調整できない Cloud VPN の上限：IKE の有効期間とピア側 NAT

遠隔機器に 24 時間のフェーズ 1 有効期間を設定すると、Google 側がすべて正しく構成されていても Cloud VPN トンネルはダウンしたままです。ピアがレスポンダの受け入れない値を提示しているため、ネゴシエーションは完全に失敗するか、無限に再開します。Cloud VPN はフェーズ 1 を 36,000 秒、つまり十時間に制限しており、この上限は引き上げられる設定ではありません。変更すべきは遠隔機器側です。

問い合わせるのはピア、決めるのはレスポンダ

IKE は二つの提案セットを突き合わせる作業です。トンネルは、レスポンダが受け入れる範囲内で両セットが重なる場所にのみ確立され、範囲外の有効期間では部分的なトンネルすらできません。ピアの設定を提案ではなく希望リストとして扱うのがよくある誤りです。共通部分が空なら、ルーティングとセレクタがどれほど正しくてもトンネルはダウンのままです。

ケースを開く前にトンネル自身の状態を読み取ってください。詳細ステータスは通常、失敗した段階を名指しします:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

返ってきた内容を、ゲートウェイ種別と IKE バージョンでサポートされるセットと比較し、その場で両方のトラフィックセレクタを記録します。セレクタの不一致はアルゴリズムの不一致と同じトンネルダウンの症状を生み、アルゴリズムと違ってこちらは自分で直す側です。

上限は 36,000 秒

フェーズ 1 は 36,000 秒で止まります。86,400 に設定した機器は、レスポンダが決して同意しない値を要求しており、再試行しても考えは変わりません。遠隔側の提案を範囲内に戻せば同じ構成で確立します。非対称性こそが教訓で、自分の値は下げられても Google の値は上げられません。

選んだ値を設計ノートに書き残してください。さもなければ次のエンジニアが 24 時間の実験をやり直し、同じ壁に突き当たります。

サポートされるセットはゲートウェイ種別と IKE バージョンごとに次で公開されています: Cloud VPN の概要。一般的な IKE ガイドではなく、自分のトポロジの節を読んでください。

決まった周期で落ちるトンネル

フェーズ 2 は挙動が異なります。両端が一致しない場合、鍵の再生成は短い方の間隔に従います。不一致を致命的とみなすピアは代わりにトンネルを落とすため、一つの不一致が無関係な二つの障害に見えることがあります。最初の接続だけでなく、鍵再生成のリズムを見てください。一定の拍で上がっては落ちるトンネルは、ルーティング不良よりも有効期間の不一致であることが多いです。

変更する前に、その落ちた時刻をピア自身のログと突き合わせてください。セレクタやルートの変更でも同じリズムを再現できるからです。拍がフェーズ 2 のタイマーと一致すれば、提案に触れずに原因が判明します。

スイートはゲートウェイ種別から決まる

暗号と完全性のスイートは、strongSwan のようにトンネルごとに編集できるプロファイルではありません。ゲートウェイ種別と IKE バージョンで選ぶもので、存在しないプロファイルを探すのは午後一つ分の無駄です。

サポートされるセットの中に何も持たない旧式機器には、正直な道が二つあります。機器を交換するか、自分で管理するソフトウェアゲートウェイで終端してそこから VPC へルーティングするかです。それ以外は次のレビューで落ちる場当たり的な回避策です。

機器ごとに一つの外部アドレス

ピアの外部アドレスは、その内部アドレスに一対一で対応している必要があります。 過負荷の PAT プールは機能しない。一つの公開アドレスの背後に複数のホストがあると、レスポンダにはそれらを分離する手段がないからです。複数のホストがアドレスを共有する必要があるなら、トンネルはそれらを見分けられる場所で終端しなければなりません。

その外部アドレスも安定させてください。機器を別の NAT の背後へ移すと、すべての提案が一致していても関連付けが切れます。どの値が Google 側でどれが自分側かを書き留める価値があります。有効期間、スイート、一対一 NAT は相手側で固定され、提案、セレクタ、ルーティング、BGP の優先度は自分側です。