VPN トラフィックにおける ASA identity NAT と IOS NAT 除外の違い

支店ではインターネット向け PAT と拠点間 VPN を同じ Cisco ゲートウェイで運用しており、NAT を追加した瞬間に VPN が機能しなくなります。トンネル内のアドレスが crypto ACL の保護対象と一致しなくなるか、対向側が経路を持たない変換後のアドレスを見ているのです。Cisco はこれを二か所で解決します。ASA はアドレスを自分自身に写像する NAT ルールを選び、IOS は ACL の deny によってフローを変換ルールの外に保ちます。どちらも元のアドレスを保持し、どちらも NAT 処理を迂回するものではありません。

ルールを選ぶ前にフローを記録する

保護したいフローをまず書き出します。ローカル LAN の送信元、リモートの宛先、そして IPsec ポリシーが保護する正確なアドレス対です。ルールを編集する前にこれを行うのは、この組み合わせがどの分類子や NAT ルールに一致すべきだったかを示すからです。

次に、意図したルールではなく、実際に一致したルールを探します。どちらのプラットフォームでも NAT は順序に従って評価され、例外が検討される前に先行するルールが勝つことがあります。正しく見える例外でも別のルールに負ければ、期待したパケットが保護ポリシーに渡ることはありません。症状は例外の欠落とまったく同じなので、設定を変える前にルールの順序を読む必要があります。

ASA の identity NAT はルールであり、迂回ではない

ASA では、identity NAT は変換後のアドレスが元のアドレスと等しい NAT ルールです。他のルールと同じように選択され、変換エントリも作成されるため、パケットが NAT 処理を飛ばすわけではありません。変わるのはネットワーク上のアドレスが同じまま保たれる点であり、これが IPsec ポリシーの要求です。

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

ルールのインターフェースと route-lookup の設定は転送設計と一致している必要があります。アドレスを正しく写像していても、誤ったインターフェース対に適用されたルールは対象フローに選択されません。route-lookup は変換後のパケットをルーティングするか元の宛先を使うかを決め、それが戻りトラフィックがトンネルを通るかどうかを左右します。

ASA 自体への管理アクセスは別の話です。管理トラフィックに identity NAT を使う場合、リリース固有の route-lookup 要件が適用され、VPN の例からコピーした広い例外では SSH は直りません。

IOS の NAT ACL における deny はここでは選択されないという意味

IOS ではインターネット向け NAT は送信元リストで制御され、その ACL はフィルタではなく分類子です。permit 行は変換対象のトラフィックを選び、deny 行はそのパケットがここでは選択されないことを意味します。この deny は、インターフェース ACL の deny のようにパケットを破棄する指示ではありません。

ここでは選択されないは、どこでも変換されないよりも狭い意味です。別の NAT ルール、別のインターフェース、あるいは route-map がフローを変換できるため、NAT テーブル全体を読む必要があります。パケットには経路、一致する crypto ACL、実際のアクセス制御境界での許可も依然として必要です。

最小構成の IOS では、同じリストの permit より上に deny を置き、overload ルールをそのリストに向けます。すると crypto ACL は deny が変換から除外したのと同じ対を保護します。

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

両モデルに共通する検証可能な問い

どちらのモデルも同じ問いに答えます。どのルールがこのフローに一致したのか、どのアドレスがインターフェースを出たのか。外部インターフェースで取得し、ゲートウェイの前後で送信元アドレスを比較します。次に対向側から見たトンネルを確認します。SA が上がっていても、保護対象のフローが別の場所で変換されていることがあるからです。

ASA では nat detail と変換テーブルを、IOS では ip nat translations と対応する ACL カウンタを表示します。まったく増えないルールは一度も選択されておらず、それは crypto の設定ではなく順序、インターフェース、方向を示しています。

設定がつまずく場所

よくある失敗は機械的なものです。deny が permit の下にあり決して一致しない。分類子が誤った方向に適用され、戻りのフローが変換される。identity ルールが正しいアドレスを対象にしていてもインターフェース対が誤っている。crypto ACL が NAT ルールの提示する内容と一致しないサブネットを保護している。

元のアドレス対と提示されるアドレス対をルールの担当者のそばに記録し、次の技術者がなぜ分類子が変換を拒否するのにファイアウォールがアプリケーションを許可するのかを理解できるようにします。それは個人メモではなく変更チケットに残してください。その後、NAT を変更するたびにフローを再実行します。ルールの文言が変わらなくても順序は設定の一部だからです。トンネルが上がったことはアドレスが保たれた証拠ではありません。取得したパケットと対向側のカプセル解除後の見え方だけが証拠です。