IOSからASAへのVPN移行：合意内容を翻訳し、コマンドは訳さない

ASA 移行の参照として届く IOS 設定は、あるプラットフォームの構文で包まれた合意内容を記述しています。ピアのアドレス、識別情報、保護範囲が合意そのものです。キーリング、プロファイル、暗号マップの連鎖は IOS がそれを表現する方法であり、ASA は同じ意図をトンネルグループとその属性で表現します。後半だけを写しても機能せず、前半だけを写すと作業は中途半端になります。

以下の五つの手順を順番に進め、二つのプラットフォームが「違う言葉」ではなく「違うもの」を説明している箇所では手を止めてください。

ステップ 1：合意内容を構文から切り分ける

引き継ぎを、両方の管理者が同意する要件として書き出します。四つの行は、ピアの位置と開始側、各側の識別情報の証明方法、許容される保護、トンネル越しに維持すべきアプリケーションというほぼすべてを網羅します。これらの行のどこにもコマンドは出てきません。

元のテキストは指示ではなく証拠として保管します。一方のプラットフォームにあってもう一方にない行は、同じ要件を別の方法で満たせるかどうかを確認するまでは、単なる構文の違いです。

ステップ 2：各プラットフォームでオブジェクトに名前を付ける

IOS XE では IKEv2 キーリングが IKEv2 プロファイルに供給され、そのプロファイルは暗号マップまたは IPsec プロファイル経由で結び付けられ、ASA ではトンネルグループが接続プロファイルとその IPsec 属性を保持して暗号マップがそれを指します。詳しくは 接続プロファイルのガイド で説明されています。これらは継承の異なる別々のオブジェクトグラフであり、そのため行単位の対応付けでは、解析は通るものの接続しない設定が出来上がります。

対象のオブジェクトは、元の行からではなく要件の行から組み立てます。行が揃っていれば、対象の設定は設計上の判断です。揃っていなければ、どれだけコマンドを翻訳しても欠けた意図は補えません。

ステップ 3：アドレスだけでなく識別情報を引き継ぐ

識別情報は静かに壊れる部分です。アドレスで認証するピアは、証明書のサブジェクトや FQDN で認証するピアとは振る舞いが異なり、両プラットフォームはその前提を別々の場所に記録します。テストが簡単だからといって共有シークレットに置き換えず、意図した識別情報と信頼の連鎖を保ってください。

事前共有シークレットは比較メモやチケットに残さないでください。誰が所有し、承認された経路でどう受け渡されるかを記録し、ドキュメントの例にあるプレースホルダーは顧客の資格情報ではないことを忘れないでください。

ステップ 4：切り替え前に保護方式を合意する

提供されたテキストに載っているからといって、古い暗号設定をそのまま引き継がないでください。両方の既設ピアが現在サポートするスイートの共通部分を合意し、変更作業の前に相手の管理者と確認します。その共通部分が既存ピアの想定と異なるなら、それは局所的な編集ではなく調整された変更です。

合意した組み合わせを書き留めます。電話での会話について記憶が食い違う二人の管理者こそが、切り替えで第二フェーズの不一致が起きる原因です。

ステップ 5：構文ではなくサービスを検証する

まず対象の実効オブジェクト、次に確立されたアソシエーション、次に実際のアプリケーションフローとその応答を確認します。コマンドをエラーなく入力できたことは構文の証明にすぎません。トンネルが上がっても通信が流れない場合、通常は保護範囲か戻り経路が相手側と一致しておらず、これはコマンドの問題ではなく要件の行の問題です。暗号マップに再度触れる前に、両側の保護範囲を比較してください。

何を、どのアドレスで、どちら側から検証したかを記録します。その記録は「VPN は上がっている」という曖昧な主張を、相手の管理者が独自に確認できるものに変えます。

返すべきもの

要件マトリクス、対象設定の要約、検証結果を送ってください。どの元設定を引き継がなかったのか、その理由を明示します。その一覧は、次の意見の相違がそこから始まるため、翻訳済みの設定よりも有用です。

元のテキストもチケットと一緒に保管してください。何が求められたかを示す一方、マトリクスは何が合意されたかを示します。