Cloud VPN-status: lees eerst de resourcestatus, dan het IKE-log

Een Cloud VPN-tunnel draait twee levenscycli tegelijk, en ze lopen niet op dezelfde klok. De resource moet zijn toegewezen en geconfigureerd voordat er kan worden onderhandeld, en daarna heeft het protocol zijn eigen volgorde van IKE-berichten. Een statusveld kan het eerste melden zonder iets nuttigs over het tweede te zeggen. Ze als één ding lezen is de manier waarop een sleutelafwijking de schuld krijgt van een provisioning-vertraging.

Begin met één tunnelobject en één tijdvenster.

Twee levenscycli, één tunnelobject

De levenscyclus van de resource is de provider die de tunnel voorbereidt: adressen, configuratie, capaciteit. De levenscyclus van het protocol begint zodra beide kanten genoeg configuratie hebben om IKE_SA_INIT uit te wisselen, dan IKE_AUTH, dan onderliggende beveiligingsassociaties. Een tunnel die nog in de eerste fase zit, is niet mislukt op authenticatie, omdat authenticatie nog niet is geprobeerd.

Dat onderscheid is het hele probleem. Al het andere gaat over hoe je het waarneemt zonder losstaande berichten samen te voegen.

Lees het object, niet de consolesamenvatting

Vraag de API om de twee velden die ertoe doen en niets anders, zodat het antwoord klein genoeg blijft om om drie uur ’s nachts te lezen: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". Het veld status benoemt de fase van de levenscyclus, en detailedStatus draagt de leesbare reden die eraan hangt. Een volledige configuratiedump beantwoordt andere vragen en is lastiger in een ticket te plakken. Zulke alleen-lezen-aanroepen kunnen de tunnel niet wijzigen, wat uitmaakt zolang het incident nog loopt.

Noteer de tijdstempel van de aanroep naast de waarden, want beide velden bewegen.

ALLOCATING_RESOURCES is geen sleutelafwijking

Wanneer de tunnel ALLOCATING_RESOURCES meldt, stelt de provider het object nog samen. Een afwijking van de vooraf gedeelde sleutel is in die fase niet waarneembaar, en een geblokkeerde peer-poort is evenmin bewezen. Wat u kunt controleren is het gedetailleerde bericht, of het project en de dienst gezond lijken en of de tunnelconfiguratie volledig genoeg is om de peer überhaupt te kunnen bereiken. De geheime sleutel nu vervangen wijzigt een waarde die nooit is getest.

Wacht tot de status beweegt voordat u een conclusie over de configuratie trekt.

ESTABLISHED is het begin van de toegangscontroles

Een tot stand gebrachte tunnel betekent dat IKE is voltooid, niet dat er verkeer stroomt. Bevestig de routes die de tunnel draagt en, waar een Cloud Router betrokken is, bevestig de BGP-sessie en de prefixen die deze heeft geleerd. Test daarna een toegestane applicatie-uitwisseling, want een firewallregel of een ontbrekende route kan verkeer blokkeren door een tunnel die volledig gezond is. Elk daarvan is een aparte waarneming met een aparte correctie.

Status vertelt u welke vraag u hierna moet stellen. Het beantwoordt nooit de toegangsvraag voor u.

Correleer één object en één tijdvenster

Een oude authenticatiefout in het log hoort bij een eerdere poging, tenzij de tijdstempel binnen het venster valt dat u onderzoekt. Haal de logs van de tunnelresource op voor dezelfde minuten als de status die u noteerde, en houd de identificatoren bij elkaar. Een later IKE-gebeurtenis kan laten zien dat de onderhandeling is begonnen, terwijl het consolebericht waar u naar staart al verouderd is.

Als de tunnel zich herstelt voordat u iets verzamelt, zeg dat dan. Een onbepaalde oorzaak is een betere vastlegging dan een zelfverzekerd verhaal dat uit losstaande regels is samengesteld.

De volgende stap heeft altijd dezelfde vorm: één object, één venster, één fase. Alles breder is een samenvatting, geen diagnose.