Cisco ASA から Azure VPN へ:トラフィックセレクターのプレフィックスペア
ASA から Azure VPN への接続を契約として書き下す。接続モデル、正確なプレフィックスペア、セレクターの検証、そしてロールバックまで。リリースに合わせたランブック。
トンネルは上がり、IKE は正常に見えるのに、そこを何も通過しない。これが ASA から Azure へのセレクター問題のよくある形であり、どちらのコンソールにも触れる前に私が契約を書く理由でもある。契約は四つで成り立つ。各ピアを識別するオブジェクト、接続モデル、正確なプレフィックスペア、そして各ペアを証明する検証だ。ここを間違えると、以降のすべてのコマンドは、本来構築すべきでなかった設定のデバッグに費やされる。このランブックは私が使う順序であり、どのオブジェクトが実際に間違っているかを示すコマンドを添えている。
設定する前に四つのオブジェクトを書き出す
まず ASA のリリースとプラットフォーム、公開エンドポイント、Azure VPN ゲートウェイの種類と SKU、そして自分の側を表すローカルネットワークゲートウェイから始める。これら四つの名前は、以降のすべての語彙であり、何かが壊れたときにはそれぞれ別の担当者がいる。
そのうち二つがまだ推測なら、止まる。ローカルネットワークゲートウェイのプレフィックス一覧が間違っているのは、チューニングの問題ではない。
接続モデルを一つ選び、テンプレートの混在をやめる
crypto map の設計と tunnel interface の設計は別の設定であり、片方のテンプレートは、ピアアドレスを編集しても他方に対して有効にはならない。何かを貼り付ける前に、どちらを構築しているかを記録する。不一致は後で設定エラーではなくセレクター問題として現れるからだ。Microsoft の ASA 相互運用ガイド は両方のパターンを扱い、それぞれがどの Azure ゲートウェイモデルを前提とするかを明記している。メモにモデル名がなければ、まだ設計はない。
ポリシーベースのトラフィックセレクターを備えたルートベースの Azure ゲートウェイは、特定の文書化された選択肢であり、既定ではない。設計がそれに依存するなら、設計はそう書かなければならない。既定のルートベースセレクターモデルは Azure 側で異なる動作をするからだ。
バージョンの制限も契約に含める。暗号化ドメインの上限に関する古いフィールドレポートは、特定のリリースについてのデータ点であり、すべての ASA の恒久的な性質ではない。
集約ではなく、プレフィックスペアを列挙する
マトリクスを書く。オンプレミスの A と B から Azure の X と Y へは四つのペアがあり、それぞれにカバレッジか明示的な除外が必要だ。A と B を一つの集約にまとめると、両者の間に存在するものまで含めてしまい、そうして設計は静かに穴を広げる。
保存した内容ではなく、ピアがネゴシエートした内容を確認する。ASA のローカルネットワークとリモートネットワークの一覧は意図であり、CHILD SA が結果だ。
ペアが欠けているとき、修正は通常 access-list の一行かセレクターのエントリであり、新しいトンネルではない。
オブジェクトを名指しするコマンドで検証する
ASA では IKE セッション、次に IPsec SA、次にセレクターペアを確認する。各コマンドは別の問いに答えており、最初の一つだけを実行することが、「トンネルは上がっている」を誤った結論に変える。一覧の先頭にある SA ではなく、実際に設定したピアの出力を読む。Azure 側も同じ三つの問いに自分側の視点から答える。
show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed
次に az network vpn-connection show --name <connection> --query connectionStatus で Azure に接続状態を問い合わせる。データパスにゼロバイトのまま「接続済み」なら、それはルーティングではなくセレクターの問題だ。
ペアごとに許可されるフローを一つ試し、反対側で見える送信元アドレスを確認し、拒否されるべきリソースを一つ試す。その最後のテストだけが、境界がまだ存在することを証明する。
暗号化スコープとアクセス許可を分けておく
広いセレクターは許可ではない。サポートされる構成がアプリケーションポリシーより広いなら、狭いサービスはファイアウォールルールに残し、暗号化スコープは必要な場所に置いておく。
Azure のワークロードルートとオンプレミスの戻りルートは別々にレビューする。BGP アドバタイズ、静的ネットワークスコープ、ユーザー定義ルートは同じ経路を記述しなければならず、どれもピアのトランスポートを再帰的に捕捉してはならない。
ロールバックと、それが機能した証拠
セレクターを変更する前に以前の running configuration を保持し、それを戻す一つのコマンドを知っておく。ASA では保存コピーと対応する復元手順であり、何を編集したかの記憶ではない。変更がまだ仮定のうちに、復元コマンドを変更チケットに書く。その後、同じ三つの確認を再実行する。IKE 状態、IPsec SA ペア、ペアごとに許可されるフロー一つ。
復元後もペアが失敗するなら、変更が原因ではなかったのであり、二度目の障害をちょうど避けたことになる。