IOS VPN出口でNATの内側と外側を受け持つインターフェースはどれか

フルトンネルのインターネット出口を提供するルーターは、一見一つに見える二つの仕事を担います。トンネルを終端し、復号したクライアントパケットをインターネットへ転送します。変換が必要なのは二つ目の仕事だけで、その変換は内側のフローに一致しなければなりません。この区別が、どのインターフェースがNATの役割を担い、どのアドレス範囲がルールに現れるかを決めます。

パケットを一つ、ルーターを通して追う

10.90.0.25 のクライアントが公開HTTPSサービスを開く場面を考えます。その宛先がそもそもトンネルに入るかどうかは、クライアント自身のポリシーの判断です。入ると、ルーターはパケットを復号して仮想インターフェースへ渡し、そこから公開アップリンクへルーティングされます。

その仮想インターフェースが変換の内側です。公開アップリンクが外側です。役割が逆になっていたり欠けていたりすると、パケットはプライベートな送信元のまま出ていくか、変換される前に破棄されます。

変換ポリシーをクライアントプールに合わせる

NATルールには、クライアントが実際に受け取る範囲を書き、たまたま同じアップリンクを共有しているオフィスLANを書いてはいけません。ローカルサブネットだけを対象にしたルールでは、両者が同じインターフェースから出ていても、遠隔のクライアントを取りこぼします。

ip access-list extended NAT-TUNNEL
 permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overload

プライベートサイト向けの例外は別に保ち、内部宛先への通信は元の送信元を保持する必要があります。そうしないと、宛先は到達できないアドレスへ応答し、戻りの経路はルーティングループのように見える形で失敗します。

役割は、展開された設計の実際のインターフェースに適用します。古いEasy VPNの回答からコピーしたVirtual-Templateの断片は完全な現在の設定ではなく、使われているトンネル種別が、復号パケットをどのインターフェースが受け取るかを決めます。

外側の転送と内側の変換を分けて考える

復号されたアプリケーションの送信元を変換することは、IKEや保護されたパケットを上流のNAT装置に通すことと同じ操作ではありません。前者はインターネットがクライアントの要求の送信元として何を見るかを変え、後者は中間装置を越えてトンネルを維持します。

両者を混同すると、典型的な二つの障害が生じます。自身のトンネル転送を変換するルーターはピア関係を壊し、内側のフローを決して変換しないルーターはプライベートアドレスをインターネットへ転送します。ルールを編集する前に、どちらのフローを見ているかを読み、変更後にトンネルが上がったままか確認します。閲覧を直しつつトンネルを落とすルールは、問題を解決せずに移しただけです。

どちらの障害も、もう一方を変えることでは直りません。ルールを編集する前に、どちらのフローを見ているかを読みます。

両方の境界で検証する

インターネット側の境界でアプリケーションの送信元を、戻りの経路で復元された宛先を読みます。前者は変換が起きたかを、後者は逆マッピングが正しいクライアントへ戻ったかを示します。

次に、承認されたスプリットトンネルの経路を使うクライアントを試します。そのクライアントはこのルーターのインターネット変換を一切通らないため、挙動が異なるはずで、その違いが通信がどちらの経路を通ったかを裏づけます。

両方のクライアントが同じように振る舞うなら、スプリットトンネルのポリシーは設計どおりに動いていません。使われていない経路向けに書かれたルールは本当の問題を隠すので、変換ルールを増やす前にそれを直します。