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 holepunching的快速概覽：

SERVER發送ICMP迴應請求包（ping），以一些其它宿主（例如3.3.3.3）至在NAT-S打開一個洞。當CLIENT想要連接時，它發送一個ICMP Time Exceeded數據包到NAT-S，這應該被路由到SERVER。爲了使所述路由工作，CLIENT通過在其中嵌入相同的數據包（ICMP回聲到3.3.3.3）來構造ICMP超時數據包，它期望SERVER首先發送。

問題

如果CLIENT需求，從而嵌入在其ICMP超時回覆留下NAT-S相同（ICMP迴應請求）數據包，它必須知道包的查詢ID。 但是它如何知道這個查詢ID？

據RFC 3022 Section 2.2，當NAT-S遇到出站ICMP迴應請求，重寫數據包的查詢ID字段以獨特的外部查詢ID，以便它可以路由未來ICMP回聲相同的查詢ID，以SERVER回覆。

鑑於上述問題，似乎背後pwnat和ICMP holepunching背後的前提是無效的，它從來沒有工作。我在這裏錯過了什麼嗎？

在此先感謝:)

Answer 1

您對查詢ID是正確的。

pwnat現在很少有作品。我幾年前碰巧知道這個icmp衝孔的東西，並對這個想法感興趣。我已經閱讀了pwnat的源代碼並在Go中自己重新實現了它。只有進行簡單地址轉換的基本NAT設備（rfc 1631描述）可以與它一起工作，具有健壯NAPT實現的任何NAPT設備都不會這樣做。

除了標識符問題，（順便說一句，pwnat的source code使用0作爲原始請求的標識符）pwnat沒有給出原始ip頭的正確校驗和，這可能導致NAT-S丟棄TTL超出的消息（如果數據包可以到達那裏）。
更嚴重的，根據rfc 5508，

當NAT設備接收來自私人領域的ICMP錯誤分組

，NAT設備使用嵌入的ICMP錯誤消息（內的分組即來自客戶端的IP分組到服務器）查找嵌入式數據包所屬的NAT會話。如果NAT設備沒有嵌入式數據包的活動映射，NAT應該悄悄丟棄ICMP錯誤數據包。

這意味着來自客戶端的ICMP Time Exceeded報文不會通過NAT-C。 This paper確實提到了這種情況並推薦了其他解決方案。