夜な夜なオフィスや自宅のルーターが発する「チカチカ」というLEDの点滅に、得も言えないロマンと、同時に「頼むから落ちてくれまいな」という冷や汗を感じるインフラエンジニアの皆さん、こんにちは。
今回は、現代のクラウドネイティブな世界でも、オンプレミスとAWS/Azureをつなぐハイブリッド環境の「大動脈」としていまだに現役バリバリで稼働している、IPsec VPNの心臓部について話をしよう。
特に、VPNトンネルが確立するまでの「最初の握手」を司る、UDPポート500番（IKE）の役割と、その裏でうごめくパケットたちの生態系について、現場の泥臭い知見を交えて徹底的に解説していく。
教科書通りの綺麗なシーケンス図を見るだけでは、深夜のトラブルシューティングでパケットキャプチャを開いたときに迷子になってしまう。生々しいパケットの動きを、一緒に脳内に焼き付けていこう。
—
1. なぜIPsecにはUDP 500番が必要なのか？
Web APIの設計やモダンなマイクロサービス開発に明け暮れていると、「HTTPはTCPの80/443だよね、じゃあVPNもそのへんのポートをよしなに使うんでしょ？」と思いがちだ。しかし、ネットワーク層やトランスポート層の根本から安全な通信路を構築するIPsecの世界は、もう少しプリミティブで、かつ厳格なルールで成り立っている。
IPsecは、OSI参照モデルの第3層（ネットワーク層）で暗号化と認証を行うプロトコルだ。単一のプロトコルではなく、いくつかのプロトコルの組み合わせで動いている。
その中でも、「通信相手はお前で間違いないか？」「暗号化の鍵をどうやって共有する？」という、いわば合コンの最初の一言から連絡先交換までの「事前の駆け引き」を担当するのが、IKE（Internet Key Exchange）である。
IKEの二役：IKEv1とIKEv2
このIKE、歴史的経緯から主に2つのバージョンが使われている。
- IKEv1: RFC 2409で規定された古典。フェーズ1（ISAKMP SAの確立）とフェーズ2（IPsec SAの確立）の2段階でネゴシエーションを行う。設定項目が多く、トララブルシュートがやや複雑。
- IKEv2: RFC 5996で標準化されたモダンな方式。メッセージ交換のラウンドトリップ（往復回数）が減り、NATトラバーサルやモビリティ耐性が大幅に向上している。
これらのIKEの制御メッセージ（コントロールプレーン）をやり取りするために、普遍的に割り当てられているのがUDPポート500番だ。
データプレーン（実際に暗号化されたユーザーパケット）が流れるのは、主にIPプロトコル番号50（ESP: Encapsulating Security Payload）だが、そのESPが流れるための「安全なトンネルの設計図」を合意するまでは、すべてこのUDP 500番が主役として奔走することになる。
—
2. 握手の裏側：IKEフェーズ1の通信フロー
では、拠点Aのルーター（イニシエーター）と、クラウド側のVPNゲートウェイ（レスポンダー）の間で、UDP 500番を介して何が行われているのか。IKEv1の「メインモード」を例に、パケットの往来を追ってみよう。
[拠点Aルーター] [クラウドVPNGW]
| |
|--- [1] IKE_SA_INIT (SA, Nonce) ----------------->| UDP 500
|<-- [2] IKE_SA_INIT (SA, Nonce, Cert/KE) ---------| UDP 500
| |
|--- [3] IKE_AUTH (ID, AUTH, SA, TSi, TSr) ------->| UDP 500 (※NAT時はUDP 4500へ移行)
|<-- [4] IKE_AUTH (ID, AUTH, SA, TSi, TSr) ---------| UDP 500 (※NAT時はUDP 4500へ移行)
| |
v v
(IPsecトンネル確立！ 以降はESPまたはUDP 4500でデータ転送)1. 第1・第2メッセージ（SAの提案と交換）: お互いに「俺はこういう暗号アルゴリズム（AES-256だのSHA-256だの）が使えるぜ」と提案し、合意を形成する。同時に、乱数（Nonce）を交換してリプレイ攻撃を防ぐ下地を作る。
2. 第3・第4メッセージ（認証と鍵の導出）: 事前共有鍵（PSK: Pre-Shared Key）やデジタル証明書を用いて、お互いの身元（Identity）を証明し合う。ここで無事に認証が通ると、暗号化通信のためのマスターキーが生成される。
トラブルの温床：NAT（Network Address Translation）の壁
ここで大きな問題が立ちはだかる。インターネットの大部分はNAT（IPマスカレード）の海だ。
UDP 500番のパケットが途中のルーターで送信元IP/ポートを書き換えられてしまうと、IKEパケットのペイロードに含まれるIPアドレス情報と矛盾が生じ、IPsecの暗号チェック（ハッシュ値の検証など）で弾かれてしまう。
この問題を鮮やかに解決するのが、NATトラバーサル（NAT-T）である。
IKEのネゴシエーションの途中で「おや、途中にNATがあるな」と検知すると、お互いに「じゃあ、これから通信ポートをUDP 4500番に切り替えようぜ」と合意し、UDP 4500番へカプセル化されたESPパケットを流すようにシフトする。
—
3. 実務で直面するファイアウォール設定と落とし穴
インフラエンジニアとして現場に出ると、「なぜかVPNが繋がらない」というチケットの9割は、ファイアウォールやセキュリティグループのポート開放漏れ、あるいはステートフルインスペクションの誤作動が原因だ。
ここでは、AWSのセキュリティグループ（Security Group）や、一般的なLinuxの iptables / nftables、あるいは企業城壁ファイアウォールでの具体的な設定例と、現場でハマりがちなポイントを見ていこう。
パラメーター選定のベストプラクティス
IKEおよびIPsecのパラメータ（いわゆるCrypto MapやProposal）は、両端のベンダーが異なっていても完全に一致していなければならない。一つでも暗号強度のミスマッチがあると、UDP 500番のやり取りの途中で「No Proposal Chosen」という悲しいログを残してネゴシエーションが破綻する。
- IKE (Phase 1) の推奨設定:
- Encryption:
AES-256-GCMまたはAES-256 - Integrity:
SHA-256(GCMの場合は不要な場合もあり) - Diffie-Hellman Group:
Group 14以上 (2048-bit MODP以上。古いGroup 1や2は脆弱性のため論外) - Lifetime:
86400秒(24時間) 程度
ファイアウォール設定例 (Linux iptables)
もし自社データセンターの出入口にLinuxベースのルーターやファイアウォールを置いている場合、UDP 500番と4500番を確実に許可する必要がある。
# ==========================================
# IPsec (IKE & NAT-T) 用のパケットフィルタリング設定
# ==========================================
# 1. 外部からのIKEネゴシエーション（UDP 500）を許可
iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A OUTPUT -p udp --sport 500 -j ACCEPT
# 2. NATトラバーサル用（UDP 4500）を許可（ESPパケットのUDPカプセル化）
iptables -A INPUT -p udp --dport 4500 -j ACCEPT
iptables -A OUTPUT -p udp --sport 4500 -j ACCEPT
# 3. 生のESPプロトコル（IP番号 50）を許可（NATがない環境や内部ルーティング用）
iptables -A INPUT -p 50 -j ACCEPT
iptables -A OUTPUT -p 50 -j ACCEPTクラウド（AWS等）のマネージドVPNゲートウェイを利用する場合、ユーザー側で直接iptablesを叩くことはないが、カスタマーゲートウェイ（CGW）側のファイアウォールやルーターで上記のエグレス/イングレス設定が確実に通っている必要がある。特に、企業の境界ファイアウォールで「アウトバウンドのUDP 500は通るが、インバウンドのUDP 500の戻りがステートフルでブロックされる（あるいはその逆）」という悲劇は、インフラエンジニアの夜更かしランキング上位の常連だ。
—
4. 現場のシニアが教える！UDP 500番のデバッグとトラブルシューティング
「設定は完璧なはずなのに、なぜトンネルが CONNECTING のままピクリとも動かないのか？」
そんな修羅場で、ベテランエンジニアが真っ先に取るべき行動をステップ順に授けよう。
ステップ1: パケットキャプチャで「誰が喋っているか」を確認する
机上の空論を語るより、パケットを見よう。拠点側のルーターや、その手前の踏み台サーバーで tcpdump を走らせる。
# UDP 500番のトラフィックをキャプチャし、ASCII文字も含めてダンプする
sudo tcpdump -nnvvv -i eth0 udp port 500ここで、
- パケットが全く飛んでいない: ルーターのルーティングテーブルがおかしい、または初期化スクリプトが走っていない。
- パケットは飛んでいるが、相手から返事（レスポンス）がない: 宛先IPアドレスの誤り、あるいは途中のファイアウォール（クラウドのセキュリティグループやプロバイダのルーター）でUDP 500番がドロップされている。
ステップ2: デバッグログのレベルを限界まで上げる
Cisco ISR、YAMAHA RTX、あるいは StrongSwan などのOSSルーター。それぞれの機器には、IKEのネゴシエーションを詳細に吐き出すデバッグモードがある。
例えば、StrongSwan（Linux）の場合：
# ログレベルを最大にしてデーモンをフォアグラウンドで起動、またはジャーナルを確認
sudo journalctl -u strongswan-starter -f --no-tailログの中に NO_PROPOSAL_CHOSEN と出ていれば、お互いの暗号アルゴリズム（AESやSHAの設定）の食い違いだ。
AUTH_FAILED と出ていれば、事前共有鍵（PSK）のタイポ（入力ミス）を疑うのが鉄則だ。
—
5. おわりに：ゼロトラスト時代におけるIPsecの位置づけ
「すべてを検証せよ（Verify Explicitly）」を旗印にするゼロトラストアーキテクチャの文脈において、従来の「社内ネットワークに入ってしまえば安全」という境界防御型のIPsec VPNは、しばしば悪者扱いされる。ID/パスワードや端末の健康状態（MDM連携など）を問わず、ネットワーク層で直通のフルアクセスを与えてしまうからだ。
しかし、だからといってIPsecが明日になくなるわけではない。
クラウドとオンプレミスを安全に結ぶバックボーンとして、あるいは個別の端末からではなく「拠点と拠点」をセキュアに結ぶレイヤー3の暗号化基盤として、UDP 500番が奏でるIKEのハンドシェイクは、今後もインフラの裏側で静かに、しかし力強く機能し続けるだろう。
その通信が「なぜ、どのように成り立っているのか」を解像度高く理解していることは、コンテナやWeb APIの海を泳ぐ現代のエンジニアにとっても、いざという時の強力な武器になる。
さあ、今日のログ確認はこのへんにして、冷えたコーヒーでも飲みに行こうか。
コメント