Cloud VPN-status: læs ressourcens tilstand før IKE-loggen

En Cloud VPN-tunnel kører to livscyklusser på én gang, og de går ikke efter samme ur. Ressourcen skal tildeles og konfigureres, før den kan forhandle, og protokollen har derefter sin egen rækkefølge af IKE-beskeder. Et statusfelt kan rapportere det første, mens det intet brugbart siger om det andet. At læse dem som én ting er måden, hvorpå en nøgleuoverensstemmelse får skylden for en forsinkelse i klargøringen.

Begynd med ét tunnelobjekt og ét tidsvindue.

To livscyklusser, ét tunnelobjekt

Ressourcens livscyklus er udbyderens klargøring af tunnelen: adresser, konfiguration, kapacitet. Protokollens livscyklus begynder, når begge parter har nok konfiguration til at udveksle IKE_SA_INIT, derefter IKE_AUTH, derefter underordnede sikkerhedsassociationer. En tunnel, der stadig er i den første fase, er ikke fejlet i godkendelsen, fordi godkendelse endnu ikke er forsøgt.

Den forskel er hele problemet. Alt andet handler om at observere den uden at sammenlægge uvedkommende beskeder.

Læs objektet, ikke konsolresuméet

Spørg API’en om de to felter, der betyder noget, og intet andet, så svaret forbliver lille nok til at læse klokken tre om natten: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". Feltet status angiver livscyklusfasen, og detailedStatus bærer den læsbare årsag, der er knyttet til den. En fuld konfigurationsdump besvarer andre spørgsmål og er sværere at indsætte i en ticket. Skrivebeskyttede kald som dette kan ikke ændre tunnelen, hvilket betyder noget, mens hændelsen stadig er aktiv.

Notér kaldets tidsstempel ved siden af værdierne, fordi begge felter flytter sig.

ALLOCATING_RESOURCES er ikke en nøgleuoverensstemmelse

Når tunnelen rapporterer ALLOCATING_RESOURCES, er udbyderen stadig ved at samle objektet. En uoverensstemmelse i den foruddelte nøgle kan ikke observeres i den fase, og en blokeret peer-port er lige så ubevist. Det, du kan kontrollere, er den detaljerede besked, om projektet og tjenesten ser sunde ud, og om tunnelkonfigurationen er fuldstændig nok til, at peer’en overhovedet kan kontaktes. At udskifte hemmeligheden nu ændrer en værdi, der aldrig blev testet.

Vent på, at tilstanden ændrer sig, før du drager en konklusion om konfigurationen.

ESTABLISHED er starten på adgangskontrollerne

En etableret tunnel betyder, at IKE blev fuldført, ikke at trafikken flyder. Bekræft de ruter, tunnelen bærer, og bekræft, hvor en Cloud Router er involveret, BGP-sessionen og de præfikser, den har lært. Test derefter en tilladt applikationsudveksling, fordi en firewallregel eller en manglende rute kan blokere trafik gennem en tunnel, der er helt sund. Hver af disse er en separat observation med en separat rettelse.

Status fortæller dig, hvilket spørgsmål du skal stille næste gang. Den besvarer aldrig adgangsspørgsmålet for dig.

Korrelér ét objekt og ét tidsvindue

En gammel godkendelsesfejl i loggen hører til et tidligere forsøg, medmindre dens tidsstempel falder inden for det vindue, du undersøger. Træk loggene for tunnelressourcen for de samme minutter som den registrerede status, og hold identifikatorerne sammen. En senere IKE-hændelse kan vise, at forhandlingen er begyndt, mens den konsolbesked, du stirrer på, allerede er forældet.

Hvis tunnelen kommer sig, før du indsamler noget, så sig det. En ubestemt årsag er en bedre registrering end en selvsikker historie samlet af uvedkommende linjer.

Det næste skridt har altid samme form: ét objekt, ét vindue, én fase. Alt bredere er et resumé, ikke en diagnose.