Una ruta de VPN fixada a un índex d’interfície es trenca en reconectar

La ruta va funcionar durant setmanes i després va començar a enviar trànsit enlloc, amb la destinació intacta i sense haver editat res. El que va canviar és el número: una ruta creada contra un índex d’interfície concret fa referència a un adaptador que ja no existeix després de reconectar, i el prefix de destinació continua apuntant a una infraestructura que s’ha substituït. Afegir persistència a aquesta ordre no ajuda, perquè el problema mai no era si la ruta sobrevivia a un reinici. La solució és lligar la intenció a la connexió, que sobreviu als canvis d’adaptador per disseny.

Comproveu a què apunta realment la ruta

Comenceu llegint l’entrada de la ruta i els adaptadors l’un al costat de l’altre. Una ruta amb un següent salt a la interfície VPN i un índex que no coincideix amb cap adaptador actual és la signatura d’aquesta fallada; el mateix prefix en un índex diferent és o una resta o la ruta que realment voleu. Llegiu les dues llistes abans de canviar-ne cap, perquè la comparació interessant és entre el número de la ruta i els números que existeixen ara. Si l’índex de la ruta apareix a la llista d’adaptadors, l’índex no és el vostre problema i la cerca passa a mètriques, política o l’extrem remot. Si no hi apareix, no cal diagnosticar res més: la ruta està lligada a una infraestructura que ja no existeix.

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 distingeix una entrada que persisteix entre reinicis d’una que desapareix amb l’adaptador, i aquesta diferència determina si la fallada tornarà demà. Una entrada al magatzem persistent que apunta a un índex desaparegut és el pitjor cas, perquè sobreviu als reinicis sense coincidir mai amb res.

Lligueu el prefix al perfil, no a l’adaptador

Un VPN natiu de Windows pot portar la seva pròpia llista de rutes, de manera que la connexió reutilitza l’adaptador correcte sempre que apareix. Llavors la ruta segueix el perfil en lloc d’un número que vau observar una vegada, i cap script ha d’endevinar un índex després de cada trucada. Afegir un prefix també és reversible amb l’ordre d’eliminació corresponent, cosa que manté el canvi auditable. El prefix es desa amb la connexió en lloc de fer-ho en un script d’inici, així que un perfil copiat a un altre usuari porta la intenció amb ell.

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

La referència d’Add-VpnConnectionRoute documenta l’associació amb la connexió, i l’abast de la llibreta d’adreces importa: un perfil per usuari i un perfil per a tots els usuaris són objectes diferents. Aquest mecanisme pertany al client VPN propi de Windows, així que un adaptador de fabricant gestionat pel seu propi servei pot prendre les rutes d’una font de política completament diferent.

Netegeu les rutes antigues abans d’afegir-ne una de nova

Dues rutes amb el mateix prefix i propietaris diferents són pitjor que una ruta equivocada, perquè el guanyador depèn de mètriques que ningú no va anotar. Inspeccioneu què existeix ja per al prefix, incloent-hi les entrades del magatzem persistent, i elimineu només el que pertany a l’intent fallit. Una resta d’un disseny anterior és habitual en aquesta àrea, ja que la ruta que falla normalment va substituir alguna cosa que funcionava. Anoteu quines entrades pertanyen a quina connexió abans d’eliminar res, i guardeu la llista al registre de canvis.

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

Feu coincidir prefix, següent salt, magatzem i propietari alhora en lloc d’esborrar tot el que sembla igual. Una altra connexió pot dependre legítimament d’una part d’aquest espai, i un esborrat massiu converteix una reparació ordenada en un incident de suport.

Reconecteu en un ordre diferent

Reproduïu la condició en lloc d’esperar que el primer intent fos representatiu. Desconnecteu, reconnecteu i confirmeu el camí seleccionat cap al mateix recurs remot mentre el túnel és actiu; amb diversos VPN en joc, activeu-los en un ordre diferent i observeu si el camí triat canvia. L’ordre és la variable que la majoria de la gent omet, i és la que exposa una ruta lligada a la connexió equivocada.

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

El resultat que voleu no és que un adaptador conservi el seu número una vegada. És que la ruta aparegui amb el número que rebi la connexió, cada vegada, i desaparegui quan la connexió es tanca. Reconectar dues vegades és la manera més barata de distingir aquests resultats.

Sapigueu què no pot fer la ruta

Una ruta de perfil proporciona un camí i res més. No obre un tallafoc remot, no crea una ruta de tornada a l’extrem remot ni resol dos llocs que fan servir el mateix rang d’adreces; cadascun d’aquests és una configuració separada amb un propietari separat. Confirmar el camí és, per tant, l’inici de la prova d’acceptació i no tota la prova.

Mantingueu la llista de prefixos amb el perfil i anoteu sota quin abast es va afegir, perquè la persona següent pugui llegir el disseny previst en lloc d’inferir-lo d’una taula de rutes. Les rutes que només existeixen a la memòria d’algú són les que es reconstrueixen malament després de la propera reconnexió. Un comentari d’una línia a les notes de desplegament costa menys que una tarda de redescobriment.