対称NATのUDPホールパンチ：少しの理論とほぼ正直な実験

こんにちは、同僚。



少し前に、私は主題に興味を持つようになりました。 この調査では多くの資料が得られましたが、調査中にいくつかの疑問が生じました。実際にいくつかの理論的な点を確認したかったのです。 興味のある方-お願いします。







対称NATとは何かについて主題に簡潔に触れていない人のために。



シンプルなスキームを考えてみましょう



host1、host2-NATの背後にあるユーザーホスト

NAT1、NAT2-NATを提供するエッジデバイス



host1が特定のreal_IPとの発信接続（TCPまたはUDP）を開始すると、NAT1デバイスは発信パケット内のソースIPを独自のものに置き換えます（オプションで独自のものに置き換えますが、簡単かつ明確にするためにこれを受け入れます）。また一般的に、PORT_SRCをランダムなPORT_SRC1に置き換えます。



host1 ____ PORT_SRC、PORT_DST ---> NAT1デバイスPORT_SRC1、PORT_DST ----> real_IP



したがって、この応答パケットのソースIP自体がreal_IPであり、ソースポートがPORT_DSTであり、宛先ポートがPORT_SRC1である場合に限り、real_IPホストがNAT1デバイスによって転送される場合、NATは対称になります。 つまり、real_IPは、そのアドレス、接続先と同じポート、およびNAT1デバイスからの発信接続と同じポートから応答します。 ここで「対称性」という用語が良いアイデアではなかったことに気付くのは難しくありません。



タスクが対称NATを「突破」し、ホストがそれと直接通信できるようにする場合はどうなりますか？



一般的な場合、次の単純なシェムカがあります。



host1 ----> NAT1 SRC1_random、DST1_required ---->



<-DST2_as_aウィッシュ、SRC2_random NAT2 < -host2



SRC1_random-NAT1によるNAT置換後の送信元ポート。

必要に応じてDST1-NAT1を介してhost1と確立された発信接続の宛先ポートを選択できます。

DST2_wanted-host2からNAT2を介してNAT1に送信されるパケットの宛先ポートは、当社が選択できます。

SRC2_random — NATがNAT2によってスプーフィングされた後のソースポート。



この図をよく見ると、「ブレークダウン」の難しさが明らかです。 トラフィック交換が機能するためには、SRC1_random = DST2_by_ desireおよびDST1_by_require = SRC2_by chanceを実行する必要があります。

デバイスhost1およびhost2は、ポートSRC1ランダムおよびSRC2ランダムを制御できません。 一般に、それらは本当にランダムになり、さらに宛先IPと宛先ポートに依存します。 このトピックを検索して見つかった資料の大部分は、この単純な事実を無視し、単純なSTUNサーバーでこれらの未知のものを認識するのに十分であると信じていました。

はい。 iptablesなどを使用して整理されたNATを使用する場合、次の形式の構成



-t nat -Aポストルーティング-jマスカレード

または

-t nat -Aポストルーティング-j SNAT --to-source



送信元IPのみを置き換えます。発信ポートはクライアントと同じままです。 したがって、タスクは大幅に簡素化され、このNATバイパステクノロジーのメディエーターの役割を説明する多くの記事が頭に浮かび始めます。

しかし、これは特別で最も単純なケースです。



同じiptablesの場合、これらの構造は次のように置き換えることができます



-t nat -A POSTROUTING -j MASQUERADE ... --random

または

-t nat -A POSTROUTING -j SNAT --to-source ... --random



状況は面白くなくなります。 送信ポートは、NAT変換中にランダムに選択されます。



全体として、上の図を注意深く見てみると、次の問題があります。



host1もhost2もSRC1ランダムおよびSRC2ランダムを認識しません。たとえば、送信パケットの送信元ポートを変更したり、NATデバイスのNAT変換のエントリが古くなってリセットされる時間があるようにデータを送信する間に十分なタイムアウトを設定するなど、間接的にのみ影響を与えることができます。

Host2は、特に、必要に応じてDST1を見つける必要があります（一般に、ポートは事前に合意できますが、最悪の場合を考慮します）。



仲介者の必要性について長い説明をすることなく、交換のすべての参加者のためのアクションのおおよそのアルゴリズムをすぐに概説します。



1. host1とhost2が無料の双方向トラフィックフローで本格的な制御接続を確立するための仲介者が厳密に必要です。 このような制御セッションのイニシエーターは、NATの背後にあるホストです。 仲介者は、ホワイトIPに関する情報をエンドホストに配布します。



2. host1がターゲット接続/クライアントのイニシエーターであり、host2の場合、接続が着信する、つまりサーバーとして機能すると仮定します。



3. Host1は、DST1_willを任意に選択して、NAT2の実際のアドレスへのパケットの送信を開始します。



4.制御接続のHost1は、選択したDST1_preferenceの仲介者に通知し、同じパラメーター（送信元ポート、宛先ポート）でパケットを送信し続けて、SRC1ランダムが変わらないようにNAT1への一定のブロードキャストを維持します。 出荷間の遅延は実験的に決定することができます。タスクは簡単なので、私はそれをペイントせず、このテキストに含めません。



5.ブローカーはNAT1をスキャンし、ソースIPをアドレスNAT2に置き換えて、必要に応じてソースポートDST1__を提供し、1024（または65535の全範囲）以上の範囲で宛先ポートをソートします。 NATは対称と呼ばれる無駄ではないと以前に決定したため、これはすべて必要です。

列挙の結果として（今回までにNAT1によって禁止されていない場合）、最終的に宛先ポートSRC1_randomでパケットを送信すると、そのようなパケットは、NAT機能の範囲を超える特にトリッキーな保護メカニズムがhost1に渡される場合。 彼が検出し、制御チャネルでさらに検出したものは、仲介者に通知し、推測値SRC1_randomを記憶します。



6.中間は、制御チャネルでhost2 SRC1_randomに報告します。



7. Host2は外部アドレスNAT1へのパケットの送信を開始します。これらのパケットの宛先ポートはDST2_of_desire = SRC1_randomである必要があります。 NAT2デバイスによって選択されたSRC2_randomがDST1_of_willと一致するまで、彼はこれをしなければなりません。

この待望の偶然が起こるとき、2つのオプションが可能です。

最初の。 そのようなパケットはhost1に到達し、これについて仲介者に通知し、仲介者はhost2に通知し、「ハッピー」セッションが継続します。

二番目。 Host2は、「swotting」でもう一度NAT1を困らせたくないので、発信パケットのIP-ttlを、NAT2を通過する値に変更しましたが、NAT1には到達しませんでした。 同時に、NAT2への変換が作成され、パケットはNAT1に到達しませんが、切望された変換が作成されると、パケットはhost1から送信されます（前述のように変換をサポートすること、つまり、NAT2が定数パラメーターで「スラム」することを忘れていません） host2に到達し、次に仲介者などに通知します。



ご覧のとおり、一般的なケースでは、対称NATを破ることはそれほど単純で高速なタスクではありません。 さまざまな実装（iptablesを思い出してください）では、大幅に簡素化され、保証された成功を伴う手順に変わりますが、一般的な場合ではなく繰り返します。

説明されているアルゴリズムの最もボトルネックは何ですか？



1.パラグラフ5のスプーフィングの必要性。仲介者は、これを許可し、プロバイダーから問題を取得しないネットワークにアクセスする方法を用意する必要があります。



2.手順5で広範囲のポートをスキャンします。「正しい」NATの場合、ホスト1が仲介者との接続を単純に確立し、NAT2への接続の場合のランダムSRC1_が同じであると仮定することはできません。 宛先アドレスを変更すると、SRC1_randomが変更されます。 スキャンは、もちろん、十分に迅速かつ積極的に実行できます。より慎重に、しかしより長くすることができます。 いずれにせよ、これは弱点です。



3.パラグラフ7のアクションは無期限に長くなる可能性があります。 この瞬間は私の好奇心と試してみたいという欲求を呼び起こしました。



4.そしてもちろん、たくさんの手紙を読むのにうんざりしている人は、「必要だと思って、すべての標的トラフィ​​ックを仲介者に通して、それだけだ！」と言うかもしれません。 ここで議論することは困難です、もちろん、私はこのテキストが取った時間のためにそれらに謝罪します。



今すぐ練習します。 トピックに興味のある人を失望させるかもしれませんが、仲介者を書きませんでした:) tcpdumpは、適切な場所で適切なタイミングで、また著者の目と手で彼の役割で行動しました:)



だから。 3G = host1のWindowsワークステーションがあります。 モデム接続で、グレーアドレス10.140.80.130が発行されました。 これは、NATの背後にあるhost1の内部アドレスです。

このルーターのすぐ後ろに白いアドレスxx.xx.xx.xxとhost2を持つAT AR-750sルーターがあります。

必要に応じて任意のDST1を選択します。私の場合は21393でした。

host1から10秒の頻度で開始し、UDPパケットをxx.xx.xx.xxに送信します：21393。

悪意のあるスキャンの段階をスキップして、ポート21393に関する「秘密の」情報とhost2にSRC1がモバイルオペレーターのNATオペレーターにとってランダムであるという「覗き見」情報を持ち込み、45499（私たちがNAT-it world-eaterであるIP too = yy.yy.yy.yy）。

host2から、yy.yy.yy.yy：45499で「bang」を開始し、ラッキーになるまで待機します。発信パケットが21393に等しいNATのソースポートを受信します。ttlを混乱させず、host1およびhost2でスニファーによる故障を検出しました。 host2からのパケット生成速度は1秒あたり5パケットでした。 同時に、NAT2ルーターには、無関係な（ユーザーが聞いたことがある）トラフィックがわずかに負荷がかかっていました。

最初の「故障」は、実験開始の約8時間後に発生しました。 その後、農場全体が一晩働くために残っていたため、さらにいくつかが起こりました。 後続のものは数回より速く発生し始めました。ここでは、「外部の」トラフィックの影響について空想することができます。



これが「故障」の様子です。 結論は選択的であり、必要な偶然の一致を伴う「ハッピー」パッケージのみが含まれます。



トラフィック収集の「トリッキー」ポイントでのスニファー出力。AR-750ルーターの外部インターフェイスでNATを実行した後（トラフィック）に表示されます。



02：19：05.060809 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499：UDP、長さ0

05：07：00.178149 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499：UDP、長さ0

06：28：35.355623 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499：UDP、長さ0

07：16：29.764069 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499：UDP、長さ0

11：28：06.899109 IP xx.xx.xx.xx.21393> yy.yy.yy.yy.45499：UDP、長さ0



故障が「検出」されたhost1のスニファー出力（時間は同期されていないため、タイムスタンプとhost2トラフィックのダンプからの出力の間に矛盾があります）。



02：18：20.480468 IP xx.xx.xx.xx.21393> 10.140.80.130.2429：UDP、長さ0

05：06：15.496093 IP xx.xx.xx.xx.21393> 10.140.80.130.2429：UDP、長さ0

06：27：50.464843 IP xx.xx.xx.xx.21393> 10.140.80.130.2429：UDP、長さ0

07：15：44.839843 IP xx.xx.xx.xx.21393> 10.140.80.130.2429：UDP、長さ0

11：27：21.589843 IP xx.xx.xx.xx.21393> 10.140.80.130.2429：UDP、長さ0



host2に直接ダンプした結果もあり、NAT1への変更されていない変換をサポートするポイント4からのパケットがhost2に到達し始めたことは明らかでしたが、私はそれをsoきました。



これはそれほど正直ではない実験です。 しかし、パラグラフ7で比較的低い検索頻度でも、比較的妥当な時間で目的の結果を達成できることを示しました。 より積極的なバスティングにより、さらに合理的になります。 もちろん、「工業用」アプリケーションは魅力的ではありませんが、...しかしそれは可能です。 説明されているアルゴリズムと実験は、加速最適化マルチスレッドアプローチなどのテーマに関する思考の糧となります。



UPD：パケットが送信元ポートに変更を加えてhost2から送信されたことを忘れていたため、送信元ポートもNAT2に対して変更され、NAT2への変換が終了するのを待つのはコストがかかりすぎます。