Azure P2S: un cliente Windows se queda sin rutas tras un cambio de VNet

Dos portátiles se autentican en la misma puerta de enlace Azure point-to-site y solo uno llega a la VNet recién conectada. Ambos muestran Connected, así que la autenticación no es la diferencia; lo son las rutas de destino que mantienen. Empieza por el cliente que falla, compara un solo destino y solo después decide si el hueco es del paquete de la puerta de enlace o de la tabla de rutas local.

Empieza por el cliente que falla, no por la puerta de enlace

Confirma la topología antes de culpar al portátil. Comprueba qué VNet están conectadas a la VNet de la puerta de enlace y si la red nueva está emparejada directamente o se alcanza por un túnel site-to-site aparte. Si la VNet nueva no está conectada a la VNet de la puerta de enlace, ningún paquete de cliente puede enrutar hacia ella, y el portátil que funciona es la anomalía que hay que explicar. Anota la respuesta, porque decide si depuras un cliente o una puerta de enlace.

Cuando la topología cuadre, pon los dos portátiles uno junto al otro. La misma puerta de enlace, el mismo grupo de direcciones, el mismo protocolo y la misma versión del cliente son la comparación que quieres; cualquier otra cosa es una segunda variable que tendrás que eliminar después.

Compara un destino con route print

Elige una IP de recurso permitida y compara ambos portátiles dos veces: desconectados y luego conectados. En Windows, route print -4 lista las rutas IPv4 con el prefijo de destino, la interfaz, el siguiente salto y la métrica. Anota la fila que realmente ganaría para ese destino en lugar de contar entradas que contengan la palabra VPN.

La selección es primero el prefijo más largo y luego la métrica, así que una ruta local más específica puede ganar a la ruta del túnel sin parecer incorrecta. Si el destino previsto está dentro de 10.24.0.0/16, un cliente sano muestra una ruta coincidente en la interfaz VPN, mientras que el cliente que falla envía la misma dirección a su puerta de enlace predeterminada.

Un prefijo local en conflicto puede producir el mismo síntoma. Antes de añadir nada, decide cuál de los dos casos tienes: ninguna ruta de túnel, o una ruta de túnel que pierde frente a una más específica.

TTL expired no es un fallo de distribución de rutas

Un ping que devuelve TTL expired in transit dice que el paquete agotó su cupo de saltos, lo que suele significar un bucle de reenvío y no un controlador VPN roto. El ping de Windows acepta un TTL de hasta 255, y subir el valor no repara un bucle; solo retrasa el mismo error. Trata el mensaje como un síntoma de la ruta, no como prueba sobre la distribución de rutas.

Usa tracert -4 10.24.1.10 para ver dónde se repite el camino. Si los mismos dos saltos aparecen una y otra vez, busca una ruta que devuelva el tráfico destinado al túnel al túnel o a un enrutador local que lo reenvíe de vuelta.

Regenera el paquete en la puerta de enlace que lo posee

Microsoft documenta que los paquetes de cliente de Windows deben descargarse e instalarse de nuevo tras cambios de topología relevantes. Obtén el paquete actual de la puerta de enlace de Azure que sirve este perfil y aplícalo con el proceso admitido para ese cliente. Sustituir el ejecutable de una aplicación VPN no relacionada no es la misma operación que regenerar ajustes específicos de la puerta de enlace. Volver a descargar el paquete es barato; adivinar rutas locales no lo es.

Vuelve a conectarte y relee la ruta del destino original. Guarda las filas de antes y después con el registro del cambio para que el resultado sea más preciso que reinstalé el cliente.

Los escenarios de enrutamiento de Azure P2S separan las VNet emparejadas directamente de las redes a las que se llega por otros túneles, y un paquete nuevo no puede hacer transitivo el emparejamiento. Algunos escenarios Windows site-to-site o BGP también necesitan rutas remotas configuradas a mano, así que refrescar el paquete no es un mecanismo universal de distribución de rutas.

Mantén temporal una ruta temporal

Una ruta manual puede aislar una ruta de cliente ausente, pero constrúyela desde el diseño real: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, sin el indicador persistente, para que desaparezca al reiniciar. Elige el índice de interfaz y el siguiente salto del adaptador VPN conectado, no de una suposición.

No dejes una ruta experimental como propietario competidor permanente. Actualizaciones futuras del perfil pueden añadir el mismo prefijo con otra métrica, y entonces la entrada manual decide en silencio qué camino gana. Anota el paso de retirada en el cambio.

Una vez activa la ruta correcta, prueba la aplicación de destino en lugar de un ping. Si los paquetes llegan a Azure pero el servicio sigue fallando, revisa el grupo de seguridad de red y el camino de vuelta, porque son independientes de si el portátil aprendió el prefijo.