ASA の failback：ルートが戻ったときに実際に動くもの

uplink を二本持つ ASA では、failback は failover の逆ではありません。peer へのルートが変わり、その後プラットフォームは三つの独立した状態機械を調停しなければなりません。ルートテーブル、IKE と IPsec のセキュリティアソシエーション、そして接続テーブルです。それぞれが他の遅れをとることがあり、その遅れこそ多くの人が戻らないトンネルと呼ぶものです。

failback が実際に変えるもの

ルート検索は目に見える部分です。監視オブジェクトが復旧すると peer の外部アドレスへの監視ルートが戻り、ASA が送る次のパケットは再び主系リンクを通ります。その後のすべては、既存の状態が新しい経路と一致しているかどうかにかかっています。

ARP と NAT は静かな依存関係です。新しい next hop には解決可能なゲートウェイと、遠端とまだ一致する変換が必要です。そうでなければ failback 後の最初のパケットはどこにも届かず、何も動かないのにルートだけは正常に見えます。

ひとつの時間軸で見る四つの視点

遷移の前、途中、後で同じ四つの項目を記録してください。一枚のスナップショットでは、どの層が動いたのか分かりません。

一度も変わらなかったルートと、古い接続が転送状態を保ったまま変わったルートは、同じ訴えと同じではない証拠を生みます。

古い接続が予備経路に残る理由

ASA はルートが変わったという理由でフローを切断しません。確立済みの接続は作成時の転送判断を保持し、プラットフォームはそれが許される時間について別々の制御を用意しています。floating-connection timeout と connection holddown です。Cisco の ASA 9.24 の接続設定ガイド はこれを別々の問いとして扱っており、実際にそのとおりに振る舞います。一方は既存フローの存続を、もう一方は新しいフローが優先経路を使える時機を司ります。

どちらを変える前にも、お使いのリリースの実効値を読んでください。下げると人がまだ使っているセッションが閉じます。上げると failback が起きなかったように見えます。新しい接続がその間ずっと古い経路を使い続けるからです。

ルートが戻ってもトンネルは鍵を再交換しない

IPsec のセキュリティアソシエーションは独自に折衝した寿命を持ち、それを運んだルート変更を生き延びます。したがってトンネルは failback をまたいで上がったままでも、その外部アドレッシングが使用中の経路と一致しないことがあります。これが DPD と、peer アドレスを変動させずに固定する設計の論拠です。

crypto-map と VTI の設計はここで異なる振る舞いをします。また Cisco の 9.24 VTI の文書はルートベースの選択肢を説明しています。ASA はルートベース VPN を動かせないという以前の一律の主張は、サポート対象のリリースには当てはまりません。

証拠はこの順に読む

制御プレーンから始めます。選択された経路には show route、リンク状態には show interface、監視オブジェクトには SLA モニタのカウンタを使います。次に show crypto ikev2 sa、または IKEv1 の相当品を読んでどの peer が生きているかを見て、続いて保護されたフローには show crypto ipsec sa を読みます。そのうえで show conn address <host> で接続テーブルを絞り、古い項目と新しい項目でインターフェース列を比べます。出力は時刻とともに書き留めてください。その順序が診断そのものです。

最後にアプリのテストを行います。既に存在していたフローと、ルートが戻った後に作られたフローの二つです。古いフローが失敗し新しい方が動くなら、接続状態の話になります。両方失敗するなら、トンネルかポリシーが誤りで、接続テーブルは注意をそらすものです。

その記録を三つの段階すべてで同じ形に保ち、正確なリリースを書き留めてください。時間軸が単一の遷移を指し続けるなら、バグ ID を推測せずに記録をサポートへ送ってください。