标签: icmp

在分析一些流量日志时，我注意到一个节点用一个大的 ping 数据包大小 ping 其网关，范围从 700 字节到 1 MB。这是从节点到网关的持续 ping，每个 ping 的大小相当高。有谁知道为什么会发生这种情况，或者操纵 PING 大小是否有好处（可能用于测试目的）？

ping包是一种ICMP包。ICMP 和 TCP 之间有什么关系吗？换句话说，我们能保证他们到达网络吗？我想知道网络中的ICMP数据包是TCP、UDP还是两者都不是？

我可以以某种方式监视 Linux 机器上的传入 ping 吗？netcat 似乎不支持。

要将 Linux 配置为忽略 ICMP 广播（以防止 SMURF 攻击），我将以下行添加到/etc/sysctl.conf：

net.ipv4.icmp_echo_ignore_broadcasts = 1

任何人都知道忽略 ICMP 广播的缺点是什么？换句话说，ICMP 广播有什么用？

EC2 实例默认禁用 ICMP 服务。虽然我不完全清楚原因，但我认为这是因为它可能存在潜在的安全风险。目前，我仅在重新启动服务器时启用 Echo Responses，以便我可以查看它是否已启动并正在运行，但是一旦它上线，我将再次禁用它。有必要吗？一般禁用 ICMP 的原因是什么？

我正在尝试 ping 一个使用普通 ping 阻止 ICMP 的服务器。它显示：

请求超时

有没有其他方法可以ping通它？

总之，我想让 Tun 设备流量通过另一个具有 Internet 连接的网络接口来回转发。虽然我可以看到流量传到互联网并返回，但它没有路由回我的 Tun 设备。

这是我的设置：

我在 VirtualBox 下使用 Mint Linux 15 VM 进行了非常简单的设置，Win7 作为主机。

在 VM 中，有两个网络接口 - eth0 和 tun0。

• eth0 接口连接到互联网，并分配​​为192.168.1.115/24。

• tun0 接口被分配为10.0.5.1/24。

  ip tuntap add dev tun0 mode tun user askldjd
  ip link set tun0 up
  ip addr add 10.0.5.1/24 dev tun0
  

  Run Code Online (Sandbox Code Playgroud)

我设置了我的 iptables 规则来伪装所有通过 eth0 流出的流量。

    iptables -I FORWARD -i tun0 -o eth0 -s 10.0.5.0/24 -m conntrack --ctstate NEW -j ACCEPT
    iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j …

一段时间以来，我发现自己对数据包分析感兴趣，并尝试找出在网络捕获中看到的各种内容。我希望你们能帮我找出这个问题。

在公司网络中，我看到 Fortigate 100E 路由器不断向应用程序服务器发送 ICMP 数据包。我的第一个想法是，“好吧，没那么特别，也许他们使用 ICMP 来监视或保持活动状态”。但后来我注意到源端口和目标端口都被填满了。

它在 ICMP 消息中使用 TCP。这很奇怪吧？我一直以为ICMP是一个3层控制协议，不使用4层TCP。

我感到好奇的另一件事是 ICMP 流量使用不同的目标端口在一个方向上。就像它正在进行端口扫描\xe2\x80\x94 这可能吗？源端口始终为 443。

我不控制路由器，因此无法检查路由器配置。我只是想了解我在收到的跟踪中看到的流量。

传输控制协议上的 Internet 控制消息传递协议和用户数据报协议有什么区别

我们有 bash 脚本来配置chrony.conf

脚本检查 ping 是否正常ntp1（ntp2ntp 服务器）

然后脚本将 ntp 服务器插入到/etc/chrony.conf（仅当 ping 成功时）

bash 脚本的示例：

ping -c 1 ntp1

if [[ $? -eq 0 ]];then
echo "server ntp1 iburst" >> /etc/chrony.conf
else
echo "sorry so much but no ping to ntp1 server , /etc/chrony.conf will not configured "
exit 1
fi


ping -c 1 ntp2

if [[ $? -eq 0 ]];then
echo "server ntp2 iburst" >> /etc/chrony.conf
else
echo "sorry so much but no …