GCP HA VPN avviser FortiGate: lokal ID-type passar ikkje
Google samanliknar identiteten ein FortiGate hevdar, ikkje berre den førehandsdelsame nøkkelen. Eit lokalt FQDN-ID fell på den kontrollen medan loggen framleis seier autentisering.
AUTHENTICATION_FAILED frå Google Cloud HA VPN sender vanlegvis folk tilbake til den førehandsdelsame nøkkelen, og nøkkelen er som regel rett. Tunnelen stoggar i fase 1 fordi Google òg samanliknar noko anna: identiteten peer-en hevdar under IKE-utvekslinga. På ein FortiGate kan den identiteten skifte type utan at nokon redigerer ei adresse. Les loggen som ein identitetskonflikt når nøkkelen er skriven inn på nytt to gonger.
Éin feil, to kontrollar
IKE stadfestar ein peer i to separate steg. Den førehandsdelsame nøkkelen beviser at begge endar har same løyndom, og ein hevda identitet fortel svararen kven peer-en påstår å vere. Google kontrollerer den identiteten mot peer-en han vart konfigurert med. Utan inngrep sender ein FortiGate ein adressebasert identitet utleidd frå det utgåande grensesnittet, og samanlikninga går gjennom utan at nokon merkar det.
Begge stega hamnar i same bøtta i loggen, noko som forklarer den kjende løkka med å skrive nøkkelen fire gonger før nokon les identitetsnyttelasta.
Kva ein FortiGate legg i identitetsnyttelasta
Problemet startar når nokon set ein lokal ID for å få dei to sidene til å stemme. Nyare FortiOS-bygg merkar den identiteten som eit fullt kvalifisert domenenamn sjølv når verdien som vert skriven inn er ei adresse med punkt. Google får difor ein FQDN-identitet medan det ventar ei adresse, og det avviser sesjonen. Ingenting i meldinga seier kva halvdel som feila, så rapporten vert lesen som ein autentiseringsfeil.
Reproduser det éin gong med IKE-feilsøking slått på og les identitetsnyttelasta brannmuren faktisk sender.
Stadfest i same runden tre billege faktum: IKE-versjonen begge endar brukar, den nøyaktige nøkkelen inkludert usynlege sluttteikn, og peer-adressa Google ventar. Dei svarar på ulike spørsmål, og ein nøkkel som passar seier ingenting om identiteten.
Alternativ, og kva kvart kostar
Kvar utveg reparerer eit anna lag, og ingen av dei er tilgjengelege for kvar utrulling.
| 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 |
Å rette identiteten på brannmuren er det reinaste svaret der fastvaren lét deg velje typen og halde verdien. Feltet finst i nokre bygg og fyller typen feil i andre, så test din versjon i staden for å stole på utgivingsnotata.
Ei rutbar offentleg adresse på forhandlingsgrensesnittet er den dokumenterte omvegen, fordi standardidentiteten då passar med det Google ventar og inga overstyring trengst. Det er dit dei fleste utrullingane kjem, om brannmuren i det heile kan halde ei slik adresse.
Å terminere på ein peer som validerer det du produserer, er ei topologiendring. Handsame det som eit designval og ikkje som ein omveg med ei venlegare skildring.
Når NAT fjernar eitt alternativ
Bak NAT forsvinn utvegen via offentleg adresse, og det som står att avheng av fastvareåtferd du ikkje styrer. Det er punktet der du medvite vel mellom å oppgradere, flytte peer-en eller godta eit anna skyendepunkt. Det er tre ulike budsjett, og å velje eitt ved uhell er korleis ein mellombels omveg vert arkitektur. Skriv valet og grunnen ved sida av tunnelen.
Før du tolkar noko av dette, stadfest tilstanden til tunnelen på Google-sida og at IKE ikkje berre vert droppa undervegs. Ein droppa pakke går ut på tid; han gjev inga avvising.
Kva som skal noterast medan det verkar
Noter identitetstypen, verdien, fastvareversjonen og peer-adressa som galdt då tunnelen sist kom opp. Ei fastvareoppdatering kan endre standarden igjen, og neste feil vil sjå nøyaktig ut som ein nøkkelkonflikt. Med identiteten lagra ved sida av nøkkelen og peer-adressa startar neste person på dei billege kontrollane.
Den registreringa er òg den einaste måten å vite om ein omveg framleis trengst etter neste oppgradering.