NAT 是否會重寫 ICMP 數據包有效負載中的 ipAddress？
今天，當我測試執行
tracert命令（windows + Wireshark）時，我看到一個出站 ICMP_ECHO_REQUEST 數據包，其sourceIP 為“192.168.1.55” - 我的本地 IPAddress。緊隨其後的是從 Internet 狂野主機發送的 ICMP_TTL_EXCEEDED 數據包，作為對我的 EchoRequest 數據包中途死亡的回复。回複數據包在有效負載部分“引用”了我的“原始數據包”的前 28 個字節，在那裡我可以看到源 IP 停留在“192.168.1.55” - 我的本地 ipAddress。
一個問題立即從我的腦海中冒出來：“NAT 沒有重寫 IP-Header 中的“本地”源 IP，還是他在有效負載中重寫了它？
AFAIK 在 TCP 或 UDP 數據包的情況下，NAT 將在數據包的 IP 標頭中將本地“ip:port”替換為外部“IP:PORT”。所以我想知道：
1 - NAT 是否在數據包的有效負載部分替換它們？（或者只使用 TTL_Exceeded 類型的 ICMP 數據包？）
2 - 如果 1 不正確，這是一種安全威脅嗎？
答案是視情況而定。
我收到了來自具有 NAT 設備的系統的 ICMP 消息，該設備允許內部 IP 地址通過 ICMP 消息洩漏。
然而，為了讓 ICMP 消息的接收者可靠地將其與先前發送的數據包相關聯，ICMP 消息需要包含與最初看起來一樣的觸發數據包。這意味著如果數據包在被 NAT 修改後觸發 ICMP 消息，則 NAT 必須反轉 ICMP 有效負載內的修改。有些 NAT 做到了這一點。
還有更多微妙的方面需要注意。當 NAT 修改 IP 地址時，它還必須修改數據包內的校驗和。然而，ICMP 有效負載通常是截斷的 IP 數據包，因此無法驗證傳輸層校驗和。出於這個原因，它們很少使用，並且不修改 ICMP 有效負載中的校驗和不會導致損壞。然而，這確實會導致校驗和在一個方向而不是另一個方向上被修改。這樣一來，關於內部 IP 地址的一些資訊就會洩露。
這些洩漏可以被認為是安全漏洞。這只是 NAT 可能導致的一種洩漏。更嚴重的洩漏也是可能的，包括將數據包片段發送到另一個主機而不是預期接收者的可能性。這些是 NAT 不是一個好主意的一些原因。用沒有 NAT 的防火牆替換 NAT 將提供更好的整體安全性。但這當然需要更多的 IP 地址。