スプリットトンネルは公開ホストを ASA の NAT ルールから免除しない

スプリットトンネリングは通常、社内トラフィックをトンネル内に、残りのインターネットをファイアウォールの外に保つ方法として説明される。その説明のどちらの半分も同じように間違っている。スプリットトンネリングはクライアントが下すルートの判断であり、ルートの判断は、パケットがヘッドエンドに届いた後に何が起きるかについては何も語らない。

本社のアドレスを見ることを譲らない、公開アドレス上のパートナーサービスが一つあるだけで、その話は崩れる。

神話: スプリットトンネルはファイアウォールを経路から外す

信じられているのは、プライベート範囲の外にある宛先はローカルのインターネット接続に残るので、ファイアウォールはそれを見ることも、ルールを必要とすることもない、というものだ。それが成り立つのは、宛先がトンネルリストにない間だけである。運用者が公開ホストを split-include ACL に追加した瞬間、クライアントはそのトラフィックをトンネルに送り、ASA は他の復号済みフローと同様にルーティング、フィルタリング、変換を行う必要がある。クライアント側で変わったのは宛先リストだけだ。

クライアントがルーターになったわけではない。与えられたポリシーに従っただけだ。

split-include ルートが実際に行うこと

Cisco ASA のリモートアクセス構成では、グループポリシーが split-tunnel-policy tunnelspecified と、標準 ACL を指定する split-tunnel-network-list を持つ。その ACL の各 permit 行はクライアントがトンネルに送るべき宛先であり、それ以外はすべてローカルのデフォルトルートを使い続ける。

ホストを一つ追加するのは一行であり、クライアントが見られる変更はそれだけだ: access-list RA-SPLIT standard permit host 203.0.113.20。

その後クライアントを再接続する。ポリシーは接続時に交換されるため、確立済みのセッションは古いリストを保持し、変更が何もしていないように見える。

パケットは同じインターフェースから出入りする

復号後のフローを追ってみる。パケットは VPN トンネル経由で外部インターフェースに入り、宛先は公開アドレスであり、ルーティングテーブルは同じ外部インターフェースからインターネットへ向けて送り返す。一つのインターフェースに出入りするトラフィックは、same-security-traffic permit intra-interface による許可がない限り破棄される。これがないと、接続はルーティング問題に見える形で失敗するが、実際はそうではない。

この設定はグローバルだ。必要とするすべてのフローにヘアピンを許可するのであって、このパートナーホストだけではないため、迅速なテストではなくレビュー済みの変更に属する。

宛先限定の PAT が任意でない理由

復号されたパケットの送信元アドレスは依然としてクライアントの VPN アドレスで、通常は 10.77.0.0/24 のようなプールから割り当てられる。そのアドレスはパブリックインターネット上にルートを持たないため、パートナーは決して応答しないか、どこにも届かない応答をする。

変換は送信元を修正し、宛先はそのままにする。オブジェクトはすでに別の場所で定義されているので、この宛先に限定した手動ルールは次の形になる:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

destination static の部分が重要だ。これを外すと、ルールは意図よりはるかに多くのトラフィックに一致しうる広い変換になり、順序で先にある広い identity ルールがこれを完全に上回ることがある。自分のルールが一致していると決めつける前に、show nat detail とセクションの順序を確認すること。

インターフェース PAT は、パートナーが ASA のインターフェースアドレスを見ることも意味し、それは上流で再度変換される可能性がある。契約がアドレスを指定しているなら、一つのホップではなく端から端まで確認すること。

正しいテスト宛先で証明する

汎用の what-is-my-ip ページではなく、パートナーホスト自体を使う。そのページはほぼ確実に split リストの外にあるので、ローカルのインターネットアドレスを報告するだけで、この経路については何も語らない。パートナーサービスへの新しい接続を開き、どの送信元を観測したか尋ねるか、packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed を実行して NAT とルーティングの各段階を行ごとに読む。クライアントからの traceroute は、すでに起きた経路を示すだけで、それを選んだポリシーは示さないため、弱い確認だ。

次に、変わってはならないものを確認する。通常のウェブサイトは依然としてローカル接続から出る必要があり、トンネルリスト内のプライベートリソースは依然として到達可能でなければならない。パートナーを直してそのどちらかを壊す変更は、別のバグだ。

この設計の動作する版は、split ACL のホスト一つ、ヘアピンの許可、宛先限定の PAT ルール一つという短さだ。話の残りはすべて神話だ。