ASA の peer reset が消すのは IPsec SA だけ、IKE 状態とセッションは残る
peer 単位の clear が落とすのは IPsec のデータパスだけです。何が残るのか、なぜトンネルが数秒で再構築されるのか、代わりにどの層を消すべきかを解説します。
一つのアプリケーションでトンネルが切れ、誰かが peer 単位の IPsec clear を実行し、コマンドが通ったという理由でチケットが閉じられます。その流れのどこにも、障害が直ったことは示されていません。ASA では reset という語が三つの別々の範囲を覆っており、peer 単位の clear が触れるのはそのうち一つだけです。だから同じトンネルが、担当者が出力を読み終える前に戻っていることがよくあります。
一つの言葉の裏に三つの範囲
IPsec SA のペアはデータパスそのもので、方向ごとに一つのアソシエーションがあり、シーケンス番号とカウンタを持ちます。IKE SA はそのアソシエーションを生み出し、peer との関係を今も保っているネゴシエーション用のチャネルです。VPN セッションは、ユーザー、サイト間 peer、クライアントレス接続についてのセッションデータベースのレコードです。
| Scope | What a clear removes | What usually survives |
|---|---|---|
| IPsec SA | Data-path associations for the matching peer or selector | IKE SA, session records, crypto-map or tunnel-group config |
| IKE SA | Negotiation channel and the IPsec children derived from it | Session records until they age out or are cleared |
| VPN session | Session-database entry for that user or peer type | Configuration, and any SA that is not tied to the session |
範囲同士は十分に独立しているため、一つを消しても他は動き続けます。そしてこの独立が混乱の大部分を生みます。IKE SA が健全なまま IPsec SA を消すと、トラフィックが数秒で新しいアソシエーションを起こすので、トンネルが自力で直ったように見えます。しかし背後にある提案の不一致、ルートの欠落、認証の失敗はそのまま残っています。
障害がネゴシエーション側にあるなら、IPsec clear は観測できるものを何も変えません。
状態が残っているうちに読む
何も触る前に、peer のアドレス、使用中の IKE バージョン、保護対象ネットワーク、方向別のカウンタを記録します。表示できるビューはリリースによって異なりますが、形は安定しています。show crypto ipsec sa peer、show crypto ikev2 sa detailed または IKEv1 の相当コマンド、そしてセッション層には show vpn-sessiondb です。
その出力の横に、タイムスタンプと利用者が見ている正確な障害を書き添えます。一つの peer が複数の保護対象ネットワークを持つことはよくあるため、peer 単位の clear の影響範囲はその peer のすべてのセレクタであり、チケットの一つのアプリケーションではありません。事前の画像がない reset は後から診断できません。clear が、比較に使うはずだったカウンタそのものを消してしまうからです。
まず証拠を押さえます。clear はそれを消してしまい、後から撮ったスクリーンショットが示すのは何が再構築されたかであって、何が壊れていたかではありません。
peer 単位の clear が実際にしていること
Cisco の clear コマンドリファレンス に peer 単位の IPsec 形式が記載されています。ドキュメント用アドレスを当てはめると、次のようになります。
clear crypto ipsec sa peer 198.51.100.42このコマンドは peer に一致する IPsec アソシエーションを落とします。IKE SA は削除せず、設定も消さず、セッションデータベースもリセットしません。変更するトンネルに依存しない管理経路から実行してください。そのトンネルの中を通る SSH セッションは道連れに落ち、自分では戻ってこない可能性があります。装置の他のすべては動き続けるので、コマンドは無害に感じられます。
対象の特定が不確かなときは、条件を付けない clear に逃げないでください。広い形式は装置上のすべての peer に届き、生じる障害は呼ばれた理由のものより大きなものになります。
直そうとした層を検証する
clear の後は、peer の一覧が埋め直されたからといって reset が効いたと決めつけず、アソシエーションが新しいカウンタで戻ったことを確認します。そのうえでチケットが挙げたアプリケーションを試してください。ping の成功は、サービスの許可や期限切れのセッションについて何も語りません。
アソシエーションが再構築されてもアプリケーションが失敗するなら、残る候補は IKE 層とセッション層です。状態をまだ確認できるほうを選びます。実際に動いているバージョンに合った的を絞った操作を使ってください。IKEv2 の clear、IKEv1 の clear、あるいは正しいセッション種別に限定したセッションデータベースの clear です。永続的な crypto-map 設定を削除して作り直し、再構築を強いるのは、戻し作業が長くなる当て推量です。
もう一度消すのではなく、前と後の両方の画像を添えてエスカレーションしてください。
reset が障害を長引かせるとき
繰り返しの clear は reset では直せない障害を隠す: 欠けたルート、新しいサブネットに合わなくなったセレクタ、片側だけ変わった事前共有鍵、peer が受け入れない提案で繰り返し失敗する鍵更新などです。clear のたびに、その peer のすべてのセレクタで健全なトラフィックが途切れ、本当の原因は手つかずのまま残ります。こうして五分の調査が変更作業の時間帯に変わります。
範囲を限った reset は今でも役に立ちます。役に立つのは、対象を絞り、記録し、直すはずだった層を確認するところまで含めた版です。
作業の順序: peer、バージョン、セレクタ、カウンタを記録する。障害がどの範囲に属するかを確かめる。一致する最も狭い clear を実行する。アソシエーションとアプリケーションを検証する。層は回復したのに症状が残るなら、証拠を添えてエスカレーションする。