NAT 背後の FortiGate：local-gw、localid、パブリック IP

NAT 背後の FortiGate は、WAN インターフェース上で 10.0.0.2 を持ちながら、インターネット上では 198.51.100.40 として見えることがあり、どちらの数値も実在します。デバイスがバインドするアドレスと、IKE 認証中に送信する識別子は別々の選択であり、別々のフィールドで、別々の相手に向けて設定します。NAT は通過時に外側のアドレスを書き換えますが、認証済みの識別子を遠端のピアが期待する値に書き換えることはしません。この形でのフェーズ 1 の失敗の多くは、正しい値を誤ったフィールドに入れることから生じます。

三つの値、三つの所有者

まず三つの値と、それぞれの所有者を明確にします。local-gw は FortiGate が外部インターフェースで IKE の送信元として使うアドレスで、デバイスが実際に保持しているアドレスでなければなりません。パブリックエンドポイントは NAT デバイスのアドレスで、変換を行う側が所有します。IKE 識別子はピアが自身の設定と照合する文字列であり、IP アドレスである必要はまったくありません。

フィールド名が似ているため置き換えたくなりますが、そこが落とし穴です。localid と localid-type は識別を表し、local-gw はローカルバインディングを表します。

例で違いを具体的にします。FortiGate で config vpn ipsec phase1-interface を開き、次に set interface "wan1" と set local-gw 10.0.0.2 を設定します。これは機器が所有するアドレスであり、これが IKE ソケットのバインドを成功させます。local-gw を 0.0.0.0 のままにするとインターフェースアドレスが使われ、通常は同じですが明示的ではありません。local-gw を 198.51.100.40 に設定してはいけません。デバイスがそのアドレスを所有しておらず、ソケットはバインドできません。二つの値を紙の上で同じに見せることは設定ではありません。

ステップ 1：ピアが受け入れる識別子を選ぶ

次に識別子です。これは別の判断です。set localid はピアが比較する値を取り、set localid-type は FortiGate にその解釈方法を伝えます。アドレス、FQDN、ユーザー FQDN、キー ID のいずれかです。auto の場合、デバイスは通常、送信インターフェースのアドレスからそれを導出します。これはまさに NAT デバイスが変更しようとしている値です。

この導出こそ、このトポロジで明示的な識別子が重要な理由です。ピアがアドレス識別子を期待するなら、localid-type address と localid をピアが見るパブリックアドレスに設定し、ピアがその値をルーティング先ではなく識別子として受け入れることを確認します。ピアが FQDN を期待するなら、localid-type fqdn と設定時の名前を使います。実際に何が送られたかは diagnose vpn ike gateway list で確認します。これは意図した入力ではなく、ゲートウェイの状態と使用中の識別子を表示します。識別子タイプのオプションが任意の非ローカルアドレスを受け入れると決めつけず、まずリリースの文書化された意味論を確認してください。

ステップ 2：UDP 500 と 4500 をデバイスへ転送する

三つ目の値は NAT デバイスに属し、見落とされがちなものです。パブリックエンドポイントは UDP 500 と UDP 4500 を FortiGate へ転送する必要があります。NAT-T の検出とその後に続くカプセル化 ESP は、どちらもこれらのポートの到達に依存します。この設計が前提とするのは一対一のマッピングです。単一のパブリックアドレスを複数のピアでポート単位に共有するのは、別の制約を持つ別のトポロジです。

転送は願望ではなくキャプチャで確認します。diagnose sniffer packet any "udp port 500 or udp port 4500" 4 はパケットが到着しているか、応答が出ているかを示します。

Google Cloud VPN は、NAT 背後のピアに対して NAT-T を用いた一対一 NAT をサポート構成として文書化しており、遠端が Cloud VPN ゲートウェイならこの制約に沿って設計する必要があります。一対多やポート単位の共有は同じサポート構成ではなく、ローカル識別子の調整では変わりません。遠端が別の機器なら、その機器の文書が識別子として何を受け入れるか、変換されたピアアドレスを許容するかを定めています。ローカルフィールドを変える前にそれを読みましょう。ローカル側は、遠端が実装していない規則を交渉することはできません。

ステップ 3：フェーズ 1 が解決しないことを確認する

NAT トラバーサルはトンネルを確立し、識別子の一致がピアの受け入れを決め、内側プレフィックスのルーティングが実際に何が通るかを決めます。正しいローカル ID は、欠けた静的ルートや欠けたトラフィックセレクタを補えません。

したがって層ごとに確認します。get vpn ipsec tunnel details はトンネルが確立しているか、どのセレクタが交渉されたかを示します。設定した遠端サブネットと交渉されたセレクタの不一致は、フェーズ 2 の衣装を着たルーティング問題です。execute vpn ike gateway clear は再交渉を強制するので、最後の変更前に確立したセッションではなく現在の設定を試験できます。次に遠端プレフィックスのホストへ通信を送り、カウンタが動くことを確認します。確立していても何も通さないトンネルは、確認するまで正常なものと見分けがつきません。

三つの値をノートの一か所にまとめておきます。デバイスが持つローカルアドレス、NAT デバイスが提示するパブリックエンドポイント、ピアが期待する識別子文字列です。これらは別々の理由で、別々のタイミングで変わります。

NAT デバイスの再採番は FortiGate の local-gw に触る理由ではなく、識別子の変更は何かを再採番する理由でもありません。両者を混同すると、無関係なメンテナンス時間に稼働中のトンネルを作り直すことになります。Cloud VPN の NAT ガイダンス が、その側でサポートされるトポロジの参照先です。

決着をつける試験は地味で速いものです。外部インターフェースでキャプチャし、ピアから UDP 500 と 4500 が届くことを確認し、IKE 交換の識別子がピアの期待設定と一致することを確認し、交渉されたセレクタが対象のサブネットを覆うことを確認します。最初の確認が失敗すれば NAT デバイスが疑わしく、二つ目が失敗すれば識別子フィールド、三つ目が失敗すれば NAT も識別子も問題ではなかったということです。