Una ruta de VPN anclada a un índice de interfaz se rompe al reconectar

La ruta funcionó durante semanas y luego empezó a enviar tráfico a ninguna parte, con el destino intacto y sin haber editado nada. Lo que cambió es el número: una ruta creada contra un índice de interfaz concreto hace referencia a un adaptador que ya no existe tras reconectar, y el prefijo de destino sigue apuntando a una infraestructura que se sustituyó. Añadir persistencia a ese comando no ayuda, porque el problema nunca fue si la ruta sobrevivía a un reinicio. La solución es atar la intención a la conexión, que sobrevive a los cambios de adaptador por diseño.

Compruebe a qué apunta realmente la ruta

Empiece leyendo la entrada de la ruta y los adaptadores uno al lado del otro. Una ruta con un siguiente salto en la interfaz VPN y un índice que no coincide con ningún adaptador actual es la firma de este fallo; el mismo prefijo en otro índice es o un resto o la ruta que realmente quiere. Lea las dos listas antes de cambiar cualquiera de ellas, porque la comparación interesante está entre el número de la ruta y los números que existen ahora. Si el índice de la ruta aparece en la lista de adaptadores, el índice no es su problema y la búsqueda pasa a métricas, política o el extremo remoto. Si no aparece, no hay que diagnosticar nada más: la ruta está ligada a una infraestructura que ya no existe.

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

La columna Store distingue una entrada que persiste entre reinicios de una que desaparece con el adaptador, y esa diferencia determina si el fallo reaparecerá mañana. Una entrada en el almacén persistente que apunta a un índice desaparecido es el peor caso, porque sobrevive a los reinicios sin coincidir nunca con nada.

Ate el prefijo al perfil, no al adaptador

Un VPN nativo de Windows puede llevar su propia lista de rutas, de modo que la conexión reutiliza el adaptador correcto siempre que aparece. Entonces la ruta sigue al perfil en lugar de a un número que observó una vez, y ningún script tiene que adivinar un índice tras cada marcación. Añadir un prefijo también es reversible con el comando de eliminación correspondiente, lo que mantiene el cambio auditable. El prefijo se guarda con la conexión en lugar de en un script de inicio, así que un perfil copiado a otro usuario lleva la intención consigo.

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

La referencia de Add-VpnConnectionRoute documenta la asociación con la conexión, y el ámbito de la libreta de direcciones importa: un perfil por usuario y un perfil para todos los usuarios son objetos distintos. Este mecanismo pertenece al cliente VPN propio de Windows, así que un adaptador de fabricante gestionado por su propio servicio puede tomar sus rutas de una fuente de directiva completamente distinta.

Limpie las rutas antiguas antes de añadir la nueva

Dos rutas con el mismo prefijo y propietarios distintos son peor que una ruta equivocada, porque el ganador depende de métricas que nadie anotó. Inspeccione lo que ya existe para el prefijo, incluidas las entradas del almacén persistente, y elimine solo lo que pertenece al intento fallido. Un resto de un diseño anterior es habitual en esta área, ya que la ruta que falla suele haber sustituido algo que funcionaba. Anote qué entradas pertenecen a qué conexión antes de eliminar nada, y guarde la lista en el registro de cambios.

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

Haga coincidir prefijo, siguiente salto, almacén y propietario a la vez en lugar de borrar todo lo que se parezca. Otra conexión puede depender legítimamente de parte de ese espacio, y un borrado masivo convierte una reparación ordenada en un incidente de soporte.

Vuelva a conectar en un orden distinto

Reproduzca la condición en lugar de confiar en que el primer intento fue representativo. Desconecte, vuelva a conectar y confirme la ruta seleccionada hacia el mismo recurso remoto mientras el túnel está activo; con varios VPN en juego, actívelos en un orden distinto y observe si cambia la ruta elegida. El orden es la variable que casi todo el mundo omite, y es la que expone una ruta ligada a la conexión equivocada.

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

El resultado que quiere no es que un adaptador conserve su número una vez. Es que la ruta aparezca con el número que reciba la conexión, siempre, y desaparezca cuando la conexión se cierra. Reconectar dos veces es la forma más barata de distinguir esos resultados.

Sepa qué no puede hacer la ruta

Una ruta de perfil aporta un camino y nada más. No abre un cortafuegos remoto, no crea una ruta de vuelta en el extremo remoto ni resuelve dos sedes que usan el mismo rango de direcciones; cada una de esas cosas es una configuración aparte con un propietario aparte. Confirmar el camino es, por tanto, el comienzo de la prueba de aceptación y no toda la prueba.

Mantenga la lista de prefijos con el perfil y anote bajo qué ámbito se añadió, para que la siguiente persona pueda leer el diseño previsto en lugar de deducirlo de una tabla de rutas. Las rutas que solo existen en la memoria de alguien son las que se reconstruyen mal tras la siguiente reconexión. Un comentario de una línea en las notas de despliegue cuesta menos que una tarde de redescubrimiento.