En VPN-rute festet til en grensesnittindeks bryter sammen ved gjentilkobling

Ruten fungerte i uker og begynte så å sende trafikk ingen steder, mens målet var uendret og ingenting var redigert. Det som endret seg, er nummeret: en rute opprettet mot en bestemt grensesnittindeks refererer til en adapter som ikke finnes lenger etter en gjentilkobling, og målprefikset fortsetter å peke på infrastruktur som er byttet ut. Å legge til varighet i den kommandoen hjelper ikke, for problemet var aldri om ruten overlevde en omstart. Løsningen er å knytte intensjonen til tilkoblingen, som ved design overlever adapterbytter.

Sjekk hva ruten faktisk peker på

Begynn med å lese ruteoppføringen og adapterne side om side. En rute med neste hopp på VPN-grensesnittet og en indeks som ikke passer med noen gjeldende adapter, er signaturen på denne feilen; samme prefiks på en annen indeks er enten en rest eller ruten du faktisk vil ha. Les begge listene før du endrer noen av dem, for den interessante sammenligningen er mellom nummeret i ruten og numrene som finnes nå. Hvis rutens indeks vises i adapterlisten, er ikke indeksen problemet ditt, og søket flytter seg til målinger, policy eller den fjerne enden. Hvis den ikke vises, er det ingenting mer å diagnostisere: ruten er knyttet til infrastruktur som ikke finnes lenger.

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

Kolonnen Store skiller en oppføring som består gjennom omstarter fra en som forsvinner med adapteren, og den forskjellen avgjør om feilen kommer tilbake i morgen. En oppføring i det vedvarende lageret som peker på en forsvunnet indeks er det verste tilfellet, fordi den overlever omstarter uten å noen gang passe med noe.

Bind prefikset til profilen, ikke til adapteren

En innebygd Windows-VPN kan bære sin egen rutteliste, slik at tilkoblingen gjenbruker riktig adapter hver gang den kommer opp. Da følger ruten profilen i stedet for et nummer du observerte én gang, og ingen skript må gjette en indeks etter hvert anrop. Å legge til et prefiks er også reversibelt via den tilsvarende fjerningskommandoen, noe som holder endringen reviderbar. Prefikset lagres med tilkoblingen i stedet for i et oppstartsskript, så en profil kopiert til en annen bruker bærer intensjonen med seg.

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

Referansen for Add-VpnConnectionRoute dokumenterer koblingen til tilkoblingen, og telefonbokens omfang betyr noe: en profil per bruker og en profil for alle brukere er forskjellige objekter. Denne mekanismen tilhører Windows' egen VPN-klient, så en leverandøradapter som styres av sin egen tjeneste, kan hente rutene sine fra en helt annen policykilde.

Rydd gamle ruter før du legger til den nye

To ruter med samme prefiks og forskjellige eiere er verre enn én feil rute, fordi vinneren avhenger av målinger som ingen skrev ned. Undersøk hva som allerede finnes for prefikset, inkludert oppføringer i det vedvarende lageret, og fjern bare det som hører til det mislykkede forsøket. En rest fra et tidligere design er vanlig på dette området, siden den feilende ruten vanligvis erstattet noe som fungerte. Noter hvilke oppføringer som hører til hvilken tilkobling før du fjerner noe, og hold listen i endringsloggen.

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

Match prefiks, neste hopp, lager og eier sammen i stedet for å slette alt som ser likt ut. En annen tilkobling kan med rette avhenge av en del av det rommet, og en feiende sletting gjør en ryddig reparasjon om til en støttesak.

Koble til på nytt i en annen rekkefølge

Reproduser betingelsen i stedet for å håpe at det første forsøket var representativt. Koble fra, koble til på nytt, og bekreft den valgte veien til den samme eksterne ressursen mens tunnelen er oppe; med flere VPN-er i spill, ta dem opp i en annen rekkefølge og se om den valgte veien endres. Rekkefølge er variabelen de fleste hopper over, og den er den som avslører en rute knyttet til feil tilkobling.

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

Resultatet du vil ha, er ikke at en adapter beholder nummeret sitt én gang. Det er at ruten dukker opp med hvilket nummer tilkoblingen enn får, hver gang, og forsvinner når tilkoblingen lukkes. Å koble til på nytt to ganger er den billigste måten å skille disse utfallene.

Vit hva ruten ikke kan gjøre

En profilrute gir en vei og ingenting annet. Den åpner ikke en ekstern brannmur, oppretter ikke en returrute i den fjerne enden og løser ikke to nettsteder som bruker samme adresseområde; hver av disse er en egen konfigurasjon med egen eier. Å bekrefte veien er derfor begynnelsen på aksepttesten og ikke hele testen.

Hold prefikslisten sammen med profilen og noter hvilket omfang den ble lagt til under, slik at neste person kan lese det tilsiktede designet i stedet for å utlede det fra en rutetabell. Ruter som bare finnes i noens minne, er de som bygges opp feil etter neste gjentilkobling. En kommentar på én linje i distribusjonsnotatene koster mindre enn en hel ettermiddag med gjenoppdagelse.