A VM do Azure não chega ao IMDS nem ao WireServer após o VPN iniciar

A VM está ligada, o cliente VPN diz que está conectado e poucos minutos depois o agente do Azure começa a relatar um estado não saudável. Por vezes o SSH sobrevive e o Run Command do portal não, o que leva as pessoas a olhar para o agente em vez da tabela de rotas. As decisões de encaminhamento do convidado mudaram quando o túnel subiu, e dois endereços de plataforma são normalmente as primeiras vítimas. Trato isso como um sintoma de encaminhamento antes de o tratar como falha do agente.

O sintoma parece um agente avariado

Ambos os endereços abaixo são propostos como correção, e não são o mesmo serviço. Copiar um /32 para um porque funcionou para o outro é exatamente como um contorno temporário se torna uma configuração permanente que ninguém ousa remover.

A ordem que funciona é confirmar qual endereço a chamada que falha realmente atinge e depois ler como o convidado o resolve. Todo o resto é adivinhar com passos extra e uma janela de alteração mais longa.

168.63.129.16 não é um destino público

168.63.129.16 é o endereço virtual especial da plataforma Azure, e um dos seus papéis é o WireServer, que o agente da VM usa para falar com a fabric. A Microsoft documenta que o tráfego do agente para as portas TCP 80 e 32526 deve permanecer disponível. Não é um anfitrião de internet comum, e não é algo que um VPN de túnel completo deva transportar para uma saída remota. É por isso que um túnel que parece saudável ainda pode deixar o agente sem resposta.

A documentação do endereço de plataforma também diz que este endereço não está sujeito a rotas definidas pelo utilizador, o que é uma propriedade da fabric Azure e não uma promessa sobre o seu convidado. Uma regra local de firewall ou a própria política de encaminhamento do cliente VPN ainda podem quebrar o caminho, e nenhuma delas vive na tabela de rotas da VNet.

Se é o agente que reporta o problema, verifique o estado do serviço e o caminho até esse endereço antes de reinstalar seja o que for.

169.254.169.254 tem as suas próprias regras

169.254.169.254 é o endereço link-local do Azure Instance Metadata Service. Os pedidos para ele têm requisitos próprios: a NIC e o IP primários, uma configuração DHCP que suporte o endereço e a omissão de qualquer proxy HTTP. Enviá-los por uma saída VPN remota ou por um gateway de internet arbitrário não é o modelo de acesso que a Microsoft descreve.

Essa cláusula de proxy apanha quem corrigiu a rota e continua a ver falhas. Um proxy HTTP no convidado pode quebrar o IMDS enquanto ip route get devolve exatamente a interface que espera, por isso verifique as exclusões de proxy além das rotas.

Não cole respostas de metadados num ticket de suporte enquanto depura isto. Podem conter credenciais e detalhes da instância que sobrevivem ao incidente.

Leia o encaminhamento por política do convidado, não apenas a tabela principal

Num convidado Linux, três comandos só de leitura separam as camadas: ip -4 rule show para as regras de política, depois ip -4 route get 168.63.129.16 e ip -4 route get 169.254.169.254 para as decisões que o kernel realmente toma. Execute-os antes e depois de o VPN ligar. A diferença entre essas duas saídas é o seu conjunto de alterações, e é mais útil do que qualquer suposição sobre o que o cliente fez.

Um cliente VPN que instala regras de política pode deixar a tabela principal intacta e ainda redirecionar essas consultas. É por isso que uma correção só na tabela principal parece funcionar num anfitrião e não faz nada no seguinte. Convidados com várias NIC acrescentam o mesmo problema do outro lado, porque a resposta depende de qual NIC e endereço de origem a regra escolhe.

Resista à receita que acrescenta ambas as rotas /32 pelo gateway antigo. Um caminho de plataforma link-local e um próximo salto WAN genérico são objetos diferentes, e uma exceção global esconde o conflito de política real.

Mantenha a administração e a recuperação separadas

A sua resposta SSH ou RDP também pode ser capturada por um default de túnel completo, mas aponta para o endereço observado do administrador e não para um endpoint da plataforma. Diagnostique-a a partir do seu próprio par pedido-resposta e mantenha um canal de recuperação independente, como a consola série, antes de alterar a política de VPN. Se uma implementação reinicia a VM e o agente reporta um estado não saudável, inspecione a ação registada e o serviço responsável em vez de assumir que a alteração de rota causou o reinício.

Depois verifique os três fluxos separadamente: o recurso privado que realmente queria, a comunicação suportada entre agente e plataforma e o caminho administrativo. Restaurar um deles não é prova de que os outros dois sobreviveram.

Escreva a exceção aprovada em nome do proprietário da rede do convidado e da configuração do VPN, incluindo o que acontece ao reconectar e reiniciar. Os UDR do Azure não são a tabela de rotas do convidado, e editá-los não corrige uma regra local de política.