Estat de Cloud VPN: llegiu l’estat del recurs abans del registre IKE

Un túnel de Cloud VPN executa dos cicles de vida alhora, i no van al mateix rellotge. El recurs s’ha d’assignar i configurar abans que pugui negociar, i després el protocol té la seva pròpia seqüència de missatges IKE. Un camp d’estat pot informar del primer sense dir res d’útil sobre el segon. Llegir-los com una sola cosa és com una discrepància de clau acaba carregant la culpa d’un retard d’aprovisionament.

Comenceu amb un objecte de túnel i una finestra de temps.

Dos cicles de vida, un objecte de túnel

El cicle de vida del recurs és el proveïdor preparant el túnel: adreces, configuració, capacitat. El cicle de vida del protocol comença quan tots dos parells tenen prou configuració per intercanviar IKE_SA_INIT, després IKE_AUTH, després associacions de seguretat filles. Un túnel encara en la primera fase no ha fallat l’autenticació, perquè l’autenticació encara no s’ha intentat.

Aquesta distinció és tot el problema. La resta és com observar-ho sense fusionar missatges sense relació.

Llegiu l’objecte, no el resum de la consola

Demaneu a l’API els dos camps que importen i res més, perquè la resposta continuï sent prou petita per llegir-la a les tres de la matinada: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". El camp status anomena l’etapa del cicle de vida, i detailedStatus porta el motiu llegible que hi va associat. Un abocament complet de la configuració respon altres preguntes i és més difícil d’enganxar en un tiquet. Les crides només de lectura com aquesta no poden canviar el túnel, cosa que importa mentre l’incident encara és viu.

Anoteu la marca de temps de la crida al costat dels valors, perquè tots dos camps es mouen.

ALLOCATING_RESOURCES no és una discrepància de clau

Quan el túnel informa d’ALLOCATING_RESOURCES, el proveïdor encara està muntant l’objecte. Una discrepància de clau prèviament compartida no es pot observar en aquesta etapa, i un port del par bloquejat tampoc no està provat. El que sí que podeu comprovar és el missatge detallat, si el projecte i el servei semblen sans i si la configuració del túnel és prou completa perquè el par es pugui contactar. Substituir el secret ara canvia un valor que mai no s’ha provat.

Espereu que l’estat es mogui abans de treure una conclusió sobre la configuració.

ESTABLISHED és l’inici de les comprovacions d’accés

Un túnel establert vol dir que l’IKE s’ha completat, no que hi passi trànsit. Confirmeu les rutes que porta el túnel i, on hi hagi un Cloud Router, confirmeu la sessió BGP i els prefixos que ha après. Després proveu un intercanvi d’aplicació permès, perquè una regla de tallafoc o una ruta que falta poden bloquejar el trànsit per un túnel perfectament sa. Cadascuna d’aquestes és una observació separada amb una correcció separada.

L’estat us diu quina pregunta cal fer després. Mai no respon la pregunta d’accés per vosaltres.

Relacioneu un objecte i una finestra de temps

Una fallada d’autenticació antiga del registre pertany a un intent anterior, tret que la seva marca de temps caigui dins de la finestra que investigueu. Traieu els registres del recurs de túnel per als mateixos minuts que l’estat que heu anotat, i manteniu els identificadors junts. Un esdeveniment IKE posterior pot mostrar que la negociació ha començat mentre el missatge de consola que mireu ja és obsolet.

Si el túnel es recupera abans que recolliu res, digueu-ho. Una causa indeterminada és un registre millor que una història segura muntada amb línies sense relació.

El pas següent sempre té la mateixa forma: un objecte, una finestra, una etapa. Qualsevol cosa més àmplia és un resum, no un diagnòstic.