要約

  • RFC 5382 REQ-7 は、異なる内部エンドポイントが同じ外部アドレス・ポートのマッピングを同時に使う TCP ポート過負荷を禁止する。
  • 宛先が異なる試験では隠れていた共有が、二つの内部アプリケーションが同じ外部エンドポイントへ接続したとき、同一の公開四つ組として衝突する。容量の証明は、この収束条件を含まなければならない。

衝突が現れる一パケット

内部端末 A が外部サーバー X へ SYN を送る。NAT は A の私設アドレスとポートを、ある公開アドレスとポートへ変換する。次に内部端末 B が外部サーバー Y へ接続する。装置は B にも同じ公開座標を与える。X と Y が違うため、内部表では遠隔アドレスとポートを追加キーとして戻り先を選べる。

この状態だけを観測すれば、ポート利用効率は向上したように見える。だが B が次の接続で X を選び、A と同じサービスポートへ向かったらどうなるか。変換後の送信元は同じ、宛先も同じ、プロトコルも同じである。公開された四つ組から A と B を区別するフィールドがなくなる。

RFC 5382 の 7.1 節は、同じマッピングを共有する二つの内部エンドポイントが、一つの共通外部エンドポイントへ同時に接続できなくなると説明する。REQ-7 は TCP NAT がポート過負荷を行ってはならないと定める。

重要なのは、衝突が日常の平均トラフィックでは見えないことである。利用者が多くの宛先に分散しているほど、遠隔宛先が無料の識別子として働く。人気サービス、ソフトウェア更新先、認証基盤のように通信が一か所へ収束した時だけ、借り物だった区別が消える。

宛先独立と共同所有を混同しない

同じ RFC は TCP に endpoint-independent mapping を要求する。これは一つの内部アドレス・ポートが複数の外部宛先と通信しても、同じ外部マッピングを維持できるという意味である。主体は一つで、相手が変わる。

ポート過負荷では主体そのものが増える。異なる内部アドレス・ポートが一つの外部マッピングを同時に持つ。前者は一人の主体に対する継続性、後者は一つの座標に対する共同所有である。単なる再利用率の差ではない。

フィルタリングも別の判断である。どの外部送信元からの戻りを許すかという方針は、許可されたパケットをどの内部主体へ渡すかという一意性を作らない。BTW には NAT64 マッピングとフィルタリングを分けて論じる既存記事がある。本稿の境界はさらに手前にある。アクセス制御が判定する前に、公開座標は一人の受取人を指しているか。

運用記録では、マッピングの所有者、戻り通信の許可、TCP 確立、アプリケーション完了を別々に保存する必要がある。「同じマッピングを使えた」という事実は、それ以降のどの結論も自動的には与えない。

simultaneous open とは異なる

RFC 5382 には TCP simultaneous open に関する重要な要件もある。二つのピアが同時に active open を行い、SYN が交差しても、完全な TCP 状態機械は一つの接続を成立させられる。既存の BTW 記事は、その役割対称性と六秒の不確実性窓を扱っている。

ポート過負荷の衝突では、二つの内部端末は互いへ接続しようとしているとは限らない。両者が第三の同じサーバーを選ぶ。問題は交差する SYN の解釈ではなく、NAT が二つの内部送信元を同じ公開送信元へ射影したことにある。

したがって検証資料も違う。simultaneous open では SYN-SENT から SYN-RECEIVED への遷移や受信方針を追う。REQ-7 では割り当て時の内部組、外部組、遠隔組、時刻、アルゴリズム版、状態を所有するノードを追う。状態待ち時間を延ばしても、不足している二つ目の公開ポートは生まれない。

人気サービスを試験条件にする

適合試験は、異なる内部送信元から同じ制御済みリスナーへ二本の接続を開く。一本目のマッピングを生かしたまま、二本目を同じ外部アドレスとポートへ向ける。変換後の送信元は異ならなければならない。適合する資源がなければ、二本目は観測可能な形で拒否されるべきで、一本目の身元へ密かに重ねてはならない。

明示的な拒否は好ましいサービス結果ではない。しかし容量不足を正しく表現し、既存接続の意味を守る。ポート過負荷は初期の受け入れ数を増やせても、後で返信、再送、または新しい接続が二つの主体を同じものとして扱う危険を作る。

試験は通常負荷だけでなく、ポート枯渇、プール縮小、方針再読込、ノード切替でも繰り返すべきである。多様な宛先への百万接続は、同一宛先への二接続が守られることを証明しない。分散ケースでは隠れキーが常に存在するからだ。

IPv4 の希少性が決められないこと

公開 IPv4 は有限であり、大規模 NAT は現実の移行期間を支える。RFC 6888 が扱う運用要件も、この集中を前提としている。アドレスを共有すること自体が問題なのではない。

ただし TCP 接続が使うのはポート番号だけではない。外部アドレスとポートは、一定期間、戻りパケットを一つの内部主体へ運ぶための仮の請求権である。永久の所有権ではないが、同時に二人へ渡せば意味を失う。

容量設計にはプールの拡張、ポートブロック、タイムアウト、明示的な admission control、IPv6 移行という選択肢がある。どれも費用を伴う。だが、その費用を避けるために識別子の一意性を削ると、費用は障害調査、誤帰属、再現困難な顧客影響へ移るだけである。

正しい限界は測れる。割り当て拒否数、枯渇時間、影響を受けた契約、回復までの時間を記録できる。曖昧な割り当ては限界を隠し、成功と失敗の境界そのものを不明にする。

hairpin と ICMP が示す証拠の範囲

REQ-8 は TCP hairpinning を必須とし、内部へ戻すパケットにも外部送信元アドレスとポートを提示するよう求める。互いを公開マッピングでしか知らない内部アプリケーションは、その座標をピア識別に使う。経路が装置の内側で完結しても、外部アイデンティティを維持する必要がある。

REQ-9 と REQ-10 は ICMP の範囲を定める。Destination Unreachable は翻訳すべきだが、ICMP を受け取っただけでマッピングや TCP 接続を終了してはならない。エラーは経路についての証拠であって、状態を消す権限ではない。

アイドル時間も同様である。RFC は活動性を判断できない場合の最低時間を示すが、静かな接続が死亡したとは断定しない。その論点は既存 keepalive 記事の領域である。REQ-7 に必要な範囲では、まだ有効なマッピングを、通信が少ないという理由だけで他の内部主体へ同時貸与してはならない。

ALG がシーケンス番号を変更するなら SACK を正しく扱う必要がある。隠れた変換には後続パケットまで一貫した帳簿が要る。ポート過負荷はそれ以前に、「どの主体のシーケンス空間か」という問いを曖昧にする。

再構成できる受領証

各割り当てには、内部送信元、外部マッピング、遠隔宛先、プロトコル、生成・更新・削除時刻、方針版、装置識別子、切替世代を記録する。SYN、SYN-ACK、ACK をその割り当てへ結び、アプリケーションの処理結果を別の受領証として残す。

公開アドレスとポートによる帰属には時刻が不可欠である。もし遠隔宛先もなければ内部主体を復元できない設計なら、その制約を濫用対応や監査へ明示しなければならない。REQ-7 は TCP について、同時共同所有を最初から避ける。

試験の不成功も保存する。二本目を拒否した理由は、装置が規範を守りつつ容量限界へ達した証拠である。拒否を消して成功率だけを報告すれば、次の予算判断に必要な事実がなくなる。

出典