Estado do Cloud VPN: leia o estado do recurso antes do log do IKE

Um túnel do Cloud VPN executa dois ciclos de vida ao mesmo tempo, e eles não estão no mesmo relógio. O recurso precisa ser alocado e configurado antes de poder negociar, e depois o protocolo tem a sua própria sequência de mensagens IKE. Um campo de estado pode relatar o primeiro sem dizer nada útil sobre o segundo. Ler os dois como uma coisa só é como uma divergência de chave acaba levando a culpa por um atraso de provisionamento.

Comece com um objeto de túnel e uma janela de tempo.

Dois ciclos de vida, um objeto de túnel

O ciclo de vida do recurso é o provedor preparando o túnel: endereços, configuração, capacidade. O ciclo de vida do protocolo começa quando os dois pares têm configuração suficiente para trocar IKE_SA_INIT, depois IKE_AUTH, depois associações de segurança filhas. Um túnel ainda na primeira fase não falhou na autenticação, porque a autenticação ainda não foi tentada.

Essa distinção é o problema inteiro. Todo o resto é como observá-la sem fundir mensagens não relacionadas.

Leia o objeto, não o resumo do console

Peça à API os dois campos que importam e nada mais, para que a resposta continue pequena o bastante para ser lida às três da manhã: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". O campo status nomeia a etapa do ciclo de vida, e detailedStatus carrega o motivo legível associado a ela. Um dump completo da configuração responde a outras perguntas e é mais difícil de colar num ticket. Chamadas somente de leitura como essa não podem alterar o túnel, o que importa enquanto o incidente ainda está ativo.

Anote o carimbo de data e hora da chamada ao lado dos valores, porque os dois campos se movem.

ALLOCATING_RESOURCES não é uma divergência de chave

Quando o túnel relata ALLOCATING_RESOURCES, o provedor ainda está montando o objeto. Uma divergência da chave pré-compartilhada não pode ser observada nessa etapa, e uma porta do par bloqueada está igualmente sem prova. O que você pode verificar é a mensagem detalhada, se o projeto e o serviço parecem saudáveis e se a configuração do túnel está completa o bastante para que o par possa ser contactado. Substituir o segredo agora altera um valor que nunca foi testado.

Espere o estado mudar antes de tirar uma conclusão sobre a configuração.

ESTABLISHED é o início das verificações de acesso

Um túnel estabelecido significa que o IKE foi concluído, não que o tráfego flui. Confirme as rotas que o túnel transporta e, onde houver um Cloud Router envolvido, confirme a sessão BGP e os prefixos que ela aprendeu. Depois teste uma troca de aplicação permitida, porque uma regra de firewall ou uma rota ausente podem bloquear o tráfego através de um túnel perfeitamente saudável. Cada uma dessas é uma observação separada com uma correção separada.

O estado diz qual pergunta fazer a seguir. Nunca responde por você à pergunta do acesso.

Correlacione um objeto e uma janela de tempo

Uma falha de autenticação antiga no log pertence a uma tentativa anterior, a menos que o carimbo de data e hora caia dentro da janela que você investiga. Puxe os logs do recurso de túnel para os mesmos minutos do estado que anotou, e mantenha os identificadores juntos. Um evento IKE posterior pode mostrar que a negociação começou enquanto a mensagem do console que você encara já está desatualizada.

Se o túnel se recuperar antes de você recolher qualquer coisa, diga isso. Uma causa indeterminada é um registro melhor do que uma história confiante montada com linhas não relacionadas.

O passo seguinte tem sempre a mesma forma: um objeto, uma janela, uma etapa. Qualquer coisa mais ampla é um resumo, não um diagnóstico.