GCP HA VPN avvisar FortiGate: lokal ID-typ stämmer inte
Google jämför identiteten som en FortiGate hävdar, inte bara den fördelade nyckeln. Ett lokalt FQDN-ID fallerar den kontrollen medan loggen fortfarande säger autentisering.
AUTHENTICATION_FAILED från Google Cloud HA VPN skickar oftast folk tillbaka till den i förväg delade nyckeln, och nyckeln är vanligen korrekt. Tunneln stannar i fas 1 eftersom Google också jämför något annat: identiteten som peer-en hävdar under IKE-utbytet. På en FortiGate kan den identiteten byta typ utan att någon redigerar en adress. Läs loggen som en identitetskonflikt när nyckeln har skrivits in igen två gånger.
Ett fel, två kontroller
IKE verifierar en peer i två separata steg. Den i förväg delade nyckeln bevisar att båda ändarna har samma hemlighet, och en hävdad identitet talar om för svararen vem peer-en påstår sig vara. Google kontrollerar den identiteten mot den peer den konfigurerades med. Lämnad åt sig själv skickar en FortiGate en adressbaserad identitet härledd från sitt utgående gränssnitt, och jämförelsen passerar utan att någon märker det.
Båda stegen hamnar i samma hink i loggen, vilket förklarar den välbekanta slingan att skriva nyckeln fyra gånger innan någon läser identitetsnyttolasten.
Vad en FortiGate lägger i identitetsnyttolasten
Problemet börjar när någon sätter en lokal ID för att få de två sidorna att stämma. Nyare FortiOS-byggen markerar den identiteten som ett fullt kvalificerat domännamn även när värdet som skrivs in är en adress med punkter. Google tar därför emot en FQDN-identitet medan det väntar sig en adress, och avvisar sessionen. Inget i meddelandet säger vilken halva som misslyckades, så rapporten läses som ett autentiseringsfel.
Reproducera det en gång med IKE-felsökning påslagen och läs identitetsnyttolasten som brandväggen faktiskt skickar.
Bekräfta i samma omgång tre billiga fakta: IKE-versionen som båda ändarna använder, den exakta nyckeln inklusive osynliga sluttecken, och peer-adressen som Google förväntar sig. De svarar på olika frågor, och en nyckel som stämmer säger ingenting om identiteten.
Alternativ, och vad varje kostar
Varje utväg reparerar ett annat lager, och ingen av dem är tillgänglig för varje utrullning.
| 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 |
Att rätta identiteten på brandväggen är det renaste svaret där firmware tillåter dig att välja typ och behålla värdet. Fältet finns i vissa byggen och fyller i typen fel i andra, så testa din version i stället för att lita på utgivningsanteckningarna.
En routingbar offentlig adress på förhandlingsgränssnittet är den dokumenterade omvägen, eftersom standardidentiteten då stämmer med det Google förväntar sig och ingen åsidosättning behövs. Det är dit de flesta utrullningar kommer, om brandväggen alls kan hålla en sådan adress.
Att terminera på en peer som validerar det du producerar är en topologiförändring. Behandla det som ett designbeslut och inte som en omväg med en vänligare beskrivning.
När NAT tar bort ett alternativ
Bakom NAT försvinner utvägen via offentlig adress, och det som återstår beror på firmwarebeteende du inte styr. Det är punkten där du medvetet väljer mellan att uppgradera, flytta peer-en eller acceptera en annan molnändpunkt. Det är tre olika budgetar, och att välja en av misstag är hur en tillfällig omväg blir arkitektur. Skriv valet och skälet bredvid tunneln.
Innan du tolkar något av detta, bekräfta tunnelns tillstånd på Googles sida och att IKE inte bara släpps under vägen. Ett tappat paket löper ut; det ger ingen avvisning.
Vad som ska noteras medan det fungerar
Notera identitetstypen, dess värde, firmwareversionen och peer-adressen som gällde när tunneln senast kom upp. En firmwareuppdatering kan ändra standarden igen, och nästa fel kommer att se exakt ut som en nyckelkonflikt. Med identiteten sparad bredvid nyckeln och peer-adressen börjar nästa person med de billiga kontrollerna.
Den noteringen är också det enda sättet att veta om en omväg fortfarande behövs efter nästa uppgradering.