Azure サイト間 VPN と NAT 背後のピア:確認チェックリスト

以下の確認を順番に実施し、最初に失敗したところで止める。Azure が NAT 背後の機器をサポートしないという報告の多くは、実際には Azure から到達できないピアアドレスか、正しい側から決して開始されないトンネルである。外側のトランスポートと内側のルーティングは別の問題であり、混同すると半日を無駄にする。以下の各手順は、そのまま他の人に渡せる観察結果を生む。

手順 1:NAT の背後にピアがあること自体を確認する

機器の WAN インターフェースのアドレスと、Azure がその機器に対して見ているアドレスを比較する。両者が異なるなら、どこかで変換が行われており、その変換器はすでに VPN 設計の一部である。プロバイダーに、マッピングが固定か共有かを確認する。共有マッピングは何を前提にできるかを変えるためだ。プライベートな WAN アドレスを持ち転送のない機器は、安定したパブリックマッピングを持つキャリアグレード NAT 背後の機器とは別のケースである。

二つのアドレスが一致するなら、ここで止める。NAT は問題ではなく、このリストの残りは役に立たない。

両方のアドレスと変換器の型番をチケットに記録する。この一行が、設定したピアが応答しない理由をめぐる次の質問攻めを防ぐ。

手順 2:どちらが開始するかを合意する

Azure VPN Gateway の FAQ は NAT-T のサポートを述べ、オンプレミス機器が NAT の背後にある場合は IPsec トンネルを開始すべきだと付け加えている。これはステートフルな変換の仕組みと一致する。内側の機器が最初のパケットを送ったからこそ、変換器がマッピングを保持するのだ。Azure が開始することを期待し、そのマッピングを作るパケットが届かなければ、トンネルは決して始まらない。

応答側のみという誤りが明白になるようにピアを設定し、機器が自力で再試行するのか、トリガーが必要なのかを確認する。興味深いトラフィックが現れたときだけトンネルを張る機器もあり、それは興味深いトラフィックが決して来ないヘルスプローブになるまでは問題ない。

手動開始の間に機器の IKE 交換を観察する。そこでの沈黙はルーティングかファイアウォールの答えであり、Azure の答えではない。

手順 3:ピアアドレスを正しく設定する

Azure はローカルネットワークゲートウェイオブジェクト内のピアに到達可能なパブリックアドレスを必要とする。通常は機器の内側アドレスではなく変換器のパブリックアドレスだ。機器が認証に使う ID は別のフィールドであり、Azure が発信するアドレスと合法的に異なってよい。両者を取り違えないこと。入れ替えると、NAT の問題とまったく同じに見える認証失敗が起きる。

パブリックアドレスが変われば、このオブジェクトも一緒に変える必要がある。古いアドレスに解決する名前は、手作業で更新が必要な固定アドレスより悪い。

三つの値を書き留める。機器のローカルアドレス、変換後のパブリックアドレス、設定したピア ID である。

手順 4:NAT-T に必要なポートだけを開く

NAT-T は ESP を UDP の中に運び、RFC 3948 はポート 500 での初期ネゴシエーション後にポート 4500 を使うカプセル化を記述している。ファイアウォールと変換器の両方が、この交換と戻りのトラフィックを許可する必要がある。無関係な TCP ポートを許可してもこの経路については何も証明できず、送信だけを許可して応答を許可しないルールはやはり失敗する。

ピアが開始し変換器が状態を保持する場合、固定の受信ポート転送は自動的には必要ない。必要になるのは、マッピングが不安定なとき、または経路上の何かが状態を積極的に失効させるときだ。

変換器の両側で一度ずつキャプチャする。カプセル化の違いはすぐに見える。

手順 5:外側のトランスポートと内側のルーティングを分ける

確立しても何も運ばないトンネルはルーティングの問題であり、NAT-T の問題ではない。サイトには依然として互換性のあるトラフィックセレクタ、一致するアドレス空間、アクセスルール、アプリケーションネットワーク向けの戻り経路が必要だ。IKE 交換の成功がこれらを提供するわけではない。

二つのサイトが重複するプライベート範囲を使う場合、トンネル内での変換は独自のルールを持つ別設計である。外側のゲートウェイがたまたま家庭用ルーターの背後にあるからといって、サブネットを再番号付けしないこと。

何かを変える前に、失敗を段階で分類し、その分類をチケットに残す。そうすれば次の人が、あなたが止まったところから始められる。