Cloud VPN の状態: IKE ログより先にリソースの状態を読む

Cloud VPN のトンネルは二つのライフサイクルを同時に走らせており、両者は同じ時計の上にありません。リソースは割り当てと設定が済んで初めてネゴシエーションできるのであり、その後にプロトコル側の IKE メッセージの順序があります。状態フィールドが前者を報告していても、後者について有用なことを何も語っていないことがあります。両者を一つのものとして読むと、鍵の不一致がプロビジョニングの遅れのせいにされます。

まず一つのトンネル オブジェクトと一つの時間枠から始めます。

二つのライフサイクル、一つのトンネル オブジェクト

リソースのライフサイクルとは、プロバイダーがトンネルを用意する段階です。アドレス、設定、容量が含まれます。プロトコルのライフサイクルは、両側のピアが IKE_SA_INIT、次に IKE_AUTH、次に子のセキュリティ アソシエーションを交換できるだけの設定を持った時点で始まります。最初の段階にとどまっているトンネルは認証に失敗したのではなく、認証がまだ試されていないだけです。

この区別が問題のすべてです。あとは、無関係なメッセージを混ぜずに観察する方法の問題です。

コンソールの要約ではなく、オブジェクトを読みます

API には重要な二つのフィールドだけを問い合わせ、他は求めません。そうすれば答えは午前三時に読める程度に小さく保てます: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)"。status フィールドはライフサイクルの段階を示し、detailedStatus はそれに付随する読める理由を保持します。設定全体のダンプは別の問いに答えるもので、チケットに貼るのも難しくなります。このような読み取り専用の呼び出しはトンネルを変更できないので、インシデントが続いている間は重要な性質です。

呼び出しの時刻を値のそばに記録してください。どちらのフィールドも動くからです。

ALLOCATING_RESOURCES は鍵の不一致ではありません

トンネルが ALLOCATING_RESOURCES を報告しているとき、プロバイダーはまだオブジェクトを組み立てています。その段階では事前共有鍵の不一致を観察できず、ピアのポートが塞がれていることも同様に証明されていません。確認できるのは詳細メッセージ、プロジェクトとサービスが健全に見えるか、そしてピアにそもそも連絡できるだけの設定がトンネルにあるかどうかです。いま秘密を差し替えても、一度も試されていない値を変えるだけです。

設定について結論を出す前に、状態が動くのを待ってください。

ESTABLISHED はアクセス確認の始まりです

確立したトンネルは IKE が完了したという意味で、トラフィックが流れているという意味ではありません。トンネルが運ぶルートを確認し、Cloud Router が関与する場合は BGP セッションと学習したプレフィックスを確認します。そのうえで許可されたアプリケーションの交換を試してください。ファイアウォール規則や欠けたルートは、まったく健全なトンネルでもトラフィックを止められるからです。それぞれが別の観察であり、別の修正です。

状態は次にどの問いを立てるべきかを教えてくれます。アクセスの問いに代わりに答えてくれることは決してありません。

一つのオブジェクトと一つの時間枠を突き合わせる

ログにある古い認証失敗は、その時刻が調べている時間枠に入らない限り、以前の試行のものです。記録した状態と同じ分のトンネル リソースのログを取り、識別子を一緒に保ってください。後から起きた IKE イベントは、ネゴシエーションが始まったことを示す一方で、見つめているコンソールのメッセージがすでに古いことがあります。

何も集める前にトンネルが復旧したなら、そう伝えてください。原因不明という記録は、無関係な行をつなぎ合わせた自信ありげな物語より優れています。

次の一歩はいつも同じ形です。一つのオブジェクト、一つの時間枠、一つの段階。それより広いものは要約であって、診断ではありません。