GCP HA VPN rifiuta FortiGate: il tipo di ID locale non corrisponde
Google confronta l’identità che un FortiGate dichiara, non solo la chiave precondivisa. Un ID locale di tipo FQDN fallisce quel controllo mentre il registro parla ancora di autenticazione.
L’AUTHENTICATION_FAILED di Google Cloud HA VPN di solito riporta le persone alla chiave precondivisa, e la chiave di norma è corretta. Il tunnel si blocca in fase 1 perché Google confronta anche qualcos’altro: l’identità che il peer dichiara durante lo scambio IKE. Su un FortiGate quell’identità può cambiare tipo senza che nessuno modifichi un indirizzo. Leggete il registro come una discrepanza di identità una volta reinserita due volte la chiave.
Un guasto, due controlli
IKE verifica un peer in due passaggi separati. La chiave precondivisa dimostra che entrambe le estremità possiedono lo stesso segreto, e un’identità dichiarata dice al risponditore chi il peer afferma di essere. Google controlla quell’identità rispetto al peer con cui è stato configurato. Lasciato solo, un FortiGate invia un’identità basata sull’indirizzo derivata dalla sua interfaccia in uscita, e il confronto passa senza che nessuno se ne accorga.
Entrambi i passaggi finiscono nello stesso secchio del registro, il che spiega il solito ciclo di riscrivere la chiave quattro volte prima che qualcuno legga il payload dell’identità.
Che cosa mette un FortiGate nel payload dell’identità
Il problema inizia quando qualcuno imposta un ID locale per far coincidere i due lati. Le versioni recenti di FortiOS marcano quell’identità come nome di dominio completamente qualificato anche quando il valore digitato è un indirizzo con punti. Google riceve quindi un’identità FQDN mentre si aspetta un indirizzo, e rifiuta la sessione. Nulla nel messaggio dice quale metà ha fallito, quindi il rapporto si legge come un errore di autenticazione.
Riproducetelo una volta con il debug IKE attivo e leggete il payload dell’identità che il firewall emette davvero.
Nello stesso passaggio, confermate tre fatti economici: la versione IKE usata da entrambe le estremità, la chiave esatta compresi i caratteri finali invisibili, e l’indirizzo del peer che Google si aspetta. Rispondono a domande diverse, e una chiave corrispondente non dice nulla sull’identità.
Le opzioni, e quanto costa ciascuna
Ogni uscita corregge uno strato diverso, e nessuna è disponibile per ogni distribuzione.
| 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 |
Correggere l’identità sul firewall è la risposta più pulita dove il firmware consente di scegliere il tipo e mantenere il valore. Il campo esiste in alcune versioni e riempie male il tipo in altre, quindi provate la vostra versione invece di fidarvi delle note di rilascio.
Un indirizzo pubblico instradabile sull’interfaccia di negoziazione è la soluzione alternativa documentata, perché l’identità predefinita corrisponde allora a ciò che Google si aspetta e non serve alcuna sostituzione. È lì che finiscono la maggior parte delle distribuzioni, se il firewall può anche solo mantenere un indirizzo del genere.
Terminare su un peer che convalida ciò che producete è un cambio di topologia. Trattatelo come una decisione di progetto e non come una soluzione alternativa con una descrizione più amichevole.
Quando NAT elimina un’opzione
Dietro NAT l’uscita tramite indirizzo pubblico scompare, e ciò che resta dipende da un comportamento del firmware che non controllate. È il punto in cui scegliere deliberatamente tra aggiornare, spostare il peer o accettare un altro endpoint cloud. Sono tre budget diversi, e sceglierne uno per caso è il modo in cui una soluzione temporanea diventa architettura. Scrivete la scelta e il suo motivo accanto al tunnel.
Prima di interpretare qualunque cosa, confermate lo stato del tunnel sul lato Google e che IKE non venga semplicemente scartato lungo il percorso. Un pacchetto scartato va in timeout; non produce un rifiuto.
Che cosa annotare finché funziona
Annotate il tipo di identità, il suo valore, la versione del firmware e l’indirizzo del peer in vigore quando il tunnel è salito l’ultima volta. Un aggiornamento del firmware può cambiare di nuovo il valore predefinito, e il prossimo guasto sembrerà esattamente una discrepanza di chiave. Con l’identità salvata accanto alla chiave e all’indirizzo del peer, la persona successiva parte dai controlli economici.
Quel registro è anche l’unico modo per sapere se una soluzione alternativa serve ancora dopo il prossimo aggiornamento.