A VM de Azure non chega a IMDS nin a WireServer despois de iniciar a VPN

A VM está acendida, o cliente VPN di que está conectado e poucos minutos despois o axente de Azure comeza a informar de que non está san. Ás veces SSH sobrevive e Run Command do portal non, o que leva a xente a mirar o axente en lugar da táboa de rutas. As decisións de reenvío do convidado cambiaron cando subiu o túnel, e dúas direccións de plataforma adoitan ser as primeiras vítimas. Trátoo como un síntoma de enrutamento antes que como un fallo do axente.

O síntoma parece un axente roto

As dúas direccións de abaixo proponse como solución, e non son o mesmo servizo. Copiar unha /32 para unha porque funcionou para a outra é exactamente como unha solución temporal se converte nunha configuración permanente que ninguén se atreve a quitar.

A orde que funciona é confirmar que dirección apunta realmente a chamada que falla e despois ler como a resolve o convidado. Todo o demais é adiviñar con pasos extra e unha xanela de cambio máis longa.

168.63.129.16 non é un destino público

168.63.129.16 é a dirección virtual especial da plataforma Azure, e un dos seus papeis é WireServer, que o axente da VM usa para falar co tecido. Microsoft documenta que o tráfico do axente cara aos portos TCP 80 e 32526 debe seguir dispoñible. Non é un host de internet corrente, e non é algo que unha VPN de túnel completo deba levar a unha saída remota. Por iso un túnel que parece san aínda pode deixar sen comida o axente.

A documentación da dirección de plataforma tamén di que esta dirección non está suxeita a rutas definidas polo usuario, o cal é unha propiedade do tecido de Azure e non unha promesa sobre o teu convidado. Unha regra local de cortafuegos ou a propia política de enrutamento do cliente VPN aínda poden romper o camiño, e ningunha das dúas vive na táboa de rutas da VNet.

Se é o axente quen informa do problema, comproba o estado do servizo e o camiño cara a esa dirección antes de reinstalar nada.

169.254.169.254 ten as súas propias regras

169.254.169.254 é a dirección link-local do servizo Azure Instance Metadata Service. As peticións cara a ela teñen requisitos propios: a NIC e a IP primarias, unha configuración DHCP que admita a dirección e a omisión de calquera proxy HTTP. Envialas por unha saída VPN remota ou unha pasarela de internet arbitraria non é o modelo de acceso que describe Microsoft.

Esa cláusula de proxy atrapa a quen arranxou a ruta e segue vendo fallos. Un proxy HTTP no convidado pode romper IMDS mentres ip route get devolve exactamente a interface que esperas, así que revisa as exclusións de proxy ademais das rutas.

Non pegues respostas de metadatos nun ticket de soporte mentres depuras isto. Poden levar credenciais e detalles de instancia que sobreviven ao incidente.

Le o enrutamento por política do convidado, non só a táboa principal

Nun convidado Linux, tres ordes de só lectura separan as capas: ip -4 rule show para as regras de política, despois ip -4 route get 168.63.129.16 e ip -4 route get 169.254.169.254 para as decisións que o núcleo toma realmente. Execútaas antes e despois de que conecte a VPN. A diferenza entre esas dúas saídas é o teu conxunto de cambios, e é máis útil que calquera conxectura sobre o que fixo o cliente.

Un cliente VPN que instala regras de política pode deixar a táboa principal intacta e aínda así redirixir esas consultas. Por iso unha solución que só toca a táboa principal parece funcionar nun host e non fai nada no seguinte. Os convidados con varias NIC engaden o mesmo problema desde o outro lado, porque a resposta depende de que NIC e que dirección de orixe elixa a regra.

Resiste a receita que engade as dúas rutas /32 pola pasarela antiga. Un camiño de plataforma link-local e un seguinte salto WAN xeral son obxectos distintos, e unha excepción global esconde o conflito de política real.

Mantén a administración e a recuperación separadas

A túa resposta SSH ou RDP tamén pode ser capturada por un default de túnel completo, pero apunta á dirección observada do administrador e non a ningún extremo de plataforma. Diagnostícaa desde o seu propio par de petición e resposta, e mantén un canal de recuperación independente como a consola serie antes de cambiar a política de VPN. Se un despregamento reinicia a VM e o axente informa de que non está san, inspecciona a acción rexistrada e o servizo responsable en lugar de supoñer que o cambio de ruta causou o reinicio.

Despois verifica os tres fluxos por separado: o recurso privado que de verdade querías, a comunicación admitida do axente e a plataforma, e o camiño de administración. Restaurar un non é proba de que os outros dous sobrevivisen.

Escribe a excepción aprobada a nome de quen posúe a rede do convidado e a configuración da VPN, incluído que ocorre ao reconectar e reiniciar. Os UDR de Azure non son a táboa de rutas do convidado, e editalos non arranxará unha regra local de política.