ICMP数据包与TCP？

Question

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

\n

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

\n

\n

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

\n

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

\n

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

\n

Answer 1

根据 ICMP 消息类型（3“目标不可达”），这些不是监视而是错误数据包（这是 ICMP 最常见的用途）。它们不使用 TCP，但它们是由TCP 数据包引起的。

\n

为了允许接收主机将错误报告与某些特定的套接字或连接相关联，每个错误数据包必须包含原始数据包的网络层和传输层标头。因此，Wireshark 报告的端口号不是 ICMP 数据包本身的端口号，而是其有效负载（即导致此错误的原始 TCP 数据包）的端口号。

\n

（Wireshark 将有效负载解析为嵌套的 IP 数据包，以便您可以看到信息，但它无法区分解析字段的“深度”，因此tcp.dport == 443无论 TCP 标头有多深，整个捕获的数据包都会接收一个属性。）

\n

通过查看 ICMP 有效负载（“返回”的数据包），您可以看到位于 192.168.15.4:443 的 HTTPS 服务器正在尝试向客户端主机 172.16.30.3 发送 TCP FIN，但是客户端主机已关闭并且网关无法执行 ARP 查找，或者数据包被网关阻止，因此未传递的数据包将返回到 Web 服务器。

\n

（编辑：查看OP 在现已删除的回复中发布的完整跟踪，FIN 是在大约 60 秒空闲后发送的，因此看起来有点正常，客户端主机建立了一大堆 TCP 连接并交换了一开始正常请求/回复，但随后断开 Wi-Fi 连接，而没有关闭它们 \xe2\x80\x93 或类似的东西。网关的行为就像它应该的那样，并发送“主机无法访问”以表明它无法\不再通过 ARP 解析 172.16.30.3。）

\n

\n

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

\n

\n

客户端总是选择一个随机端口作为每个 TCP 连接的源端口，因此从服务器到客户端的响应看起来以 443 作为源端口和随机目标端口是完全正常的。

\n

您假设“源端口”始终意味着“客户端端口”，但情况并非总是如此 \xe2\x80\x93 它取决于数据包最初的方向；对于从服务器到客户端的数据包，源/目标端口号会交换（就像交换地址一样）。

\n