Stato di Cloud VPN: leggete lo stato della risorsa prima del log IKE

Un tunnel Cloud VPN esegue due cicli di vita insieme, e non sono sullo stesso orologio. La risorsa deve essere allocata e configurata prima di poter negoziare, e dopo il protocollo ha la propria sequenza di messaggi IKE. Un campo di stato può segnalare il primo senza dire nulla di utile sul secondo. Leggerli come un’unica cosa è il modo in cui una discrepanza di chiave si prende la colpa di un ritardo di provisioning.

Iniziate con un oggetto tunnel e una finestra temporale.

Due cicli di vita, un oggetto tunnel

Il ciclo di vita della risorsa è il provider che prepara il tunnel: indirizzi, configurazione, capacità. Il ciclo di vita del protocollo inizia quando entrambi i peer hanno abbastanza configurazione per scambiare IKE_SA_INIT, poi IKE_AUTH, poi associazioni di sicurezza figlie. Un tunnel ancora nella prima fase non ha fallito l’autenticazione, perché l’autenticazione non è ancora stata tentata.

Questa distinzione è tutto il problema. Il resto è come osservarla senza fondere messaggi non correlati.

Leggete l’oggetto, non il riepilogo della console

Chiedete all’API i due campi che contano e nient’altro, così la risposta resta abbastanza piccola da leggere alle tre di notte: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". Il campo status nomina la fase del ciclo di vita, e detailedStatus porta il motivo leggibile a essa associato. Un dump completo della configurazione risponde ad altre domande ed è più difficile da incollare in un ticket. Le chiamate di sola lettura come questa non possono cambiare il tunnel, il che conta mentre l’incidente è ancora in corso.

Annotate il timestamp della chiamata accanto ai valori, perché entrambi i campi si muovono.

ALLOCATING_RESOURCES non è una discrepanza di chiave

Quando il tunnel segnala ALLOCATING_RESOURCES, il provider sta ancora assemblando l’oggetto. Una discrepanza della chiave precondivisa non è osservabile in quella fase, e una porta del peer bloccata è altrettanto non dimostrata. Quello che potete verificare è il messaggio dettagliato, se il progetto e il servizio sembrano sani e se la configurazione del tunnel è abbastanza completa da poter contattare il peer. Sostituire il segreto adesso cambia un valore che non è mai stato testato.

Aspettate che lo stato si muova prima di trarre una conclusione sulla configurazione.

ESTABLISHED è l’inizio dei controlli di accesso

Un tunnel stabilito significa che IKE è terminato, non che il traffico scorra. Confermate le rotte che il tunnel trasporta e, dove è coinvolto un Cloud Router, confermate la sessione BGP e i prefissi che ha appreso. Poi provate uno scambio applicativo consentito, perché una regola del firewall o una rotta mancante possono bloccare il traffico attraverso un tunnel perfettamente sano. Ognuno di questi è un’osservazione separata con una correzione separata.

Lo stato vi dice quale domanda fare dopo. Non risponde mai al posto vostro alla domanda sull’accesso.

Correlate un oggetto e una finestra temporale

Un vecchio errore di autenticazione nel log appartiene a un tentativo precedente, a meno che il suo timestamp non cada nella finestra che state esaminando. Scaricate i log della risorsa tunnel per gli stessi minuti dello stato che avete annotato, e tenete insieme gli identificatori. Un evento IKE successivo può mostrare che la negoziazione è iniziata mentre il messaggio della console che state fissando è già obsoleto.

Se il tunnel si riprende prima che abbiate raccolto qualcosa, ditelo. Una causa indeterminata è un resoconto migliore di una storia sicura messa insieme da righe non correlate.

Il passo successivo ha sempre la stessa forma: un oggetto, una finestra, una fase. Qualsiasi cosa più ampia è un riepilogo, non una diagnosi.