境界防御の幻想と現実：NATトラバーサルでハマる「見えない壁」を突破せよ
ネットワークエンジニアの皆さん、お疲れ様です。VPNを構築していて、「なぜか接続だけが確立しない」「パケットは飛んでいるはずなのに、応答がない」という悪夢にうなされたことはありませんか？
特に、IPsec VPNをNAT環境下に持ち込んだ時の挙動は、多くのエンジニアを深夜のトラブルシューティングへと引きずり込む魔物です。今日は、教科書には載っていない「NATトラバーサル（NAT-T）」の泥臭い挙動と、現場で確実に原因を切り分けるためのデバッグ術を叩き込みます。
—
1. なぜ「NAT」がVPNの敵なのか
IPsecは本来、OSI参照モデルのネットワーク層（レイヤー3）を保護するプロトコルです。しかし、伝統的な ESP（Encapsulating Security Payload）パケットには、TCPやUDPのような「ポート番号」という概念がありません。
NATルーターは、内部プライベートIPアドレスをパケットヘッダーから書き換える際に、ポート番号を追跡（NAPT）します。しかし、ポート番号を持たない ESP を見ると、ルーターは「一体どのセッションのパケットだ？」とパニックになり、パケットをドロップするか、うまく変換できずに接続を破壊してしまうのです。
これを解決するのが NAT-T（NAT Traversal） です。
2. NAT-Tのメカニズム：UDP 4500へのカプセル化
NAT-Tの役割はシンプルです。「ESPパケットを、UDPヘッダーという『ポート番号付きの箱』に包んで運ぶ」 ことです。
通信シーケンスのリアル
1. IKEフェーズ1（ISAKMP）: 最初に UDP 500 でネゴシエーションを行います。
2. NAT検出: 双方で NAT-D（NAT Discovery）ペイロードを交換し、「経路途中にNATが存在するか？」をハッシュ値で検証します。
3. カプセル化の開始: NATの存在が確認された瞬間、IKEは UDP 4500 へとポートを切り替え、以降のESPパケットは UDP 4500 で包まれて転送されます。
ここで重要なのは、「経路上の全ての機器がUDP 4500を通過させる設定になっているか」 という点です。
3. 実践トラブルシューティング：パケットを「視る」
VPNが繋がらない時、管理画面を眺めていても解決しません。まずはパケットをキャプチャし、泥臭く追いかけましょう。
tcpdumpによるデバッグ手法
現場で最も信頼できるのは、やはり tcpdump です。以下のコマンドで、NAT-Tの動きを可視化します。
# UDP 4500 (NAT-T) のパケットをキャプチャする
tcpdump -ni eth0 udp port 4500 -vvここで Non-ESP Marker という文字が見えれば、NAT-Tが正しく機能しています。もし 500 で止まっているなら、そもそもフェーズ1でネゴシエーションが失敗しています。
IPsec設定ファイル（StrongSwan例）のポイント
LinuxでStrongSwanを運用する際、NAT-Tを明示的に制御するパラメーターがこちらです。
# /etc/ipsec.conf の設定例
conn my-vpn
# NAT-Tを強制的に有効化する場合
forceencaps = yes
# NAT-T検出の頻度（Keepaliveの調整）
# NATルーターのセッションタイムアウト対策に必須
nat_keepalive = 20snat_keepalive を短くするのは現場の定石です。NATルーターが勝手にセッションを閉じてしまわないよう、VPN側から定期的にパケットを送り続ける（Keepalive）必要があります。
4. SSL-VPNのトラブル：MTUとパケット断片化
SSL-VPN（HTTPSベース）でも、同様に「パケットサイズ」が原因のトラブルが多発します。SSL-VPNはTLSでラップされるため、オーバーヘッドが大きく、物理的な MTU（1500）を超過してパケットが断片化（フラグメンテーション）され、ドロップされるケースが後を絶ちません。
PythonによるMTUチェックの自動化
自社のAPIサーバーや拠点間通信で、パケットが途中で欠けていないかを確認する簡単なスクリプトです。
import subprocess
# 特定のMTUサイズでpingを打ち、断片化による拒否が発生しないか確認
def check_mtu(target_host, mtu_size):
# DFフラグ(Don't Fragment)を立てて、強制的にパケットサイズを検証
cmd = ["ping", "-M", "do", "-s", str(mtu_size - 28), target_host, "-c", "1"]
try:
subprocess.check_call(cmd)
print(f"MTU {mtu_size} は通過可能です。")
except subprocess.CalledProcessError:
print(f"MTU {mtu_size} でパケットがドロップしました。調整が必要です。")
# 1300〜1500の間で調整を試みる
check_mtu("192.168.1.1", 1400)5. まとめ：エンジニアとしての矜持
VPNのNATトラバーサル問題は、単なる設定ミスではなく、「ネットワークの境界がどこにあるのか」 を意識させる良質な障害です。
- IKEフェーズ1（UDP 500）が通っているか？
- UDP 4500への切り替え時にNATがパケットを落としていないか？
- MTUサイズによって大きなパケットが消失していないか？
これらを順を追って切り分けることができれば、どんな複雑なエンタープライズ環境であっても、必ず解決の糸口は見つかります。
「なぜ動かないのか」と悩む時間を、「パケットがどう旅をしているのか」を想像する楽しみに変えていきましょう。それが、境界防御を極めるための第一歩です。それでは、また次回の現場でお会いしましょう。
コメント