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のholepunchingの概要pwnatで説明したように：

SERVERにいくつかの他のホスト（例えば3.3.3.3）にICMPエコー要求パケット（pingを）送りますNAT-Sに穴を開けてください。 CLIENTが接続したい場合、SERVERにルーティングされるはずのNAT-SにICMP Time Exceededパケットを送信します。前記ルーティングが動作するためには、が最初に送信されることを期待する同じパケット（ICMPエコー3.3.3.3）をその中に埋め込むことにより、CLIENTはICMP時間超過パケットを構築する。

問題

それはそのICMPタイムにNAT-Sを残したのと同じ（ICMPエコー要求）パケットを埋め込むCLIENTニーズが回答を超過した場合、それはパケットのクエリIDを知っている必要があります。 しかし、このクエリIDはどのように知っていますか？ RFC 3022 Section 2.2によると

、NAT-Sは、アウトバウンドICMPエコー要求に遭遇したとき、それはルート将来ICMPエコーSERVERに同じクエリIDを返信することができるように、それはユニーク外部クエリIDにパケットのクエリIDフィールドを書き換えます。

上記の問題を考えると、pwnatとICMPホールパンチの前提は無効で、動作するとは思われません。私はここに何かを逃していますか

ありがとうございます。

Answer 1

質問IDについては正しいですか。

pwnat今日はめったに動作しません。私は何年も前にこのicmpパンチングのことを知り、このアイデアに興味がありました。私はpwnatのソースコードを読んで、自分でGoに再実装しました。簡単なアドレス変換を行う基本的なNATデバイス（rfc 1631が記述しているもの）だけで動作しますが、堅牢なNAPT実装を持つNAPTデバイスは動作しません。

（ただし、pwnatのsource codeは元の要求の識別子として0を使用します）pwnatは、TTLをドロップするNAT-Sにつながる元のIPヘッダーの正しいチェックサムを与えませんでした（パケットが届いている場合）メッセージを超過しました。
より深刻な、rfc 5508によると、

NATデバイスは、プライベートレルムからのICMPエラーパケットを受信したとき、NATデバイスがクライアントからのICMPエラーメッセージ（すなわち、IPパケット内に埋め込まれたパケットを使用しています埋め込みパケットが属するNATセッションをルックアップする。 NATデバイスが埋め込みパケットのアクティブマッピングを持たない場合、NATはICMPエラーパケットを静かにドロップすべきである（SHOULD）。

これは、クライアントからのICMP Time ExceededパケットがNAT-Cを通過しないことを意味します。 This paperはこのシナリオに言及し、他の解決策を推奨します。