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

力学

如pwnat所描述的ICMP持孔运行的快速概述

SERVER向其他主机(如3.3.3.3)发送ICMP请求数据包(pings)，以打开NAT-S中的一个漏洞。当CLIENT想要连接时，它会向NAT-S发送一个ICMP时间超过的数据包，该数据包应该被路由到SERVER。为了使所述路由工作，CLIENT构造ICMP时间超过数据包，方法是在其中嵌入它期望SERVER首先发送的同一个数据包(ICMP到3.3.3.3)。

问题

如果CLIENT需要嵌入相同的(ICMP回波请求)数据包，因为它在ICMP时间超过应答时离开了NAT-S，它必须知道数据包的查询ID. ，但是它如何知道这个查询ID?

根据RFC 3022 2.2节的说法，当NAT-S遇到出站ICMP请求时，它会将数据包的查询ID字段重写为唯一的外部查询ID，以便它可以使用相同的查询ID将未来的ICMP回复路由到SERVER。

考虑到上面的问题，似乎pwnat和ICMP抢占背后的前提是无效的，而且不应该起作用。我是不是漏掉了什么？

(预先谢谢:)

Answer 1

查询ID是正确的。

pwnat现在很少工作。我几年前碰巧认识这个icmp，对这个想法很感兴趣。我已经阅读了pwnat的源代码，并自己重新实现了它。只有执行简单地址转换的基本NAT设备(rfc 1631描述)才能与它一起工作，任何具有健壮NAPT实现的NAT设备都不能工作。

除了标识符问题(顺便说一句，pwnat的源代码使用0作为原始请求的标识符)，pwnat没有给出原始ip报头的正确校验和，这可能导致NAT-S丢弃TTL超过消息(如果数据包能够到达那里)。

更严重的是，据rfc 5508说，

当NAT设备从私有领域接收ICMP错误分组时，NAT设备使用嵌入在ICMP错误消息(即从客户端到服务器的IP分组)内的包来查找嵌入包所属的NAT会话。如果NAT设备没有针对嵌入式数据包的活动映射，NAT应该静默地丢弃ICMP错误数据包。

这意味着ICMP时间超过了来自客户端的数据包不会通过NAT-C。本论文确实提到了这个场景，并推荐了其他解决方案。