GCP HA VPN respinge FortiGate: tipul ID-ului local nu se potrivește
Google compară identitatea pe care un FortiGate o declară, nu doar cheia prepartajată. Un ID local de tip FQDN eșuează la acea verificare, în timp ce jurnalul încă spune autentificare.
AUTHENTICATION_FAILED de la Google Cloud HA VPN trimite de obicei oamenii înapoi la cheia prepartajată, iar cheia este de regulă corectă. Tunelul se blochează în faza 1 pentru că Google compară și altceva: identitatea pe care partenerul o declară în timpul schimbului IKE. Pe un FortiGate acea identitate poate schimba tipul fără ca cineva să editeze o adresă. Citiți jurnalul ca o nepotrivire de identitate după ce cheia a fost reintrodusă de două ori.
O singură eroare, două verificări
IKE verifică un partener în două etape separate. Cheia prepartajată dovedește că ambele capete au același secret, iar o identitate declarată îi spune respondentei cine pretinde partenerul că este. Google compară acea identitate cu partenerul cu care a fost configurat. Lăsat singur, un FortiGate trimite o identitate bazată pe adresă, derivată din interfața sa de ieșire, iar comparația trece fără ca cineva să observe.
Ambele etape ajung în aceeași găleată din jurnal, ceea ce explică buclele cunoscute de rescriere a cheii de patru ori înainte ca cineva să citească payload-ul de identitate.
Ce pune un FortiGate în payload-ul de identitate
Problema începe când cineva setează un ID local ca cele două părți să fie de acord. Versiunile recente FortiOS marchează acea identitate ca nume de domeniu complet calificat chiar și când valoarea introdusă este o adresă cu puncte. Google primește astfel o identitate FQDN în timp ce așteaptă o adresă, și refuză sesiunea. Nimic din mesaj nu spune care jumătate a eșuat, așa că raportul se citește ca o eroare de autentificare.
Reproduceți-o o dată cu depanarea IKE activată și citiți payload-ul de identitate pe care firewallul îl emite efectiv.
În aceeași trecere, confirmați trei fapte ieftine: versiunea IKE folosită de ambele capete, cheia exactă inclusiv caracterele finale invizibile și adresa partenerului pe care Google o așteaptă. Ele răspund la întrebări diferite, iar o cheie potrivită nu spune nimic despre identitate.
Opțiuni și cât costă fiecare
Fiecare ieșire repară un strat diferit, și niciuna nu este disponibilă pentru fiecare implementare.
| 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 |
Corectarea identității pe firewall este cel mai curat răspuns acolo unde firmware-ul vă lasă să alegeți tipul și să păstrați valoarea. Câmpul există în unele versiuni și completează greșit tipul în altele, așa că testați-vă versiunea în loc să vă bazați pe notele de lansare.
O adresă publică rutabilă pe interfața de negociere este ocolul documentat, pentru că atunci identitatea implicită se potrivește cu ce așteaptă Google și nu mai e nevoie de nicio suprascriere. Acolo ajung majoritatea implementărilor, dacă firewallul poate ține deloc o asemenea adresă.
Terminarea pe un partener care validează ce produceți este o schimbare de topologie. Tratați-o ca o decizie de proiectare, nu ca ocol cu o descriere mai prietenoasă.
Când NAT elimină o opțiune
În spatele NAT ieșirea prin adresă publică dispare, iar ce rămâne depinde de un comportament al firmware-ului pe care nu îl controlați. Acesta este momentul să alegeți deliberat între actualizare, mutarea partenerului sau acceptarea altui punct final din cloud. Sunt trei bugete diferite, iar alegerea unuia din greșeală este felul în care un ocol temporar devine arhitectură. Scrieți alegerea și motivul ei lângă tunel.
Înainte de a interpreta orice, confirmați starea tunelului pe partea Google și că IKE nu este pur și simplu aruncat pe drum. Un pachet aruncat expiră; nu produce un refuz.
Ce să notați cât timp funcționează
Notați tipul identității, valoarea ei, versiunea de firmware și adresa partenerului care erau în vigoare când tunelul a urcat ultima dată. O actualizare de firmware poate schimba din nou valoarea implicită, iar următoarea eroare va arăta exact ca o nepotrivire de cheie. Cu identitatea salvată lângă cheie și adresa partenerului, următoarea persoană începe cu verificările ieftine.
Acea înregistrare este și singura modalitate de a afla dacă un ocol mai este necesar după următoarea actualizare.