Google HA VPN から Cisco ルーターへ：まずピアリソースを計画する

Cisco から Google への HA VPN で最初の判断は、どの暗号プロファイルを使うかではなく、トンネルを終端するのがオンプレミスの機器一台か二台かです。Google の HA VPN ゲートウェイには二つのインターフェースがあり、それぞれが対応するピアトンネルを想定しています。これにより、ルーターが二台あるかどうかに関係なく二本のトンネルが得られ、違いは、電源一つまたはソフトウェア更新一つで設計全体が落ちるかどうかにあります。

判断はピア機器を一台にするか二台にするかです

ローカル障害点を受け入れられるか、両方のクラウドインターフェースを使う必要があるか、ワークロードがどれだけの再収束を許容するかという三つの条件からレイアウトを選びます。三つのうちどれかが厳格な要件なら、ピア機器二台が正直な答えです。

コンソールを開く前にそれを決めてください、答えによってワークシートが記述すべきトンネルと BGP セッションの数が変わるからです。

どのコマンドよりも先にワークシートを書きます

ワークシートには五行があり、それぞれに担当者が必要です。

外部ピアリソースは Google Cloud 内のインターフェースを記述するもので、作成しても Cisco ルーターは設定されません。この非対称性は、クラウドコンソールが両端の真実の源になると期待する人を驚かせます。これは Google が何を期待すべきかの宣言であり、ルーターは依然としてそれに一致する必要があります。Google の ピアゲートウェイガイド は、その宣言を、まだ果たしていないトンネル、BGP、ファイアウォール、IKE の作業に対応付けます。

行に担当者がいなければ、切り替え中に勤務している人がそれを埋めます。

三つのアドレスの役割を分けておく

公開ピアアドレスは外部の IPsec 交換を運びます。内部の BGP ペアは、その上を流れる保護された論理接続に属します。アドバタイズされる LAN と VPC のプレフィックスは、その接続の背後のワークロードを記述します。VM の内部アドレスを外部ピアのフィールドにコピーすると、最初の二つの役割が混ざり、障害はデータ入力の誤りではなくネゴシエーションの問題のように見えます。

HA VPN の各インターフェースに一つずつ、対応するピアトンネルを二本計画します。両方のクラウドインターフェースを使っても、二本のトンネルが同じシャーシに着地し得るため、ローカル障害点そのものは消えません。

ワークシートの各値の隣にアドレスの役割を書きます。その一つの習慣がほとんどの混同を防ぎます。

ワークシートを Cisco のリリースに翻訳する

サポートされているピアのドキュメント、またはお使いのプラットフォームに合う Google の設定テンプレートから始め、すべてのプレースホルダーをワークシートと突き合わせます。IKEv2 認証、ESP 提案、PFS、トンネルとルーティングのモデルをまとめて確認します、どれか一つの不一致は通常、別の不一致として現れるからです。何がサポートされるかは実際のプラットフォームとソフトウェアリリースで選びます、Classic VPN のレシピは別の出発点だからです。

共有シークレットは、スクリーンショット、チケットの添付ファイル、サポートメモから外しておきます。ケースのコメントに貼り付けた事前共有鍵は認証情報の開示であり、トラブルシューティングの成果物ではありません。

テンプレートとワークシートが食い違う場合は、止まって紙の上で解決します。機器があなたの代わりに裁定することはありません。

各トンネルをそれぞれの証拠で受け入れる

HA VPN には BGP セッションが必要で、成功した IKE ネゴシエーションは最初の段階を確立するだけです。内部セッションが上がり、意図したプレフィックスがアドバタイズされて受け入れられ、ワークロードのトラフィックが動く前に有用なルートとファイアウォールの許可が存在している必要があります。それらを一つの青信号として記録すると、どの段階が実際に失敗したかが隠れます。

トンネルごとに受け入れの証拠を記録します。ネゴシエートされたセキュリティアソシエーション、BGP ネイバーの状態、期待される学習プレフィックス、意図したワークロードの経路です、その後、制御された障害と復旧の確認を実行します、一度も失敗していないトンネルは、復旧経路が試されていないトンネルだからです。

その記録は次に設計が変わるときに再利用でき、相互運用と、前提が失われたコマンド断片との違いになります。