一段时间以来，我发现自己对数据包分析很感兴趣，我试图找出我在网络捕获中看到的各种东西。我希望你们能帮我找出这个。
在公司网络中，我看到一台 Fortigate 100E 路由器不断地向应用服务器发送 ICMP 数据包。我的第一个想法是，“好吧，没那么特别，也许他们使用 ICMP 进行监控或保持活动状态”。但后来我注意到源端口和目标端口都被填满了。
它在 ICMP 消息中使用 TCP。这很奇怪吧？我一直认为 ICMP 是不使用第 4 层 TCP 的第 3 层控制协议。
另一件让我感到好奇的事情是，ICMP 流量是在一个方向上使用不同的目标端口。就像它在进行端口扫描——这可能吗？源端口始终为 443。
我不控制路由器，所以我无法检查路由器配置。我只是想了解我在收到的痕迹中看到的流量。
根据 ICMP 消息类型（
3“Destination Unreachable”），这些不是监视而是错误数据包（这是 ICMP 最常见的用法）。它们不使用 TCP，但它们是由TCP 数据包引起的。为了允许接收主机将错误报告与某些特定的套接字或连接相关联，每个错误数据包都必须包含原始数据包的网络层和传输层标头。因此，Wireshark 报告的端口号不是针对 ICMP 数据包本身，而是针对其有效负载（即导致此错误的原始 TCP 数据包）。
（Wireshark 将有效负载分解为嵌套的 IP 数据包，以便您可以看到信息，但它无法区分分解字段的“深度”，因此
tcp.dport == 443无论 TCP 标头有多深，整个捕获的数据包都会收到一个属性。）通过查看 ICMP 负载（“返回的”数据包），您可以看到位于 192.168.15.4:443 的 HTTPS 服务器试图向客户端主机 172.16.30.3 发送 TCP FIN，但客户端主机已关闭并且网关无法进行 ARP 查找，或者数据包被网关阻止，因此未传送的数据包被返回到 Web 服务器。
（编辑：查看 OP 在现已删除的回复中发布的完整跟踪，FIN 是在闲置约 60 秒后发送的，因此看起来有点正常，客户端主机建立了一大堆 TCP 连接并交换了一个一开始是正常的请求/回复，但随后在没有关闭它们的情况下断开了 Wi-Fi 连接——或者类似的东西。网关表现得像它应该的那样，并发送“Host Unreachable”以表明它无法通过 ARP 解析 172.16.30.3了。）
客户端总是选择一个随机端口作为每个 TCP 连接的源端口，因此从服务器到客户端的响应看起来将 443 作为源端口和一个随机目标端口是完全正常的。
您假设“源端口”始终表示“客户端端口”，但情况并非总是如此——它取决于数据包最初去往的方向；对于从服务器到客户端的数据包，交换源/目标端口号（就像交换地址一样）。