Cloud VPN-status: läs resursens tillstånd före IKE-loggen

En Cloud VPN-tunnel kör två livscykler samtidigt, och de går inte på samma klocka. Resursen måste tilldelas och konfigureras innan den kan förhandla, och därefter har protokollet sin egen ordning av IKE-meddelanden. Ett statusfält kan rapportera det första utan att säga något användbart om det andra. Att läsa dem som en enda sak är hur en nyckelavvikelse får skulden för en försening i etableringen.

Börja med ett tunnelobjekt och ett tidsfönster.

Två livscykler, ett tunnelobjekt

Resursens livscykel är leverantörens förberedelse av tunneln: adresser, konfiguration, kapacitet. Protokollets livscykel börjar när båda sidor har tillräckligt med konfiguration för att utbyta IKE_SA_INIT, sedan IKE_AUTH, sedan underordnade säkerhetsassociationer. En tunnel som fortfarande är i första fasen har inte misslyckats med autentiseringen, eftersom autentiseringen ännu inte har försökts.

Den skillnaden är hela problemet. Allt annat handlar om hur man observerar den utan att slå ihop orelaterade meddelanden.

Läs objektet, inte konsolsammanfattningen

Fråga API:et efter de två fält som spelar roll och inget annat, så att svaret förblir litet nog att läsa klockan tre på natten: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". Fältet status namnger livscykelns fas, och detailedStatus bär det läsbara skälet som hör till den. En full konfigurationsdump svarar på andra frågor och är svårare att klistra in i ett ärende. Sådana skrivskyddade anrop kan inte ändra tunneln, vilket spelar roll medan incidenten fortfarande är aktiv.

Anteckna anropets tidsstämpel bredvid värdena, eftersom båda fälten rör sig.

ALLOCATING_RESOURCES är inte en nyckelavvikelse

När tunneln rapporterar ALLOCATING_RESOURCES håller leverantören fortfarande på att sätta ihop objektet. En avvikelse i den i förväg delade nyckeln kan inte observeras i den fasen, och en blockerad peer-port är lika obevisad. Det du kan kontrollera är det detaljerade meddelandet, om projektet och tjänsten ser friska ut och om tunnelkonfigurationen är tillräckligt fullständig för att peeren alls ska kunna kontaktas. Att byta hemligheten nu ändrar ett värde som aldrig testades.

Vänta tills tillståndet rör sig innan du drar en slutsats om konfigurationen.

ESTABLISHED är början på åtkomstkontrollerna

En etablerad tunnel betyder att IKE slutfördes, inte att trafik flödar. Bekräfta rutterna som tunneln bär och, där en Cloud Router är inblandad, bekräfta BGP-sessionen och prefixen den lärde sig. Testa sedan ett tillåtet applikationsutbyte, eftersom en brandväggsregel eller en saknad rutt kan blockera trafik genom en helt frisk tunnel. Var och en av dessa är en separat observation med en separat åtgärd.

Statusen säger vilken fråga du ska ställa härnäst. Den svarar aldrig på åtkomstfrågan åt dig.

Korrelera ett objekt och ett tidsfönster

Ett gammalt autentiseringsfel i loggen tillhör ett tidigare försök, om inte dess tidsstämpel faller inom det fönster du undersöker. Hämta loggarna för tunnelresursen för samma minuter som statusen du antecknade, och håll identifierarna tillsammans. En senare IKE-händelse kan visa att förhandlingen har börjat, medan konsolmeddelandet du stirrar på redan är inaktuellt.

Om tunneln återhämtar sig innan du samlar in något, säg det. En obestämd orsak är en bättre anteckning än en självsäker historia hopsatt av orelaterade rader.

Nästa steg har alltid samma form: ett objekt, ett fönster, en fas. Allt bredare är en sammanfattning, inte en diagnos.