GCP HA VPN avviser FortiGate: lokal ID-type passer ikke
Google sammenligner identiteten en FortiGate hevder, ikke bare den forhåndsdelsatte nøkkelen. En lokal FQDN-ID feiler den kontrollen mens loggen fortsatt sier autentisering.
AUTHENTICATION_FAILED fra Google Cloud HA VPN sender vanligvis folk tilbake til den forhåndsdelsatte nøkkelen, og nøkkelen er som regel riktig. Tunnelen stopper i fase 1 fordi Google også sammenligner noe annet: identiteten peer-en hevder under IKE-utvekslingen. På en FortiGate kan den identiteten skifte type uten at noen redigerer en adresse. Les loggen som en identitetskonflikt når nøkkelen er skrevet inn på nytt to ganger.
Én feil, to kontroller
IKE verifiserer en peer i to separate trinn. Den forhåndsdelsatte nøkkelen beviser at begge ender har samme hemmelighet, og en hevdet identitet forteller svareren hvem peer-en påstår å være. Google kontrollerer den identiteten mot peer-en den ble konfigurert med. Uten inngrep sender en FortiGate en adressebasert identitet utledet fra det utgående grensesnittet, og sammenligningen passerer uten at noen merker det.
Begge trinnene havner i samme bøtte i loggen, noe som forklarer den kjente løkken med å skrive nøkkelen fire ganger før noen leser identitetsnyttelasten.
Hva en FortiGate legger i identitetsnyttelasten
Problemet starter når noen setter en lokal ID for å få de to sidene til å stemme. Nyere FortiOS-bygg markerer den identiteten som et fullt kvalifisert domenenavn selv når verdien som tastes inn er en adresse med punkter. Google mottar derfor en FQDN-identitet mens det forventer en adresse, og avviser sesjonen. Ingenting i meldingen sier hvilken halvdel som feilet, så rapporten leses som en autentiseringsfeil.
Reproduser det én gang med IKE-feilsøking slått på og les identitetsnyttelasten brannmuren faktisk sender.
Bekreft i samme runde tre billige fakta: IKE-versjonen begge ender bruker, den nøyaktige nøkkelen inkludert usynlige slutttegn, og peer-adressen Google forventer. De svarer på ulike spørsmål, og en nøkkel som passer sier ingenting om identiteten.
Alternativer, og hva hver koster
Hver utvei reparerer et annet lag, og ingen av dem er tilgjengelig for hver 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 reneste svaret der fastvaren lar deg velge typen og beholde verdien. Feltet finnes i noen bygg og fyller typen feil i andre, så test din versjon i stedet for å stole på utgivelsesnotatene.
En rutbar offentlig adresse på forhandlingsgrensesnittet er den dokumenterte omveien, fordi standardidentiteten da passer med det Google forventer og ingen overstyring trengs. Det er dit de fleste utrullinger kommer, hvis brannmuren i det hele tatt kan holde en slik adresse.
Å terminere på en peer som validerer det du produserer, er en topologiendring. Behandle det som en designbeslutning og ikke som en omvei med en vennligere beskrivelse.
Når NAT fjerner ett alternativ
Bak NAT forsvinner utveien via offentlig adresse, og det som gjenstår avhenger av fastvareatferd du ikke kontrollerer. Det er punktet der du bevisst velger mellom å oppgradere, flytte peer-en eller godta et annet skyendepunkt. Det er tre forskjellige budsjetter, og å velge ett ved uhell er hvordan en midlertidig omvei blir arkitektur. Skriv valget og grunnen ved siden av tunnelen.
Før du tolker noe av dette, bekreft tunnelens tilstand på Google-siden og at IKE ikke bare droppes underveis. En droppet pakke går ut på tid; den gir ingen avvisning.
Hva som skal noteres mens det virker
Noter identitetstypen, verdien, fastvareversjonen og peer-adressen som gjaldt da tunnelen sist kom opp. En fastvareoppdatering kan endre standarden igjen, og neste feil vil se nøyaktig ut som en nøkkelkonflikt. Med identiteten lagret ved siden av nøkkelen og peer-adressen starter neste person på de billige kontrollene.
Den registreringen er også den eneste måten å vite om en omvei fortsatt trengs etter neste oppgradering.