IKEv2 は UDP 500 と 4500 のどちらでデータを運ぶのか

ファイアウォールで UDP 500 を開けるとトンネルはネゴシエートできますが、その後に接続はトラフィックを通さなくなります。ポート一覧は間違いではなく、不完全でした。IKEv2 は一方のソケットで始まり、実際の多くの配備ではもう一方のソケットで続きますが、ペイロードはポートですらないこともあります。段階を順に読むことで、どのルールが欠けているかが分かります。

二つのポート、二つの役割

IKEv2 は UDP 500 での鍵交換から始まり、そこでピア同士が認証を行い、トンネルのセキュリティアソシエーションを確立します。その後のデータ経路は別の問題です。ポートではなく IP プロトコル番号であるネイティブ ESP か、4500 上で UDP にカプセル化されたトラフィックのどちらかになります。ファイアウォールの見直しでこの二つを分けて考えることが、ネゴシエートするトンネルと実際に動くトンネルの違いであり、一方のソケットが制御を、もう一方がペイロードを運びます。

だからこそ 500 だけを許可するルールは、プロトコル群全体で最も紛らわしい症状を生みます。ネゴシエーションは成功するのに役に立つものが何も続かず、状態にはピアが表示され、ログには確立した IKE SA が表示され、それでもアプリケーションはタイムアウトします。足りない許可は、たった今成功したフローとは別のフローに属しています。

4500 がそもそも存在する理由

多くの NAT 機器は TCP か UDP 以外のプロトコルを転送できず、中には ESP の整合性検査を壊す形でアドレスを書き換えるものもあります。ESP を UDP でカプセル化すれば両方の問題が解決しますが、その代わりに余分なヘッダーと、許可すべき二つ目のポートが必要になります。このカプセル化こそが、二つ目のポートが存在する理由です。

NAT が検出されると IKE 自体も 4500 に移り、すべてのトラフィックが変換装置を通る一本の経路を共有します。ESP ではない四バイトのマーカーが、そのソケット上の制御メッセージとデータを区別します。この切り替えはプロトコルの決定であり、管理者の好みではありません。

送信元ポートが変わる場所

変換装置はクライアントの送信元ポートを書き換えることがあるため、サーバー側で見えるタプルはクライアント側のタプルと一致しません。ルールが無視されていると結論づける前に、NAT ホップの両側を見てください。クライアントだけで調査すると、正しく見えるのに失敗するルールを作ってしまうことがあります。

MOBIKE 対応の実装は NAT が検出されなくても 4500 に移ることがあり、意図的にその経路を強制する配備もあります。したがって 4500 が見えることは判断の証拠であり、家庭用ルーターの証明ではありません。

すべての境界で両方のフローを確認する

三つの境界、つまりクライアントのネットワーク、中間のファイアウォール、そしてサーバーをたどります。それぞれに必要なのは配備が文書化したフローであり、別の事例についての記事のフローではありません。

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

ファイアウォール一覧の ESP 行はプロトコルの一致なので、ポートのルールでそれを覆うことは決してできません。クライアントはなじみのある番号を選ぶだけでサーバー側にリスナーを作れるわけではないため、運用者が独自のポートを使う場合は、両端で文書化された設定に従ってください。

ネゴシエーションがどこで止まったか、子セキュリティアソシエーションがインストールされたかを記録してください。この組が、遮断された経路と認証やポリシーのエラーを分けます。次に、到達可能性は認証ではないため、サーバー検証を有効にしてテストを繰り返し、許可されたポートと信頼できるピアを分けてください。