nat - ICMP 打洞有缺陷吗？

Question

如果相关 NAT 设备重写出站 ICMP 数据包，ICMP NAT 穿越应该如何工作？

图表

=========================================================================================
| CLIENT  | <---> |  NAT-C  | <---> { internet } <---> |  NAT-S  | <---> | SERVER |
=========================================================================================
                  19.19.19.19   (external addresses)   72.72.72.72
192.168.0.2       192.168.0.1   (internal addresses)   172.16.0.1       172.16.0.2

机制

ICMP 打洞的快速概述，如 pwnat 中所述:

SERVER向其他主机(例如 3.3.3.3 )发送 ICMP 回显请求数据包 (ping) 以在 NAT-S 中打开一个漏洞。当CLIENT想要连接，它会向 NAT-S 发送 ICMP 超时数据包，应该路由到 SERVER 。为了使所述路由正常工作，CLIENT通过在其中嵌入与预期 3.3.3.3 相同的数据包(ICMP Echo 至 SERVER )来构造 ICMP 超时数据包首先发送。

问题

如果CLIENT需要嵌入与离开时相同的(ICMP Echo Request)数据包NAT-S在其 ICMP 超时回复中，它必须知道数据包的查询 ID。 但是它如何知道这个查询 ID 呢？

根据RFC 3022 Section 2.2 ，当 NAT-S遇到出站 ICMP Echo 请求，它将数据包的查询 ID 字段重写为唯一的外部查询 ID，以便可以将具有相同查询 ID 的 future ICMP Echo 回复路由到 SERVER .

鉴于上述问题，pwnat 背后的前提似乎是这样的: ICMP 打洞是无效的，并且它永远不会起作用。我在这里遗漏了什么吗？

提前致谢:)

Answer 1

您对查询 ID 的看法是正确的。

pwnat 如今很少起作用。我几年前碰巧知道了 icmp 打洞的事情，并对这个想法感兴趣。我阅读了pwnat的源代码并自己用Go重新实现了它。只有进行简单地址转换的基本 NAT 设备(rfc 1631 描述)才可以使用它，任何具有强大 NAPT 实现的 NAPT 设备都无法使用。

除了标识符问题之外，(顺便说一下，pwnat 的 source code 使用 0 作为原始请求的标识符)pwnat 没有给出原始 ip header 的正确校验和，这可能会导致 NAT-S 丢弃该请求TTL 超出消息(如果数据包可以到达那里)。
更严重的是，据rfc 5508 ,

when the NAT device receives the ICMP Error packet from the Private Realm, the NAT device uses the packet embedded within the ICMP Error message (i.e., the IP packet from the client to the server) to look up the NAT Session to which the embedded packet belongs. If the NAT device does not have an active mapping for the embedded packet, the NAT SHOULD silently drop the ICMP Error packet.

这意味着来自客户端的 ICMP Time Exceeded 数据包不会通过 NAT-C。 This paper确实提到了这种情况并推荐了其他解决方案。