同じルーターの背後にある二つのクライアントが一つの IPsec ゲートウェイと通信し、一方だけが繰り返し切断されるのに他方は接続を保つ。元来の ESP はポートを持たない IP プロトコル 50 なので、複数のクライアントが一つのアドレスを共有すると、変換装置はマッピングの手がかりを持てない。NAT トラバーサルは ESP を 4500 の UDP で包むことでその隙間を埋め、そのヘッダーが続く症状のほとんどを説明する。変更すべき機器も示してくれる。

データプレーンがポート 4500 へ移る理由

設定中に IKEv2 は、双方が使用していると考えるアドレスとポートを、NAT 検出通知でハッシュを交換して比較する。ハッシュが一致しない場合、経路のどこかに変換装置があり、両ピアは保護トラフィックを UDP カプセル化へ切り替える。変換装置に直面したセッションが見かけ上異なるのはそのためだ。

包みは封筒であり、プロトコルの変更ではない。ESP はヘッダー、整合性チェック、暗号化を保つUDP が提供するのは変換装置に必要なポートだけだ。ポート 500 は IKE のやり取りを運び、4500 は検出後のカプセル化データを、そして多くの場合その後の IKE メッセージも運ぶ。どちらのポートもフローを TCP 接続にはしないという、キャプチャーを読むほとんどの人が誤解する前提だ。

二つの段階を順に確認する

まず制御のやり取りを、次にデータ経路を証明し、両者をメモで分けておく。500 でトラフィックが見え 4500 で一度も見えないキャプチャーは、通常データ経路がフィルタリングされていることを意味するので、修正はクライアントではなくファイアウォール規則の側にある。

tcpdump -ni any 'udp port 500 or udp port 4500' で両方のポートを監視し、セッションが動いている間にルーターの変換テーブルを読む。そのテーブルはゲートウェイが実際に見る送信元ポートを示し、ノート PC のキャプチャーは設計上それと食い違う。ノート PC は 500 と信じ、ゲートウェイは変換された送信元ポート付きの 4500 を見ており、どちらも正しい。同じフローの変換前と変換後は次のとおり:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

包みが説明できる症状と、説明できない二つ

制御のやり取りを許可しながらカプセル化データを遮断するルーターは「トンネルは上がったが何も通らない」という報告を生む。マッピングテーブルは期限切れになるため、アイドル状態のセッションにはピアが意図的に送るキープアライブのトラフィックが必要であり、そのパケットはヘルスチェックではない。一つのゲートウェイ背後の複数クライアントが同時に失敗する場合は、そのゲートウェイの変換と旧来のパススルー機能を調べる。包みは、トンネル確立後に全クライアントで失敗するアプリケーションも、ブロックページの証明書警告も説明しない。どちらもこの層より上にある。

二つのクライアントについて同時にマッピングテーブルを読む。両方が同じ変換ポートを示すなら、その機器はゲートウェイが要求するようには両者を分離していない。元の ESP を一つのホストにだけ渡すパススルーモードは、複数の変換クライアントにサービスすることと同等ではない(ベンダーはどちらも IPsec 対応と説明するが)。二重 NAT はマッピング層と期限切れ点をもう一つ増やすが、外向き接続を自動的に壊すわけではない。

キープアライブのトラフィックは運用マニュアルで独立した一行に値する。アイドル期間に応答経路を開いたままにするのはそれだからだ。ベンダーが文書化している場所で有効にし、セッションが最初の使用時ではなく数分の沈黙の後に死んだときにまずそれを確認する。

マッピングの所有者を変え、それから再テストする

ポートを推測するのではなく、両ピアでサポートされている NAT トラバーサル設定に従う。一つのクライアントでローカルの送信元ポートを編集しても、遠端で待ち受けるサービスは変えられず、通常は既に構築済みのマッピングを壊す。クライアントが管理外の機器の背後にあるなら、変更はその所有者のものだ。

変更のたびに両方の段階チェックを繰り返し、ステータス画面が緑になっただけでなく、データパケットが通過することを確認する。タプル、マッピングテーブルの出力、規則の変更を一つのメモにまとめ、次の人が制御のやり取りからやり直さないようにする。strongSwan の NAT トラバーサルに関する注記は、両段階の背後にあるカプセル化とキープアライブの設定を扱っている。

関連記事