Cisco ASA のトンネル既定ルート：実際に適用されるのはどんなときか

リモートアクセス利用者が ASA の先へ何も到達できないのに、同じサーバーは内部 LAN からの ping には応答する。トンネルは確立し、クライアントはプールからアドレスを受け取るのに、パケットは今もインターネットの既定ルートから出ていくか、消えてしまう。このパターンは通常、復号されたトラフィックが自前のルートを見つけられず、通常の既定ルートに落ちたことを意味する。修正は別の NAT ルールではなく、トンネル既定ルートである。

設定ではなく症状から始める

パケットがどこへ行くかを見る。どこへ行くと思っていたかではない。失敗したセッション中に外側インターフェイスで取得したキャプチャには、プールのアドレスを保ったまま復号パケットが ISP のゲートウェイへ向かう様子が写るか、ルックアップが失敗して何も写らないかのどちらかである。いずれにせよ、トンネルが問題ではない。

show vpn-sessiondb ではトンネルは健全に見える。だからこそ人々は IKE のデバッグを続けてしまう。

これを ACL ドロップと分けるのは方向である。ACL ドロップはログに記録されカウントされるが、ルートが欠けている場合は一致するエントリのないルックアップ失敗になる。クライアントの宛先に対して show route を実行し、ASA が実際に何を選んだのか、既定ルートが選ばれたかどうか、選ばれたならどれかを読み取る。

トンネル用ルックアップはどう違うか

Cisco の ASA 9.23 静的ルーティングガイドには、静的ルートも学習ルートも持たない復号 VPN トラフィック用の別個の既定ルートが記載されている。tunneled キーワードがそのルートを示すため、復号パケットは ASA 自身のトランスポートに使うネクストホップとは別のネクストホップへフォールバックできる。より具体的なルートは依然として優先されるので、クライアントは内部ゲートウェイ経由で 10.0.0.0/8 には到達できても、それ以外はすべて失う。

最小構成では、ネクストホップの異なる二つの既定ルートを保持する。一方は ASA 自身のトラフィックを、もう一方はより良いルートを持たない復号トラフィックを運ぶ。どちらのネクストホップも、接続するインターフェイスから到達可能でなければならない。

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

両方の既定ルートが同じネクストホップを指すなら、キーワードは何も変えず、症状も動かない。

機能するかどうかを決める制約

同じガイドはトンネル既定ルートを一つだけ許可し、ECMP はサポートされないと明記しているので、そのパスで負荷分散はできない。さらにルートトラッキング、リバースパス検証、一部のインスペクションや管理フローに関する制約も挙げている。機能を前提に設計する前に、導入済みのリリースに照らして読むこと。これらを無視した設計は通常、どこでもではなく特定の一点で失敗する。症状が断続的に見えるのはそのためだ。

非対称な設計で効いてくるのはリバースパス検証である。応答が ASA の期待するインターフェイスとは別のインターフェイスから届くなら、ルーティングが問題になる前にパケットは破棄される。検証を無効化してネクストホップを強制するのではなく、トポロジーか戻りパスを直すこと。

ルートトラッキングは別の罠である。追跡対象のオブジェクトは通常、トンネル既定ルートではなく通常の既定ルートを守っている。

キーワードがしないこと

IKE を構築するために ASA が使う送信元アドレスを選ぶわけではない。外側のトンネル端点はプラットフォーム自身のインターフェイス選択と送信元選択に従い、トンネル既定ルートはその判断に関与しない。これを変えても、誤ったアドレスを送信元とする phase 1 は直らない。

ネクストホップをプロキシに変えるわけでもない。宛先が HTTP CONNECT のやり取りを期待している場合、生の IP パケットをプロキシホストへ送っても、それをルーティングしないホストが手に入るだけだ。代わりにクライアントが対応するプロキシ方式を設定すること。

そして下流の転送を作るわけでもない。指定したゲートウェイには、VPN プールへの戻りルートが依然として必要であり、設計が求める箇所では送信元変換も必要である。

パスを端から端まで検証する

ルートを入れたら、順に四つを確認する。プールが必要とする宛先に対する show route、新しいネクストホップへ向かうインターフェイスでのキャプチャ、ゲートウェイ自体でのキャプチャ、そしてそのゲートウェイからプールのアドレスへの戻りパスである。最初の二つは ASA がそのパスを選んだことを、最後の二つはそこで誰かが応答していることを証明する。

ゲートウェイが応答するのにクライアントに応答がまったく届かない場合は、ルーティングテーブルに再度触る前に送信元変換と戻りルートを確認すること。

検証したリリースを記録しておくこと。制約の一覧はバージョン固有であり、あるトレインで動く設計が別のトレインでは別のパスを必要とすることがある。そのメモは設定スニペットより長く生き残る。