Unha ruta de VPN ancorada a un índice de interface rompe ao reconectar

A ruta funcionou durante semanas e logo comezou a enviar tráfico a ningures, co destino intacto e sen ter editado nada. O que cambiou é o número: unha ruta creada contra un índice de interface concreto fai referencia a un adaptador que xa non existe tras reconectar, e o prefixo de destino segue apuntando a unha infraestrutura que se substituíu. Engadir persistencia a ese comando non axuda, porque o problema nunca foi se a ruta sobrevivía a un reinicio. A solución é atar a intención á conexión, que sobrevive aos cambios de adaptador por deseño.

Comprobe a que apunta realmente a ruta

Comece lendo a entrada da ruta e os adaptadores un ao lado do outro. Unha ruta cun seguinte salto na interface VPN e un índice que non coincide con ningún adaptador actual é a sinatura deste fallo; o mesmo prefixo noutro índice é ou un resto ou a ruta que realmente quere. Lea as dúas listas antes de cambiar calquera delas, porque a comparación interesante está entre o número da ruta e os números que existen agora. Se o índice da ruta aparece na lista de adaptadores, o índice non é o seu problema e a busca pasa a métricas, política ou o extremo remoto. Se non aparece, non hai que diagnosticar nada máis: a ruta está ligada a unha infraestrutura que xa non 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

A columna Store distingue unha entrada que persiste entre reinicios dunha que desaparece co adaptador, e esa diferenza determina se o fallo reaparecerá mañá. Unha entrada no almacén persistente que apunta a un índice desaparecido é o peor caso, porque sobrevive aos reinicios sen coincidir nunca con nada.

Ate o prefixo ao perfil, non ao adaptador

Un VPN nativo de Windows pode levar a súa propia lista de rutas, de modo que a conexión reutiliza o adaptador correcto sempre que aparece. Entón a ruta segue o perfil en lugar dun número que observou unha vez, e ningún script ten que adiviñar un índice tras cada marcación. Engadir un prefixo tamén é reversible co comando de eliminación correspondente, o que mantén o cambio auditable. O prefixo gárdase coa conexión en lugar de nun script de inicio, así que un perfil copiado a outro usuario leva a intención consigo.

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

A referencia de Add-VpnConnectionRoute documenta a asociación coa conexión, e o ámbito da libreta de enderezos importa: un perfil por usuario e un perfil para todos os usuarios son obxectos distintos. Este mecanismo pertence ao cliente VPN propio de Windows, así que un adaptador de fabricante xestionado polo seu propio servizo pode tomar as súas rutas dunha fonte de política completamente distinta.

Limpe as rutas antigas antes de engadir a nova

Dúas rutas co mesmo prefixo e propietarios distintos son peor que unha ruta equivocada, porque o gañador depende de métricas que ninguén anotou. Inspeccione o que xa existe para o prefixo, incluídas as entradas do almacén persistente, e elimine só o que pertence ao intento fallido. Un resto dun deseño anterior é habitual nesta área, xa que a ruta que falla adoita substituír algo que funcionaba. Anote que entradas pertencen a que conexión antes de eliminar nada, e garde a lista no rexistro 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

Faga coincidir prefixo, seguinte salto, almacén e propietario á vez en lugar de borrar todo o que se pareza. Outra conexión pode depender lexitimamente de parte dese espazo, e un borrado masivo converte unha reparación ordenada nun incidente de soporte.

Volva conectar nunha orde distinta

Reproduza a condición en lugar de confiar en que o primeiro intento foi representativo. Desconecte, volva conectar e confirme a ruta seleccionada cara ao mesmo recurso remoto mentres o túnel está activo; con varios VPN en xogo, actíveos nunha orde distinta e observe se cambia a ruta elixida. A orde é a variable que case todo o mundo omite, e é a que expón unha ruta ligada á conexión equivocada.

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

O resultado que quere non é que un adaptador conserve o seu número unha vez. É que a ruta apareza co número que reciba a conexión, sempre, e desapareza cando a conexión se pecha. Reconectar dúas veces é a forma máis barata de distinguir eses resultados.

Saiba que non pode facer a ruta

Unha ruta de perfil achega un camiño e nada máis. Non abre un devasado remoto, non crea unha ruta de volta no extremo remoto nin resolve dúas sedes que usan o mesmo rango de enderezos; cada unha desas cousas é unha configuración aparte cun propietario aparte. Confirmar o camiño é, polo tanto, o comezo da proba de aceptación e non toda a proba.

Manteña a lista de prefixos co perfil e anote baixo que ámbito se engadiu, para que a seguinte persoa poida ler o deseño previsto en lugar de deducilo dunha táboa de rutas. As rutas que só existen na memoria de alguén son as que se reconstruen mal tras a seguinte reconexión. Un comentario dunha liña nas notas de despregamento custa menos que unha tarde de redescubrimento.