GCP HA VPN lehnt FortiGate ab: Lokale ID hat falschen Typ
Google vergleicht die Identität, die ein FortiGate behauptet, nicht nur den vorab geteilten Schlüssel. Eine lokale FQDN-ID scheitert an dieser Prüfung, während das Log weiter von Authentifizierung spricht.
AUTHENTICATION_FAILED von Google Cloud HA VPN schickt Leute meist zurück zum vorab geteilten Schlüssel, und der Schlüssel stimmt normalerweise. Der Tunnel bleibt in Phase 1 stehen, weil Google noch etwas anderes vergleicht: die Identität, die der Peer während des IKE-Austauschs behauptet. Auf einem FortiGate kann diese Identität ihren Typ wechseln, ohne dass jemand eine Adresse bearbeitet. Lesen Sie das Log als Identitätskonflikt, sobald der Schlüssel zweimal neu eingegeben wurde.
Ein Fehler, zwei Prüfungen
IKE prüft einen Peer in zwei getrennten Schritten. Der vorab geteilte Schlüssel belegt, dass beide Seiten dasselbe Geheimnis kennen, und eine behauptete Identität sagt dem Responder, wer der Peer zu sein vorgibt. Google prüft diese Identität gegen den Peer, mit dem es konfiguriert wurde. Ohne Eingriff sendet ein FortiGate eine adressbasierte Identität, die von seiner ausgehenden Schnittstelle abgeleitet ist, und der Vergleich besteht, ohne dass es jemand bemerkt.
Beide Schritte landen im Log im selben Topf, was die vertraute Schleife erklärt, den Schlüssel viermal neu zu tippen, bevor jemand die Identitätsnutzlast liest.
Was ein FortiGate in die Identitätsnutzlast schreibt
Der Ärger beginnt, wenn jemand eine lokale ID setzt, damit beide Seiten übereinstimmen. Neuere FortiOS-Builds kennzeichnen diese Identität als vollqualifizierten Domainnamen, selbst wenn der eingegebene Wert eine Adresse mit Punkten ist. Google erhält also eine FQDN-Identität, während es eine Adresse erwartet, und lehnt die Sitzung ab. Nichts in der Meldung sagt, welche Hälfte gescheitert ist, daher liest sich der Bericht wie ein Authentifizierungsfehler.
Reproduzieren Sie das einmal mit aktivierter IKE-Fehlerdiagnose und lesen Sie die Identitätsnutzlast, die die Firewall tatsächlich sendet.
Bestätigen Sie im selben Durchgang drei billige Fakten: die IKE-Version beider Seiten, den exakten Schlüssel samt unsichtbarer Endzeichen und die Peer-Adresse, die Google erwartet. Sie beantworten verschiedene Fragen, und ein passender Schlüssel sagt nichts über die Identität.
Optionen und was jede kostet
Jeder Ausweg repariert eine andere Schicht, und keiner ist für jede Umgebung verfügbar.
| Option | When it works | What it costs |
|---|---|---|
| Set an address identity on the firewall | Your firmware lets you choose the type | Behaviour you must retest per release |
| Put a public address on the negotiating interface | The firewall can hold a routable address | Not possible behind NAT |
| Terminate on a peer that accepts your identity | Another endpoint validates what you produce | A topology change |
Die Identität auf der Firewall zu korrigieren ist die sauberste Antwort, wo die Firmware den Typ wählen lässt und den Wert behält. Das Feld existiert in manchen Builds und füllt den Typ in anderen falsch, also testen Sie Ihre Version, statt den Release Notes zu vertrauen.
Eine routbare öffentliche Adresse auf der verhandelnden Schnittstelle ist der dokumentierte Workaround, weil die Standardidentität dann zu dem passt, was Google erwartet, und keine Überschreibung nötig ist. Dort landen die meisten Umgebungen, wenn die Firewall überhaupt eine solche Adresse halten kann.
Auf einem Peer zu terminieren, der prüft, was Sie erzeugen, ist eine Topologieänderung. Behandeln Sie es als Designentscheidung und nicht als Workaround mit freundlicherer Beschreibung.
Wenn NAT eine Option entfernt
Hinter NAT verschwindet der Ausweg über die öffentliche Adresse, und was bleibt, hängt vom Firmwareverhalten ab, das Sie nicht kontrollieren. Das ist der Punkt, an dem Sie bewusst zwischen Upgrade, Verlegen des Peers oder einem anderen Cloud-Endpunkt wählen. Das sind drei verschiedene Budgets, und einen davon versehentlich zu wählen ist der Weg, auf dem ein vorübergehender Workaround zur Architektur wird. Schreiben Sie die Wahl und ihren Grund neben den Tunnel.
Bevor Sie irgendetwas davon deuten, bestätigen Sie den Tunnelzustand auf der Google-Seite und dass IKE nicht einfach unterwegs verworfen wird. Ein verworfenes Paket läuft in einen Timeout; es erzeugt keine Ablehnung.
Was festzuhalten ist, solange es läuft
Notieren Sie Identitätstyp, Wert, Firmwareversion und Peer-Adresse, die galten, als der Tunnel zuletzt hochkam. Ein Firmware-Update kann den Standard erneut ändern, und der nächste Fehler sieht genauso aus wie ein Schlüsselkonflikt. Mit der Identität neben Schlüssel und Peer-Adresse beginnt die nächste Person bei den billigen Prüfungen.
Diese Aufzeichnung ist auch die einzige Möglichkeit zu wissen, ob ein Workaround nach dem nächsten Upgrade noch nötig ist.