はじめに：カフェのWi-FiでVPNが繋がらない夜
深夜のカフェ。美味しいコーヒーの香りを横目に、僕は頭を抱えていた。
リモートワーク中の後輩エンジニアから「自宅以外の場所（特に公共Wi-Fi）から会社のAWS環境へIPsec/IKEv2を使ったVPNがどうしても張れない。エラーログを見ると、どうやらパケットが途中で消えているようだ」とヘルプ要請が飛んできたのだ。
「またか」と僕は苦笑いした。
Web APIの設計やモダンなクラウドインフラの構築には精通している彼らのような優秀なエンジニアでも、ひとたびパケットが物理的なルーターを飛び出し、NAPT（Network Address Port Translation）の荒海に放り出されると、途端にブラックボックス化してしまうことが多い。
特に、今日のテーマである UDPポート500番と4500番、そして NATトラバーサル（NAT-T） の挙動は、インフラエンジニアやネットワークスペシャリストにとって避けて通れない「鬼門」だ。教科書通りには動かない現実のルーターやキャリア側のCGNAT（大規模NAT）の壁をいかにして突破するか。
今回は、Web API設計やインフラ運用に携わるプロフェッショナルに向けて、IPsec/IKEv2の裏側で何が起きているのか、その泥臭い実態と解決策を紐解いていこう。
—
1. なぜIPsecはNATと相性が悪いのか？（アーキテクチャのジレンマ）
そもそも、IPsecというプロトコルは非常に頑健でセキュアな反面、設計思想が「古き良きインターネット」に基づいている。
IPsecの主役である ESP（Encapsulating Security Payload, プロトコル番号 50） は、TCPやUDPのような「ポート番号」という概念を持っていない。パケットの中に直接IPヘッダーと暗号化されたペイロードが包まれている。
ここで問題になるのが、現代のネットワークに欠かせない NAPT の存在だ。
家庭用ルーターや公共Wi-Fiのルーターは、プライベートIPアドレスをグローバルIPアドレスに変換する際、TCPやUDPの「ポート番号」を見て、どの端末からの通信かを識別している。
しかし、ポート番号を持たないESPパケットがルーターにやってくると、ルーターは「一体どの内部端末宛のパケットなんだ？」とパニックを起こし、容赦なくパケットをドロップ（破棄）してしまう。これが、NAT配下でIPsecがそのままでは動かない根本原因だ。
この絶望的な状況を救うために考案されたのが、NATトラバーサル（NAT-T） である。
—
2. 鍵交換からトンネル確立までの全シーケンス
NAT-T環境下でIPsec/IKEv2を成功させるためには、UDPポートの使い分けが極めて重要になる。まずは、パケットがどのようにやり取りされるのか、その一連の流れを追ってみよう。
登場するUDPポートの役割
UDP/500（IKE: Internet Key Exchange）: セキュリティアソシエーション（SA）の確立、認証、暗号化アルゴリズムのネゴシエーションを行う。UDP/4500（NAT-T / IPsec-NAT-T）: NAT検出が行われた後、ESPパケットをUDPでカプセル化（UDP-encapsulated ESP）して送受信するためのポート。
通信シーケンスの全体像
[クライアント (NAT配下)] [VPNゲートウェイ (グローバル)]
| |
|--- 1. IKE_SA_INIT (UDP/500) ------------->| (暗号アルゴリズムの提示)
|<-- 1. IKE_SA_INIT (UDP/500) --------------| (応答・DH鍵共有)
| |
|--- 2. IKE_AUTH (UDP/500) ---------------->| (認証情報送信 ＆ NAT検出のトリガー)
|<-- 2. IKE_AUTH (UDP/500) -----------------| (認証完了)
| |
| [ここでNAT検出：以降の通信を4500へ移行] |
| |
|<=> 3. ESP over UDP (UDP/4500) <=>>| (暗号化されたデータ通信)1. IKE_SA_INIT: 最初は標準の UDP/500 を使って通信が始まる。ここで両者は「NAT-Tをサポートしているか」を確認し合う。
2. NAT検出（NATプローブ）: クライアントから送信されたパケットの送信元IP/ポートと、ゲートウェイ側で観測されたIP/ポートが一致するかをチェックする。もし一致しなければ、「あ、途中にNATルーターがいるな」と検知される。
3. ポートの切り替え（UDP/4500へ移行）: NATが検知されると、IKEの通信および以降のすべての暗号化データ（ESP）は、強制的に UDP/4500 にカプセル化されてやり取りされるようになる。
この仕組みにより、ルーターはUDPパケットとして処理できるため、ポート番号を基に正しくNAT変換を行えるというわけだ。
—
3. 実務で役立つ！ StrongSwan設定とデバッグ手法
インフラエンジニアとして現場に立つ以上、理論だけではメシは食えない。ここでは、Linux（StrongSwan）をベースにしたサーバー側の設定例と、トラブルシューティングで必ず使うコマンドを紹介する。
サーバー側設定例 (/etc/swanctl/conf.d/vpn.conf)
実務でIKEv2/IPsecサーバーを構築する際の設定ファイルの抜粋だ。NAT-Tが有効になっていることを確認しつつ、適切な暗号スイートを指定する。
connections {
ikev2-nat-t-sample {
version = 2
local_addrs = 203.0.113.50 # VPNゲートウェイのグローバルIPアドレス
# リモート（クライアント）側の設定
remote {
auth = pubkey
certs = clientCert.pem
id = "C=JP, O=ExampleCorp, CN=remote-client"
}
# ローカル（サーバー）側の設定
local {
auth = pubkey
certs = serverCert.pem
id = "vpn.example.com"
}
# 子SA（実際のデータ通信用トンネル）の設定
children {
net-access {
local_ts = 10.10.0.0/16 # 内部ネットワークへのルーティング
remote_ts = dynamic # クライアントに割り振るIP
esp_proposals = aes256gcm16-prfsha256-ecp256,aes256-sha256
}
}
# NATトラバーサルの明示的な許可（通常は自動検出だが強制も可能）
encap = yes
}
}現場で使えるデバッグ・パケットキャプチャ術
もし「VPNが繋がらない」というアラートが上がったら、迷わずサーバー側で tcpdump を走らせ、パケットの生死を確認しよう。
# UDP 500番と4500番のトラフィックをキャプチャし、ASCIIでダンプする
sudo tcpdump -nnvvv -i eth0 "port 500 or port 4500"シニアからの実務Tips:
- もし
UDP/500のパケットすらサーバーに届いていない場合、クライアント側のOSのファイアウォール（Windows Defender Firewallやiptables/nftables）か、社外のWi-Fiルーター（あるいはプロバイダ）がUDP 500番をブロックしている可能性が高い。 UDP/500は通るのに、UDP/4500に切り替わった瞬間に通信が途絶える場合、中間にある企業のステートフルファイアウォールや古めのルーターが「UDP 4500番の長時間のUDPセッション」を不正なトラフィックとみなして遮断しているケースが多い。この場合はルーター側のタイマー設定や、企業ネットワークのポリシー見直しが必要になる。
—
4. API設計者やインフラエンジニアが知るべき「プライバシーとセキュリティ」の境界線
最後に、個人向けVPNやセキュアなリモートアクセス環境を設計・運用するエンジニアとしての視点を共有しておきたい。
パブリックなWi-Fi（カフェや空港など）を使う際、通信経路の暗号化にIPsec/IKEv2やWireGuardを用いるのは、盗聴対策（中間者攻撃の防止）として極めて有効だ。しかし、UDP 500/4500を使ったVPNトンネルを通したとしても、アプリケーション層（HTTPSなど）のプライバシー保護が免罪符になるわけではない。
Web APIを設計する際、バックエンド側では「どのVPNゲートウェイのグローバルIP（NAT-Tの変換後IP）からアクセスきているか」は識別できても、その背後にいる個々のユーザーの端末の素性まではIPsec層では見えない。
ゼロトラストの文脈においては、ネットワーク層のトンネリング（IPsecによる暗号化）だけに頼るのではなく、アプリケーション層での相互TLS（mTLS）や堅牢なトークン認証（OAuth 2.0 / OIDC）を組み合わせる多層防御こそが、現代のインフラストラクチャに求められている。
—
おわりに
UDPポート500と4500、そしてNAT-Tの仕組み。
最初は複雑怪奇に見えるパケットのカプセル化も、OSのネットワークスタックやNAPTの挙動を解きほぐしていけば、必ず原因にたどり着くことができる。
あの日の深夜、後輩と一緒に tcpdump のログを眺めながら「あ、ここのルーター、UDP 4500番を弾いてるわ！」と気づいた瞬間のあの高揚感は、インフラエンジニアにしか味わえない醍醐味だ。
この記事が、日々のネットワークトラブルに立ち向かうあなたの強力な武器になることを願っている。さあ、ログを見に行こう。
コメント