La VM de Azure no llega a IMDS ni a WireServer tras iniciar la VPN

La VM está encendida, el cliente VPN dice que está conectado y pocos minutos después el agente de Azure empieza a informar que no está sano. A veces SSH sobrevive y Run Command del portal no, lo que lleva a la gente a mirar el agente en lugar de la tabla de rutas. Las decisiones de reenvío del invitado cambiaron cuando subió el túnel, y dos direcciones de plataforma suelen ser las primeras víctimas. Lo trato como un síntoma de enrutamiento antes que como un fallo del agente.

El síntoma parece un agente roto

Ambas direcciones de abajo se proponen como solución, y no son el mismo servicio. Copiar una /32 para una porque funcionó para la otra es exactamente cómo un apaño temporal se convierte en una configuración permanente que nadie se atreve a quitar.

El orden que funciona es confirmar qué dirección apunta realmente la llamada que falla y luego leer cómo la resuelve el invitado. Todo lo demás es adivinar con pasos extra y una ventana de cambio más larga.

168.63.129.16 no es un destino público

168.63.129.16 es la dirección virtual especial de la plataforma Azure, y uno de sus papeles es WireServer, que el agente de la VM usa para hablar con el tejido. Microsoft documenta que el tráfico del agente hacia los puertos TCP 80 y 32526 debe seguir disponible. No es un host de internet corriente, y no es algo que una VPN de túnel completo deba llevar a una salida remota. Por eso un túnel que parece sano aún puede dejar sin comida al agente.

La documentación de la dirección de plataforma también dice que esta dirección no está sujeta a rutas definidas por el usuario, lo cual es una propiedad del tejido de Azure y no una promesa sobre tu invitado. Una regla local de cortafuegos o la propia política de enrutamiento del cliente VPN todavía pueden romper el camino, y ninguna de las dos vive en la tabla de rutas de la VNet.

Si es el agente quien informa del problema, comprueba el estado del servicio y el camino hacia esa dirección antes de reinstalar nada.

169.254.169.254 tiene sus propias reglas

169.254.169.254 es la dirección link-local del servicio Azure Instance Metadata Service. Las peticiones hacia ella tienen requisitos propios: la NIC y la IP primarias, una configuración DHCP que admita la dirección y la omisión de cualquier proxy HTTP. Enviarlas por una salida VPN remota o una puerta de enlace de internet arbitraria no es el modelo de acceso que describe Microsoft.

Esa cláusula de proxy atrapa a quien arregló la ruta y sigue viendo fallos. Un proxy HTTP en el invitado puede romper IMDS mientras ip route get devuelve exactamente la interfaz que esperas, así que revisa las exclusiones de proxy además de las rutas.

No pegues respuestas de metadatos en un ticket de soporte mientras depuras esto. Pueden llevar credenciales y detalles de instancia que sobreviven al incidente.

Lee el enrutamiento por política del invitado, no solo la tabla principal

En un invitado Linux, tres órdenes de solo lectura separan las capas: ip -4 rule show para las reglas de política, luego ip -4 route get 168.63.129.16 y ip -4 route get 169.254.169.254 para las decisiones que el núcleo toma realmente. Ejecútalas antes y después de que conecte la VPN. La diferencia entre esas dos salidas es tu conjunto de cambios, y es más útil que cualquier conjetura sobre lo que hizo el cliente.

Un cliente VPN que instala reglas de política puede dejar la tabla principal intacta y aun así redirigir esas consultas. Por eso una solución que solo toca la tabla principal parece funcionar en un host y no hace nada en el siguiente. Los invitados con varias NIC añaden el mismo problema desde el otro lado, porque la respuesta depende de qué NIC y qué dirección de origen elija la regla.

Resiste la receta que añade ambas rutas /32 por la puerta de enlace antigua. Un camino de plataforma link-local y un siguiente salto WAN general son objetos distintos, y una excepción global esconde el conflicto de política real.

Mantén la administración y la recuperación separadas

Tu respuesta SSH o RDP también puede ser capturada por un default de túnel completo, pero apunta a la dirección observada del administrador y no a ningún extremo de plataforma. Diagnostícala desde su propio par de petición y respuesta, y mantén un canal de recuperación independiente como la consola serie antes de cambiar la política de VPN. Si un despliegue reinicia la VM y el agente informa que no está sano, inspecciona la acción registrada y el servicio responsable en lugar de suponer que el cambio de ruta causó el reinicio.

Después verifica los tres flujos por separado: el recurso privado que de verdad querías, la comunicación admitida del agente y la plataforma, y el camino de administración. Restaurar uno no es prueba de que los otros dos sobrevivieran.

Escribe la excepción aprobada a nombre de quien posee la red del invitado y la configuración de la VPN, incluido qué ocurre al reconectar y reiniciar. Los UDR de Azure no son la tabla de rutas del invitado, y editarlos no arreglará una regla local de política.