GCP HA VPN wijst FortiGate af: type lokale ID komt niet overeen

AUTHENTICATION_FAILED van Google Cloud HA VPN stuurt mensen meestal terug naar de vooraf gedeelde sleutel, en de sleutel is doorgaans correct. De tunnel blijft in fase 1 steken omdat Google ook iets anders vergelijkt: de identiteit die de peer tijdens de IKE-uitwisseling beweert. Op een FortiGate kan die identiteit van type veranderen zonder dat iemand een adres bewerkt. Lees het log als een identiteitsconflict zodra de sleutel twee keer opnieuw is ingevoerd.

Eén fout, twee controles

IKE verifieert een peer in twee afzonderlijke stappen. De vooraf gedeelde sleutel bewijst dat beide kanten hetzelfde geheim hebben, en een beweerde identiteit vertelt de responder wie de peer zegt te zijn. Google controleert die identiteit tegen de peer waarmee het is geconfigureerd. Zonder ingrijpen stuurt een FortiGate een adresgebaseerde identiteit die is afgeleid van zijn uitgaande interface, en de vergelijking slaagt zonder dat iemand het merkt.

Beide stappen belanden in dezelfde emmer in het log, wat de bekende lus verklaart van de sleutel vier keer opnieuw typen voordat iemand de identiteitslading leest.

Wat een FortiGate in de identiteitslading zet

Het probleem begint wanneer iemand een lokale ID instelt om de twee kanten te laten overeenkomen. Recente FortiOS-builds markeren die identiteit als een volledig gekwalificeerde domeinnaam, zelfs wanneer de ingevoerde waarde een adres met punten is. Google ontvangt dus een FQDN-identiteit terwijl het een adres verwacht, en het weigert de sessie. Niets in de melding zegt welke helft faalde, dus het rapport leest als een authenticatiefout.

Reproduceer het één keer met IKE-foutopsporing aan en lees de identiteitslading die de firewall werkelijk uitzendt.

Bevestig in dezelfde ronde drie goedkope feiten: de IKE-versie die beide kanten gebruiken, de exacte sleutel inclusief onzichtbare eindtekens, en het peeradres dat Google verwacht. Ze beantwoorden verschillende vragen, en een overeenkomende sleutel zegt niets over de identiteit.

Opties, en wat elk kost

Elke uitweg repareert een andere laag, en geen ervan is beschikbaar voor elke implementatie.

De identiteit op de firewall corrigeren is het schoonste antwoord waar de firmware u de soort laat kiezen en de waarde laat behouden. Het veld bestaat in sommige builds en vult de soort in andere verkeerd, dus test uw versie in plaats van de releaseopmerkingen te vertrouwen.

Een routeerbaar openbaar adres op de onderhandelende interface is de gedocumenteerde omweg, omdat de standaardidentiteit dan overeenkomt met wat Google verwacht en er geen overschrijving nodig is. Daar landen de meeste implementaties, als de firewall überhaupt zo'n adres kan vasthouden.

Termineren op een peer die valideert wat u produceert is een topologiewijziging. Behandel het als een ontwerpbeslissing en niet als een omweg met een vriendelijker beschrijving.

Wanneer NAT één optie wegneemt

Achter NAT verdwijnt de uitweg via een openbaar adres, en wat overblijft hangt af van firmwaregedrag dat u niet beheert. Dat is het punt om bewust te kiezen tussen upgraden, de peer verplaatsen of een ander cloud-eindpunt accepteren. Dat zijn drie verschillende budgetten, en er één per ongeluk kiezen is hoe een tijdelijke omweg architectuur wordt. Schrijf de keuze en de reden ernaast bij de tunnel.

Voordat u hier iets van interpreteert, bevestig de tunnelstatus aan de Google-kant en dat IKE niet simpelweg onderweg wordt weggegooid. Een weggegooid pakket loopt in een time-out; het levert geen weigering op.

Wat te noteren terwijl het werkt

Noteer het identiteitstype, de waarde, de firmwareversie en het peeradres die golden toen de tunnel voor het laatst omhoogkwam. Een firmware-update kan de standaard opnieuw wijzigen, en de volgende fout ziet er precies uit als een sleutelconflict. Met de identiteit naast de sleutel en het peeradres opgeslagen, begint de volgende persoon bij de goedkope controles.

Die registratie is ook de enige manier om te weten of een omweg na de volgende upgrade nog nodig is.