今天，当我测试运行一个tracert命令（windows + Wireshark）时，我看到一个出站 ICMP_ECHO_REQUEST 数据包，它有源 IP 为“192.168.1.55”-我的本地 IP 地址。
随后，互联网上的一个野生主机发送了一个 ICMP_TTL_EXCEEDED 数据包，作为对我的 EchoRequest 数据包中途终止的回复。回复数据包在有效载荷部分“引用”了我的“原始数据包”的前 28 个字节，我可以看到源 IP 保持为“192.168.1.55”-我的本地 ipAddress。
我的脑海里立即冒出一个问题：“NAT没有在IP-Header中重写“本地”源IP，还是在payload中重写了它”？
据我所知，对于 TCP 或 UDP 数据包，NAT 将在数据包的 IP 标头中将本地“ip:port”替换为外部“IP:PORT”。所以我想知道：
1-NAT 是否在数据包的有效负载部分替换它们？（或者仅对 TTL_Exceeded 类型的 ICMP 数据包执行此操作？）
2——如果1不正确，这是一种安全威胁吗？
答案1
答案是视情况而定。
我收到了来自带有 NAT 设备的系统的 ICMP 消息，该设备允许内部 IP 地址通过 ICMP 消息泄露。
但是，为了让 ICMP 消息的接收者能够可靠地将其与之前发送的数据包关联起来，ICMP 消息需要包含触发数据包，其内容与最初的样子基本一致。这意味着，如果数据包在被 NAT 修改后触发了 ICMP 消息，则 NAT 必须撤消 ICMP 有效负载内的修改。有些 NAT 确实做到了这一点。
还有更多微妙的方面需要注意。当 NAT 修改 IP 地址时，它还必须修改数据包内的校验和。但是 ICMP 有效负载通常是截断的 IP 数据包，因此无法验证传输层校验和。因此它们很少使用，并且不修改 ICMP 有效负载内的校验和不会导致破坏。但是，这确实会导致校验和在一个方向上被修改，而不是在另一个方向上被修改。这样，有关内部 IP 地址的一点信息可能会泄露。
这些泄漏可以视为安全漏洞。这只是 NAT 可能导致的一种泄漏。还可能出现更严重的泄漏，包括将数据包片段发送到目标接收者以外的其他主机。这些是 NAT 不是一个好主意的一些原因。用没有 NAT 的防火墙替换 NAT 将提供更好的整体安全性。但这当然需要更多的 IP 地址。
答案2
NAT 不会触及数据包的有效负载。它只触及 IP 和 TCP/UDP 报头。IP 地址包含在 IP 报头（源和目标）中。TCP 报头包括源端口和目标端口，UDP 报头也是如此。
对于 ICMP 情况，你可以看看这一页。它指出，如果出现错误消息（例如 TTL 超出），数据包将包括 IP 标头（20 字节）+ 有效负载的 8 字节 = 您所看到的 28 字节。