【テクニカル・上級編】 IKEv2/IPsecにおけるUDPポート500番と4500番(NATトラバーサル) – サイバーセキュリティとプライバシー保護実践ガイド

モバイル時代のIPsec：IKEv2とNAT-Tが織りなすパケットの裏側と極限チューニング

カフェの片隅で、あるいは新幹線の座席で、エンジニアである私たちはシームレスに社内ネットワークやプライベートVPNへ接続する。Wi-Fiの電波が途切れ、モバイル回線へハンドオーバー（切り替え）が発生した瞬間も、TCPのセッションが切れずに生き続ける――この現代の「当たり前」の裏側では、レイヤー3とレイヤー4の境界線上で、プロトコルたちの極めて緻密なダンスが繰り広げられている。

教科書的な「VPNとは暗号化技術です」という説明にはもう飽き飽きしているはずだ。今回は、インフラアーキテクトやセキュリティスペシャリストの視点から、IKEv2/IPsecが使用するUDPポート 500 と 4500（NATトラバーサル）、そしてパケットレベルの挙動とカーネルチューニングの深淵へと踏み込んでいこう。

—

1. IKEv2とUDPポート500/4500の宿命

IPsec（Internet Protocol Security）は、OSI参照モデルのネットワーク層で動作する、最も堅牢なセキュリティプロトコル群の一つだ。その中で、鍵交換とセキュリティアソシエーション（SA）の確立を担うのがIKE（Internet Key Exchange、現在はIKEv2が主流）である。

IKEv2の初期ハンドシェイクは、標準でUDPポート 500を使用する。これはISAKMP（Internet Security Association and Key Management Protocol）のためにIANAで予約されたポートだ。

しかし、現代のインターネットはNAT（Network Address Translation）およびNAPT（Network Address Port Translation）に満ちている。自宅のルーター、オフィスのファイアウォール、そして携帯キャリアのCGNAT（Carrier-Grade NAT）。これらはすべて、プライベートIPアドレスをグローバルIPアドレスに変換する過程で、IPヘッダーやUDP/TCPヘッダーの書き換えを行う。

ここに致命的な問題が発生する。IPsec ESP（Encapsulating Security Payload、プロトコル番号 50）は、TCPやUDPのような「ポート番号」を持たない。そのため、従来のNAPTルーターはESPパケットをどの内部ホストに転送すべきか判断できず、ルーターの多重NAT環境下ではパケットが途中でドロップされてしまうのだ。

NATトラバーサル（NAT-T）のメカニズムとUDP 4500の登場

この問題を解決するのが、RFC 3948で規定されたNAT-T（NAT Traversal）である。

1. ポートの検出（IKE_SA_INIT）:
クライアントとVPNサーバーは、IKEv2の最初の交換（IKE_SA_INIT）の際にお互いのNAT検出ペイロード（Nペイロード）を交換し、経路上にNATが存在するかどうかを検証する。
2. ポートのエスカレーション（UDP 4500）:
もし経路上にNATが存在することが判明した場合、またはクライアント自身がNATの内側にいると判断した場合、通信は標準のUDP 500からUDP 4500へとカプセル化（UDP-encapsulated ESP）されて移行する。

このUDP 4500への切り替えにより、NAPTルーターは通常のUDPパケットと同様にポート番号（4500）をベースにしたパケットフォワーディングが可能になり、NAT配下であってもIPsecトンネルを維持できるようになるのだ。

—

2. パケットキャプチャから読み解くハンドシェイクの現実

実際に、Linux環境（強靭なオープンソースIPsec実装であるStrongSwan等）でIKEv2のパケットがどのように流れているのか、tcpdumpの視点からその挙動を覗いてみよう。

# クライアント側インターフェースでIKEv2およびNAT-Tのパケットをキャプチャする
sudo tcpdump -ni eth0 "udp port 500 or udp port 4500" -vv

パケットが流れると、次のようなシーケンスが観測される。

1. IKE_SA_INIT リクエストがクライアントの適当なエフェメラルポートからサーバーの UDP/500 へ送信される。
2. サーバーからの応答にNAT検出が含まれており、以降のメッセージ（IKE_AUTHなど）および実際のESPトラフィックがすべて UDP/4（送信元/宛先ポート共に 4500）にカプセル化される。
3. このUDPパケットのペイロード内部には、さらに通常のIPヘッダーとESPパケットがカプセル化されている（いわゆる「Non-ESP Marker」と呼ばれる4バイトのゼロパディングが先頭に付与される）。

この二重のカプセル化とポート変換のオーバーヘッドは、極限のスループットを追求する環境においては無視できないコストとなる。しかし、モバイルデバイスの「スリープ復帰時における圧倒的な再接続性（Mobility and Multihoming Protocol: MOBIKE）」の恩恵の前には、このオーバーヘッドなど小さな代償に過ぎない。

—

3. モバイル環境におけるRTT削減とカーネル最適化

ノートPCやスマートフォンがWi-Fiから5Gへ切り替わる際、IKEv2はMOBIKE（RFC 4555）を利用して、既存のSAを破棄することなく宛先/送信元IPアドレスの変更をサーバーに通知する。これにより、ハンドシェイクのコストをゼロに抑え、瞬時にトンネルを再構築できる。

しかし、デフォルトのLinuxカーネルパラメータのままでは、パケットロスが頻発する劣悪なモバイル回線において、IPsecのパフォーマンスは十分に発揮されない。インフラエンジニアとして、次のカーネルチューニングを施すことが実務では求められる。

/etc/sysctl.conf によるネットワークスタックの極限チューニング

# --- Linuxカーネルネットワークスタック最適化 (IPsec/UDP-T対応) ---

# UDPバッファサイズの最大化（高スループット時のパケットドロップを防ぐ）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 262144
net.core.wmem_default = 262144

# パケット処理のキュー長を拡大（バーストトラフィック対策）
net.core.netdev_max_backlog = 10000

# IPsec処理におけるパケットフラグメンテーションとPath MTU Discovery (PMTUD) の最適化
# UDPカプセル化によるオーバーヘッド（8バイトのUDPヘッダー + 4バイトのNon-ESP Marker）を考慮する
net.ipv4.ip_no_pmtu_disc = 0
net.ipv4.tcp_mtu_probing = 1

# 暗号化処理の並列化を促進するスケジューラ設定（ハードウェアアクセラレーション有効化前提）
# AES-NI命令セットが有効なCPU環境において、crypto層のキュー効率を最大化

これらのパラメータを設定した上で、以下のコマンドで即座に反映させる。

# 設定をカーネルに適用する
sudo sysctl -p

—

4. セキュリティスペシャリストが仕掛けるべき要塞化設定

UDPポート 500 と 4500 をインターネットに公開するということは、世界中のボットネットからの総当たり攻撃（Brute-force attack）や、IKEv2実装の脆弱性を狙ったスキャニングの標的になることを意味する。

境界防御の観点から、これらのポートを守るための実践的な設定例を見ておこう。以下は、StrongSwan（charon）を使用する際の ipsec.conf の堅牢化設定例である。

/etc/ipsec.conf のセキュアな設定サンプル

config setup
    # プラグインのロード設定やデバッグレベルの指定
    strictcrlpolicy = yes
    uniqueids = yes  # 同一ユーザーによる多重ログインを制御し、セッションハイジャックを防止

conn %default
    # 現代の暗号スイート（AEAD: Authenticated Encryption with Associated Data）を強制する
    # 従来のCBCモードではなく、GCMモードを使用することで処理速度と安全性を両立
    ike = aes256gcm16-prfsha512-ecp384!
    esp = aes256gcm16-ecp384!

    # ライフタイムの管理
    keyingtries = %forever
    ikelifetime = 24h
    lifetime = 8h

    # MOBIKE（シームレスなネットワーク切り替え）の有効化
    mobike = yes

    # NAT-Tを強制、あるいは自動検知させる
    forceencaps = yes  # すべてのトラフィックをUDP/4500に強制し、ファイアウォールルールをシンプル化する

さらに、OS側のファイアウォール（nftables または iptables）において、UDP 500/4500に対するレートリミット（Rate Limiting）を必ず実装すべきだ。DDoS攻撃によるCPUリソースの枯渇を防ぐための防壁となる。

# nftablesを用いたUDP 500/4500へのレートリミット設定例
# 1秒間に過剰なパケットを送ってくるスキャナーを一時的にドロップする
table inet filter {
    chain input {
        type filter hook input priority filter; policy accept;
        
        # IKEv2 (UDP 500, 4500) に対する接続要求の制限
        udp dport { 500, 4500 } limit rate 10/second burst 20 packets accept
        udp dport { 500, 4500 } drop
    }
}

—

5. 結びにかえて

IKEv2のUDPポート 500 から 4500 へのダイナミックな移行、そしてNAT-TとMOBIKEが手を取り合って実現するモビリティの世界。それは単なる「プロトコルの仕様」にとどまらず、ハードウェアの進化、OSカーネルのメモリ管理、そして巧妙化するサイバー攻撃との終わりのない攻防の結晶である。

パケットのヘッダーが刻々と書き換えられ、ルーターの海を潜り抜けて暗号化されたデータがデバイスへと届く――その背後にあるメカニズムを解像度高く理解しているかどうかが、インフラエンジニアとしての強靭な武器となる。

セキュアで、かつ一瞬の遅延も許さない極限のネットワーク環境を構築するため、今日の夕方にも、あなたの手でsysctlとファイアウォールの見直しを行ってみてほしい。

スポンサーリンク

コメント

タイトルとURLをコピーしました