GCP HA VPN afviser FortiGate: lokal ID-type passer ikke
Google sammenligner den identitet, en FortiGate påstår, ikke kun den foruddelte nøgle. Et lokalt FQDN-ID fejler den kontrol, mens loggen stadig siger godkendelse.
AUTHENTICATION_FAILED fra Google Cloud HA VPN sender normalt folk tilbage til den foruddelte nøgle, og nøglen er som regel korrekt. Tunnelen går i stå i fase 1, fordi Google også sammenligner noget andet: den identitet, peer’en påstår under IKE-udvekslingen. På en FortiGate kan den identitet skifte type, uden at nogen redigerer en adresse. Læs loggen som en identitetsuoverensstemmelse, når nøglen er indtastet igen to gange.
Én fejl, to kontroller
IKE verificerer en peer i to separate trin. Den foruddelte nøgle beviser, at begge ender har den samme hemmelighed, og en påstået identitet fortæller svareren, hvem peer’en hævder at være. Google kontrollerer den identitet mod den peer, den blev konfigureret med. Uden indgreb sender en FortiGate en adressebaseret identitet udledt af sin udgående grænseflade, og sammenligningen består, uden at nogen bemærker det.
Begge trin lander i samme spand i loggen, hvilket forklarer den velkendte løkke med at skrive nøglen fire gange, før nogen læser identitetspakken.
Hvad en FortiGate lægger i identitetspakken
Problemet starter, når nogen sætter et lokalt ID for at få de to sider til at stemme. Nyere FortiOS-builds markerer den identitet som et fuldt kvalificeret domænenavn, selv når den indtastede værdi er en adresse med punktummer. Google modtager derfor en FQDN-identitet, mens den forventer en adresse, og afviser sessionen. Intet i meddelelsen siger, hvilken halvdel der fejlede, så rapporten læses som en godkendelsesfejl.
Genskab det én gang med IKE-fejlfinding slået til, og læs den identitetspakke, firewalls faktisk sender.
Bekræft i samme omgang tre billige fakta: den IKE-version, begge ender bruger, den præcise nøgle inklusive usynlige tegn til sidst, og den peer-adresse, Google forventer. De svarer på forskellige spørgsmål, og en nøgle, der passer, siger intet om identiteten.
Muligheder, og hvad hver koster
Hver udvej retter et forskelligt lag, og ingen af dem er tilgængelig for alle udrulninger.
| 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 |
At rette identiteten på firewalls er det reneste svar, hvor firmwaren lader dig vælge typen og beholde værdien. Feltet findes i nogle builds og udfylder typen forkert i andre, så test din version i stedet for at tro på udgivelsesnoterne.
En rutbar offentlig adresse på den forhandlende grænseflade er den dokumenterede omvej, fordi standardidentiteten så passer med det, Google forventer, og ingen tilsidesættelse er nødvendig. Det er der, de fleste udrulninger ender, hvis firewalls overhovedet kan holde en sådan adresse.
At terminere på en peer, der validerer det, du producerer, er en topologiændring. Behandl det som en designbeslutning frem for en omvej med en venligere beskrivelse.
Når NAT fjerner én mulighed
Bag NAT forsvinder udvejen via offentlig adresse, og det, der er tilbage, afhænger af firmwareadfærd, du ikke styrer. Det er punktet, hvor du bevidst vælger mellem at opgradere, flytte peer’en eller acceptere et andet cloud-endpoint. Det er tre forskellige budgetter, og at vælge ét ved et uheld er, hvordan en midlertidig omvej bliver til arkitektur. Skriv valget og dets begrundelse ved tunnelen.
Inden du fortolker noget af dette, skal du bekræfte tunnelens tilstand på Google-siden og at IKE ikke blot droppes undervejs. En droppet pakke udløber; den giver ikke en afvisning.
Hvad der skal noteres, mens det virker
Notér identitetstypen, dens værdi, firmwareversionen og den peer-adresse, der var gældende, da tunnelen sidst kom op. En firmwareopdatering kan ændre standarden igen, og den næste fejl vil se præcis ud som en nøgleuoverensstemmelse. Med identiteten gemt ved siden af nøglen og peer-adressen starter den næste person ved de billige kontroller.
Den registrering er også den eneste måde at vide, om en omvej stadig er nødvendig efter næste opgradering.