NAT 越しの L2TP/IPsec：実際に何が壊れるのか、なぜか

「NAT が L2TP/IPsec を壊す」という主張は半分だけ正しく、だから役に立たない。アドレス変換は普通のことで、NAT トラバーサルはまさにそれを生き延びるために存在し、毎日何百万ものクライアントがルーターの後ろから接続している。壊れるのは特定の交換の特定の段階で、IKE に応答が返らない、カプセル化されたトンネルが 単一のプロトコルしか許可しないポリシーで破棄される、あるいはトンネルがアイドルの間に変換マッピングが失効する。どの段階にいるか分かれば、修正はたいてい ひとつのルールか keepalive で済み、新しい VPN 設計は要らない。

神話は間違った問いだ

有用な問いは「NAT がこれを壊すか」ではなく、「交換のどの部分が変換され、変換する機器がそれをどう扱うか」だ。L2TP/IPsec は層状のプロトコルで、IKE が交渉し、ESP が保護し、そして L2TP がその保護の内側で PPP を運ぶ。アドレス変換は層ごとに働きが違い、エラーダイアログではなく交渉段階を見れば障害の兆候は区別できる。

Web を問題なく閲覧できるルーターが証明するのは、送信元ポート変換つきの TCP が動くことだけだ。UDP 500、UDP 4500、プロトコル 50 については何も語らず、この配備はその三つに依存している。

ステージ 1：IKE がそもそも応答を受け取れること

最初の交換は UDP 500 で応答側に届く。応答が返らなければ、事前共有鍵も提案も資格情報も読まれないままで、ほかに意味のあるものはない。クライアントのタイムアウトから推測せず、要求と応答を見よう：

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

応答のない要求は、通常、ファイアウォールか上流のキャリアがパケットを捨てているという意味で、サーバーが拒否したのではない。提案や証明書の問題を名指しする notify ペイロード付きの応答は、パケットが届いて交渉が内容で失敗したという意味で、これはまったく別の修理になる。

両端が変換の後ろにいる場合、開始側は応答側に届きさえすればよいので、クライアント側の配備のほとんどはステージ 1 から動く。サーバー側のホスティングが受信の問題の始まる場所であり、だからこの二つの状況を一つとして論じてはいけない。

ステージ 2：カプセル化がファイアウォールの見え方を変える

ESP は IP プロトコルであって TCP や UDP のポートではなく、通常のポートアドレス変換には書き換えるべきポートフィールドがない。だから NAT トラバーサルは保護されたペイロードを UDP 4500 に移し、カプセル化によって変換する機器は変換の仕方を知っているものを受け取る。そうなると、UDP 500 だけを許可したファイアウォールルールは 交渉を許可しトンネルを落とすことになり、ログにはフェーズ 1 の成功とトラフィックなしという不可解な結果が残る。

IKE の交換自体も、NAT を検出した後に UDP 4500 へ移ることがあり、500 だけを許可していた人を驚かせる。経路上で両方のポートを双方向に許可し、ステートフルファイアウォールはトラフィックを見ている間しかフローを保持しないことを覚えておこう。

プロトコル 50 は変換のない経路でも、中間装置が許可するよう設定された経路でも依然として重要だ。消去法で切り分けるなら、ルールをまとめて足すのではなく仮説を無効にしよう：500、4500、ESP を許可し、トンネルが上がることを確認してから、不要だったものを外す。誰も説明できないルールは、次の障害の原因になったときに誰も外さないルールだ。絞り込みは直した段階とともに変更記録に書き、次のエンジニアが同じ経験則ではなくあなたの証拠から始められるようにする。

ステージ 3：マッピングが失効し、トンネルが死ぬ

変換する機器は転送するフローの状態を保持し、その状態には寿命がある。L2TP/IPsec のトンネルは誰も使っていないときはほとんどトラフィックを運ばないので、アイドルのトンネルはマッピングより長生きして戻りのトラフィックを受け取れなくなる。クライアントは接続していると思い込み、サーバーには何も見えず、最初の症状はたいてい VPN のエラーではなくアプリケーションのタイムアウトだ。

死んだピアの検出と NAT keepalive はこのためにあり、両端がそれを送る用意がなければならない。サーバーが変換の後ろにある場合、Windows 側の要件は、サーバーが自分の送信パケットに UDP カプセル化を前提とするようにする文書化されたレジストリ設定だ；それがなければ応答側は ESP を送り、変換する機器はそれを戻せない。これはサーバーの設定の問題で、クライアントの問題ではない。

WAN アドレスが変わると、別の方向から同じ結果になる：マッピングは新しいアドレスの周りで作り直され、古いセキュリティアソシエーションはもう存在しない組を指したままになる。再接続の挙動はクライアントの実装に属し、だから「ルーター再起動後に再接続」があるクライアントでは動き、別のクライアントでは手動の切り替えが要る。

キャリアグレード NAT の後ろでホストするのは別の問題だ

自宅で L2TP/IPsec サーバーをホストして外から届きたいなら、必要なのは求められていない受信到達性であり、それは NAT トラバーサルが提供するものではない。ルーターの前にキャリアグレード NAT があると、公開アドレスは共有されマッピングは送信専用なので、転送して到達可能にできるポートは存在しない。

IPsec パススルーのチェックボックスでは変わらず、どれだけクライアントを設定しても埋め合わせはできない。対応策は、実際に到達可能なアドレス、ホストされたエンドポイント、または全員が送信接続を行うアーキテクチャだ。UDP カプセル化の仕様は存在するフローの変換問題を解くが、キャリアが提供しない受信経路を作るものではない。

だから推測せずネットワークを比べよう。同じ機器と同じプロファイルを別の許可されたネットワークに持ち込み、そこでどの段階が失敗するかを見る。ほかで動くなら違いは経路にあり、それで調査は設定全体ではなく上記の三段階に絞られる。