Cloud VPN-állapot: az IKE-napló előtt olvassa el az erőforrás állapotát

Egy Cloud VPN-alagút egyszerre két életciklust futtat, és ezek nincsenek ugyanazon az órán. Az erőforrást ki kell osztani és konfigurálni kell, mielőtt tárgyalhatna, utána pedig a protokollnak megvan a saját IKE-üzenetsorrendje. Egy állapotmező jelentheti az elsőt, miközben semmi hasznosat nem mond a másodikról. Ezeket egy dologként olvasni az az út, amelyen a kulcseltérés magára vállalja a kiépítési késés hibáját.

Kezdje egy alagútobjektummal és egy időablakkal.

Két életciklus, egy alagútobjektum

Az erőforrás életciklusa a szolgáltató alagút-előkészítése: címek, konfiguráció, kapacitás. A protokoll életciklusa akkor kezdődik, amikor mindkét félnek elegendő konfigurációja van az IKE_SA_INIT, majd az IKE_AUTH, majd a gyermek biztonsági társulások cseréjéhez. Az első fázisban lévő alagút nem bukott el a hitelesítésen, mert a hitelesítést még nem kísérelték meg.

Ez a különbség az egész probléma. Minden más arról szól, hogyan figyeljük meg anélkül, hogy összeolvasztanánk az össze nem tartozó üzeneteket.

Az objektumot olvassa, ne a konzol összefoglalóját

Kérje az API-tól azt a két mezőt, amely számít, és semmi mást, hogy a válasz elég kicsi maradjon ahhoz, hogy hajnali háromkor el lehessen olvasni: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". A status mező az életciklus szakaszát nevezi meg, a detailedStatus pedig az ehhez kapcsolt olvasható okot hordozza. A teljes konfigurációs kiírás más kérdésekre válaszol, és nehezebb beilleszteni egy jegybe. Az ilyen csak olvasási hívások nem változtathatják meg az alagutat, ami számít, amíg az esemény még él.

Jegyezze fel a hívás időbélyegét az értékek mellé, mert mindkét mező mozog.

Az ALLOCATING_RESOURCES nem kulcseltérés

Amikor az alagút ALLOCATING_RESOURCES állapotot jelent, a szolgáltató még az objektumot állítja össze. Az előre megosztott kulcs eltérése ebben a fázisban nem figyelhető meg, és a blokkolt partnerport ugyanolyan bizonyítatlan. Amit ellenőrizni tud, az a részletes üzenet, hogy a projekt és a szolgáltatás egészségesnek tűnik-e, és hogy az alagút konfigurációja elég teljes-e ahhoz, hogy a partnert egyáltalán el lehessen érni. A titok mostani lecserélése olyan értéket változtat meg, amelyet soha nem teszteltek.

Várja meg, hogy az állapot elmozduljon, mielőtt következtetést von le a konfigurációról.

Az ESTABLISHED a hozzáférési ellenőrzések kezdete

Egy létrejött alagút azt jelenti, hogy az IKE befejeződött, nem azt, hogy a forgalom folyik. Erősítse meg az alagút által hordozott útvonalakat, és ahol Cloud Router szerepel, erősítse meg a BGP-munkamenetet és a tanult előtagokat. Ezután teszteljen egy engedélyezett alkalmazásváltást, mert egy tűzfalszabály vagy egy hiányzó útvonal blokkolhatja a forgalmat egy teljesen egészséges alagúton keresztül. Ezek mindegyike külön megfigyelés külön javítással.

Az állapot megmondja, melyik kérdést tegye fel következőként. Soha nem válaszol helyette a hozzáférés kérdésére.

Korreláljon egy objektumot és egy időablakot

A naplóban lévő régi hitelesítési hiba egy korábbi kísérlethez tartozik, hacsak az időbélyege nem esik abba az ablakba, amelyet vizsgál. Húzza elő az alagút-erőforrás naplóit ugyanazokra a percekre, mint a feljegyzett állapot, és tartsa együtt az azonosítókat. Egy későbbi IKE-esemény megmutathatja, hogy a tárgyalás elkezdődött, miközben a konzolüzenet, amelyet bámul, már elavult.

Ha az alagút helyreáll, mielőtt bármit gyűjtene, mondja meg. A meghatározatlan ok jobb feljegyzés, mint az össze nem tartozó sorokból összerakott magabiztos történet.

A következő lépés mindig ugyanolyan alakú: egy objektum, egy ablak, egy szakasz. Bármi szélesebb összefoglaló, nem diagnózis.