Estado de Cloud VPN: lea el estado del recurso antes del registro de IKE

Un túnel de Cloud VPN ejecuta dos ciclos de vida a la vez, y no van en el mismo reloj. El recurso debe asignarse y configurarse antes de que pueda negociar, y después el protocolo tiene su propia secuencia de mensajes IKE. Un campo de estado puede informar del primero sin decir nada útil sobre el segundo. Leerlos como una sola cosa es como una discrepancia de clave acaba cargando con la culpa de un retraso de aprovisionamiento.

Empiece con un objeto de túnel y una ventana de tiempo.

Dos ciclos de vida, un objeto de túnel

El ciclo de vida del recurso es el proveedor preparando el túnel: direcciones, configuración, capacidad. El ciclo de vida del protocolo empieza cuando ambos pares tienen suficiente configuración para intercambiar IKE_SA_INIT, luego IKE_AUTH, luego asociaciones de seguridad hijas. Un túnel que sigue en la primera fase no ha fallado la autenticación, porque la autenticación aún no se ha intentado.

Esa distinción es todo el problema. Todo lo demás es cómo observarla sin fusionar mensajes no relacionados.

Lea el objeto, no el resumen de la consola

Pida a la API los dos campos que importan y nada más, para que la respuesta siga siendo lo bastante pequeña como para leerla a las tres de la madrugada: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". El campo status nombra la etapa del ciclo de vida, y detailedStatus lleva el motivo legible asociado a ella. Un volcado completo de la configuración responde a otras preguntas y es más difícil de pegar en un tique. Las llamadas de solo lectura como esta no pueden cambiar el túnel, lo que importa mientras el incidente sigue vivo.

Anote la marca de tiempo de la llamada junto a los valores, porque ambos campos se mueven.

ALLOCATING_RESOURCES no es una discrepancia de clave

Cuando el túnel informa de ALLOCATING_RESOURCES, el proveedor todavía está montando el objeto. Una discrepancia de clave precompartida no puede observarse en esa etapa, y un puerto del par bloqueado está igual de sin probar. Lo que sí puede comprobar es el mensaje detallado, si el proyecto y el servicio parecen sanos y si la configuración del túnel es lo bastante completa como para que se pueda contactar con el par. Sustituir el secreto ahora cambia un valor que nunca se probó.

Espere a que el estado se mueva antes de sacar una conclusión sobre la configuración.

ESTABLISHED es el comienzo de las comprobaciones de acceso

Un túnel establecido significa que IKE se completó, no que fluya el tráfico. Confirme las rutas que transporta el túnel y, donde intervenga un Cloud Router, confirme la sesión BGP y los prefijos que ha aprendido. Después pruebe un intercambio de aplicación permitido, porque una regla de cortafuegos o una ruta ausente pueden bloquear el tráfico por un túnel perfectamente sano. Cada una de esas es una observación separada con una corrección separada.

El estado le dice qué pregunta hacer después. Nunca responde por usted la pregunta del acceso.

Correlacione un objeto y una ventana de tiempo

Un fallo de autenticación antiguo en el registro pertenece a un intento anterior, salvo que su marca de tiempo caiga dentro de la ventana que investiga. Extraiga los registros del recurso del túnel para los mismos minutos que el estado que anotó, y mantenga los identificadores juntos. Un evento IKE posterior puede mostrar que la negociación ha comenzado mientras el mensaje de consola que mira ya está desfasado.

Si el túnel se recupera antes de que recoja nada, dígalo. Una causa indeterminada es un registro mejor que una historia segura montada con líneas no relacionadas.

El paso siguiente siempre tiene la misma forma: un objeto, una ventana, una etapa. Cualquier cosa más amplia es un resumen, no un diagnóstico.