Starea Cloud VPN: citiți starea resursei înainte de jurnalul IKE

Un tunel Cloud VPN rulează două cicluri de viață simultan, iar acestea nu sunt pe același ceas. Resursa trebuie alocată și configurată înainte de a putea negocia, iar după aceea protocolul are propria succesiune de mesaje IKE. Un câmp de stare poate raporta primul fără a spune nimic util despre al doilea. Citirea lor ca un singur lucru este felul în care o nepotrivire de cheie ajunge să fie vinovată pentru o întârziere de provizionare.

Începeți cu un obiect de tunel și o fereastră de timp.

Două cicluri de viață, un obiect de tunel

Ciclul de viață al resursei este furnizorul care pregătește tunelul: adrese, configurație, capacitate. Ciclul de viață al protocolului începe când ambele părți au suficientă configurație pentru a schimba IKE_SA_INIT, apoi IKE_AUTH, apoi asocieri de securitate copil. Un tunel aflat încă în prima fază nu a eșuat la autentificare, pentru că autentificarea nu a fost încă încercată.

Această distincție este toată problema. Restul este cum să o observați fără a fuziona mesaje fără legătură.

Citiți obiectul, nu rezumatul din consolă

Cereți API-ului cele două câmpuri care contează și nimic altceva, ca răspunsul să rămână suficient de mic pentru a fi citit la trei dimineața: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". Câmpul status numește etapa ciclului de viață, iar detailedStatus poartă motivul lizibil atașat acesteia. Un dump complet al configurației răspunde la alte întrebări și este mai greu de lipit într-un tichet. Astfel de apeluri doar pentru citire nu pot modifica tunelul, ceea ce contează cât timp incidentul este încă activ.

Notați marca de timp a apelului lângă valori, pentru că ambele câmpuri se mișcă.

ALLOCATING_RESOURCES nu este o nepotrivire de cheie

Când tunelul raportează ALLOCATING_RESOURCES, furnizorul încă asamblează obiectul. O nepotrivire a cheii prepartajate nu poate fi observată în acea etapă, iar un port al partenerului blocat este la fel de nedovedit. Ceea ce puteți verifica este mesajul detaliat, dacă proiectul și serviciul par sănătoase și dacă configurația tunelului este suficient de completă pentru ca partenerul să poată fi contactat. Înlocuirea secretului acum schimbă o valoare care nu a fost niciodată testată.

Așteptați ca starea să se miște înainte de a trage o concluzie despre configurație.

ESTABLISHED este începutul verificărilor de acces

Un tunel stabilit înseamnă că IKE s-a încheiat, nu că traficul curge. Confirmați rutele pe care le transportă tunelul și, unde este implicat un Cloud Router, confirmați sesiunea BGP și prefixele pe care le-a învățat. Apoi testați un schimb de aplicație permis, pentru că o regulă de firewall sau o rută lipsă pot bloca traficul printr-un tunel perfect sănătos. Fiecare dintre acestea este o observație separată cu o corecție separată.

Starea vă spune ce întrebare să puneți în continuare. Nu răspunde niciodată în locul dumneavoastră la întrebarea despre acces.

Corelați un obiect și o fereastră de timp

O veche eroare de autentificare din jurnal aparține unei încercări anterioare, cu excepția cazului în care marca sa de timp cade în fereastra pe care o investigați. Extrageți jurnalele pentru resursa de tunel pentru aceleași minute ca starea notată și țineți identificatorii împreună. Un eveniment IKE ulterior poate arăta că negocierea a început, în timp ce mesajul din consolă la care vă uitați este deja învechit.

Dacă tunelul se recuperează înainte de a colecta ceva, spuneți-o. O cauză nedeterminată este o înregistrare mai bună decât o poveste încrezătoare alcătuită din linii fără legătură.

Următorul pas are întotdeauna aceeași formă: un obiect, o fereastră, o etapă. Orice mai larg este un rezumat, nu un diagnostic.