Cloud VPN-stato: legu la staton de la rimedo antaŭ la IKE-protokolo

Cloud VPN-tunelo funkciigas du vivciklojn samtempe, kaj ili ne estas sur la sama horloĝo. La rimedo devas esti asignita kaj agordita antaŭ ol ĝi povas intertrakti, kaj poste la protokolo havas sian propran sinsekvon de IKE-mesaĝoj. Statkampo povas raporti la unuan, dirante nenion utilan pri la dua. Legi ilin kiel unu aferon estas kiel malkongruo de ŝlosilo ricevas la kulpon por prokrasto en provizado.

Komencu per unu tunela objekto kaj unu tempofenestro.

Du vivcikloj, unu tunela objekto

La vivciklo de la rimedo estas la preparado de la tunelo fare de la provizanto: adresoj, agordo, kapacito. La vivciklo de la protokolo komenciĝas kiam ambaŭ flankoj havas sufiĉan agordon por interŝanĝi IKE_SA_INIT, poste IKE_AUTH, poste infanajn sekurecajn asociojn. Tunelo ankoraŭ en la unua fazo ne malsukcesis ĉe aŭtentigo, ĉar aŭtentigo ankoraŭ ne estis provita.

Tiu distingo estas la tuta problemo. Ĉio alia estas kiel observi ĝin sen kunfandi nerilatajn mesaĝojn.

Legu la objekton, ne la konzolan resumon

Petu de la API la du kampojn, kiuj gravas, kaj nenion alian, por ke la respondo restu sufiĉe malgranda por legi ĝin je la tria matene: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". La kampo status nomas la vivciklan etapon, kaj detailedStatus portas la legeblan kialon ligitan al ĝi. Plena agorda eligo respondas aliajn demandojn kaj estas pli malfacile algluebla en bileton. Tiaj nurlegaj alvokoj ne povas ŝanĝi la tunelon, kio gravas dum la incidento ankoraŭ vivas.

Notu la tempostampon de la alvoko apud la valoroj, ĉar ambaŭ kampoj moviĝas.

ALLOCATING_RESOURCES ne estas malkongruo de ŝlosilo

Kiam la tunelo raportas ALLOCATING_RESOURCES, la provizanto ankoraŭ kunmetas la objekton. Malkongruo de antaŭe dividita ŝlosilo ne observeblas en tiu etapo, kaj blokita pordo de la samtavola nodo same ne pruviĝas. Kion vi povas kontroli, estas la detala mesaĝo, ĉu la projekto kaj la servo aspektas sanaj, kaj ĉu la tunela agordo estas sufiĉe kompleta por ke oni povu entute kontakti la samtavolan nodon. Anstataŭigi la sekreton nun ŝanĝas valoron, kiu neniam estis testita.

Atendu, ke la stato moviĝu, antaŭ ol fari konkludon pri la agordo.

ESTABLISHED estas la komenco de la alir-kontroloj

Firmigita tunelo signifas, ke IKE finiĝis, ne ke trafiko fluas. Konfirmu la itinerojn, kiujn la tunelo portas, kaj, kie Cloud Router partoprenas, konfirmu la BGP-seancon kaj la prefiksojn, kiujn ĝi lernis. Poste testu permesitan aplikaĵinterŝanĝon, ĉar fajroŝirma regulo aŭ mankanta itinero povas bloki trafikon tra tute sana tunelo. Ĉiu el tiuj estas aparta observo kun aparta korekto.

Stato diras al vi, kiun demandon sekve fari. Ĝi neniam respondas anstataŭ vi la demandon pri aliro.

Koreligu unu objekton kaj unu tempofenestron

Malnova aŭtentiga malsukceso en la protokolo apartenas al pli frua provo, krom se ĝia tempostampo falas en la fenestron, kiun vi esploras. Eltiru la protokolojn por la tunela rimedo por la samaj minutoj kiel la registrita stato, kaj tenu la identigilojn kune. Pli posta IKE-evento povas montri, ke intertraktado komenciĝis, dum la konzola mesaĝo, kiun vi fiksrigardas, jam estas kaduka.

Se la tunelo resaniĝas antaŭ ol vi kolektas ion, diru tion. Nedeterminita kaŭzo estas pli bona registro ol memfida rakonto kunmetita el nerilataj linioj.

La sekva paŝo ĉiam havas la saman formon: unu objekto, unu fenestro, unu etapo. Io pli larĝa estas resumo, ne diagnozo.