Cloud VPN から Cisco ASA へ：提案の不一致後にトンネルを作り直す

遠端に Cisco ASA を置く Cloud VPN トンネルでの NEGOTIATION_FAILURE は、ほぼ常に提案かセレクタの不一致であり、最初に役立つ事実はどんな編集でも直らないということです。Cloud VPN はトンネル オブジェクトの作成時に IKE 提案を固定します。アルゴリズムをその場で変えるフィールドはないため、修復は削除と、記録した開始点からの作り直しになります。これを再構築として扱えば、作業は推測で埋める半日ではなくチェックリストになります。

何かを削除する前に、失敗の内容を読む

ネゴシエーションの失敗はフェーズの問題で、ピアのログは通常フェーズを示します。フェーズ 1 の失敗は、両端が提案で合意できなかった、または相互に認証できなかったことを意味します。フェーズ 2 の失敗は、トンネルは上がったが保護対象のセレクタが一致しなかったことを意味します。これは別の修復であり、誰かが設定に触る前にログの行を抜き出しておく価値があります。

この失敗は他の原因も排除します。VPC ルートでも、トンネル インターフェース上のファイアウォール ルールでも、ネットワーク内部の名前解決の障害でもありません。それらを追いかけると、結果を変えられない自信過剰な変更が生まれ、最終的な修正の帰属が難しくなります。

両方の設定がまだ存在するうちに記録する

トンネルの削除は半分ほどで終わり、手元にあった唯一の証拠を破壊します。その前に、ローカルとリモートのセレクタ、ピア アドレス、共有シークレットの所有者、ASA の crypto map または IKEv2 プロファイルを書き留めます。ASA は二つの別の問いに答えます。何が設定されていて、何が今上がっているのか:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

Google 側ではコンソールの要約ではなくトンネル オブジェクトを読みます。ピア アドレスとセレクタのフィールドこそ、正確に再現すべき値だからです:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

最初の削除の前に、その値をチケットに書きます。以下の作り直しが機能するのは、同じオブジェクトを一つの意図的な違いだけで再作成できるからです。

片側がネゴシエートを拒むアルゴリズム

Cloud VPN は従来のピアのように IKEv1 アルゴリズムの範囲から選ぶことはしません。期待するピア設定は固定です。暗号化に aes-cbc-128、整合性と PRF の両方に sha1-96、Diffie-Hellman グループ 2、フェーズ 1 に 36,600 秒、フェーズ 2 に 10,800 秒です。ASA のポリシーはこの集合を正確に提示する必要があります。ASA に二つ目の提案があっても、一致するものがリストにあれば害はありません。

IKEv2 は双方に余裕を与えますが、ルールの形は同じままです。PFS を有効にし、トンネルが対応する DH グループを選び、不一致が明らかになる程度に提案リストを短く保ちます。Cloud VPN で ASA をピアにする場合は静的ルーティングにもなるため、保護するプレフィックスは BGP に任せず、計画して列挙する必要があります。

他社のテンプレートからコピーした有効期間は、ここでのよくある誤りです。Google はこれらの値を必須のピア設定として公開しているので、そのとおりに設定します。短い値が ASA の望む値まで上方交渉されることはありません。

削除し、作り直し、古い状態を消す

ゲートウェイではなくトンネルを削除し、Cloud VPN が代替に付ける名前を控えます。名前は再利用されず、割り当てられるためです。記録した値と同じピア アドレスで作り直し、一致する提案を ASA のポリシー リストに追加します。

ASA の変更後、結果を読む前にセキュリティ アソシエーションを消去します。ASA は現在の SA が期限切れになるまで古いポリシーを提示し続けることがあるため、正しい設定が古い有効期間の間ずっと壊れて見え、監視者は再構築が始まってもいないのに失敗したと結論づけます:

clear crypto ikev2 sa
clear crypto ipsec sa

フェーズ 2 を見る前に、フェーズ 1 が上がることを確認します。フェーズ 1 が下がっている間は提案か事前共有鍵が誤っており、セレクタの作業ではそれは変わりません。

セレクタは鏡のように合わせ、最後はカウンタが決める

フェーズ 2 は、保護するアドレスについて両端が一致したときだけ機能し、その一致は共有ではなく鏡像です。Google のローカル セレクタは ASA がリモートと呼ぶセレクタと一致し、Google のリモート セレクタは ASA がローカルと呼ぶものと一致する必要があります。片側が 0.0.0.0/0、もう片側が単一のサブネットのトンネルはフェーズ 1 を通り、同じ主要エラーでフェーズ 2 に失敗します。どちらの側も相手のリストを広げられません。

ポリシー ベースのセレクタでは、すべてのプレフィックス ペアを列挙し、そのリストをチケットに残します。後から拠点側で追加したサブネットは両端の編集が必要です。ASA の新しいルートはセレクタを広げないため、結果はトンネルが上がっていても初日に存在したプレフィックス分しか通信が通らない状態になります。

最後にホスト間のフローを一本流し、両側のバイト カウンタを読みます。ASA で増えて Google で止まったままのカウンタは、通常、応答が別のインターフェースから出ているか、セレクタが戻り方向のプレフィックスを覆っていないことを意味します。アルゴリズム、有効期間、セレクタ、新しいトンネル名を記録します。次の提案変更でこの作り直しを繰り返すことになり、これらの値がそれを短い作業に変えます。