GCP HA VPN が FortiGate を拒否：ローカル ID の種類が不一致

Google Cloud HA VPN の AUTHENTICATION_FAILED は、たいてい人を事前共有キーへ戻させますが、そのキーは通常正しいものです。トンネルがフェーズ 1 で止まるのは、Google がもう一つ別のものも比較しているからです。それは IKE 交換中にピアが主張する識別子であり、FortiGate では誰もアドレスを編集していないのにその種類が変わる場合があります。キーを二度入れ直したら、ログを識別子の不一致として読んでください。

一つの失敗、二つの検査

IKE はピアを二つの別々の手順で検証します。事前共有キーは両端が同じ秘密を持つことを証明し、主張された識別子は応答側にピアが名乗る相手を伝えます。Google はその識別子を、設定されたピアと照合します。そのままにしておくと、FortiGate は送信インターフェースから導いたアドレス基準の識別子を送り、誰も気づかないまま比較が通ります。

どちらの手順もログでは同じバケットに入るため、識別子のペイロードを誰かが読む前にキーを四度打ち直すという、おなじみのループが生まれます。

FortiGate が識別子ペイロードに入れるもの

問題は、両側を一致させようとして誰かがローカル IDを設定すると始まります。最近の FortiOS ビルドは、入力された値が点付きのアドレスであっても、その識別子を完全修飾ドメイン名として扱います。そのため Google はアドレスを期待しているのに FQDN 識別子を受け取り、セッションを拒否します。メッセージにはどちらが失敗したか書かれていないため、報告は認証失敗として読めてしまいます。

IKE のデバッグを有効にして一度再現し、ファイアウォールが実際に送る識別子ペイロードを読んでください。

同じ機会に、両端が使う IKE のバージョン、見えない末尾文字を含めた正確なキー、Google が期待するピアのアドレスという三つの安価な事実を確認します。これらは別々の問いに答えるもので、キーが一致しても識別子については何も分かりません。

選択肢と、それぞれの代償

どの出口も異なる層を直すもので、すべての配備に使えるものはありません。

ファイアウォール側で識別子を直すのが最もすっきりした答えで、ファームウェアが種類を選ばせ、値を保てる場合に限ります。項目は一部のビルドにはあり、別のビルドでは種類を誤って埋めるため、リリースノートを信じるのではなく自分のバージョンで試してください。

折衝インターフェースに経路可能なパブリックアドレスを置くのが、文書化された回避策です。そうすれば既定の識別子が Google の期待と一致し、上書きは不要になり、ファイアウォールがそもそもそうしたアドレスを持てるなら、ほとんどの配備はここに落ち着きます。

生成物を検証するピアで終端するのは、トポロジーの変更です。より優しい説明の付いた回避策ではなく、設計判断として扱ってください。

NAT が選択肢を一つ消すとき

NAT の背後ではパブリックアドレス経由の出口が消え、残るものは自分では制御できないファームウェアの挙動に左右されます。ここが、アップグレードするか、ピアを移すか、別のクラウドエンドポイントを受け入れるかを意識的に選ぶ地点です。これは三つの異なる予算であり、うっかり一つを選ぶことが、一時的な回避策をアーキテクチャに変えてしまいます。選択とその理由をトンネルのそばに書いてください。

これを解釈する前に、Google 側のトンネル状態と、IKE が単に途中で捨てられていないことを確認してください。捨てられたパケットはタイムアウトするだけで、拒否は生みません。

動いている間に記録すること

トンネルが最後に上がったときに有効だった識別子の種類、その値、ファームウェアのバージョン、ピアのアドレスを記録します。ファームウェア更新で既定値がまた変わり、次の失敗はキーの不一致とまったく同じに見えます。識別子をキーとピアアドレスのそばに保存しておけば、次の人は安価な検査から始められます。

その記録は、次のアップグレード後に回避策がまだ必要かを知る唯一の方法でもあります。