VPN-rute fastgjort til et interfaceindeks bryder sammen ved genopkobling

Ruten virkede i uger og begyndte derefter at sende trafik ingen steder hen, mens destinationen var uændret og intet var redigeret. Det, der ændrede sig, er nummeret: en rute oprettet mod et bestemt interfaceindeks henviser til en adapter, der ikke findes længere efter en genopkobling, og destinationspræfikset bliver ved med at pege på infrastruktur, der er blevet udskiftet. At tilføje persistens til den kommando hjælper ikke, for problemet var aldrig, om ruten overlevede en genstart. Løsningen er at knytte hensigten til forbindelsen, som efter design overlever adapterudskiftninger.

Tjek, hvad ruten faktisk peger på

Begynd med at læse ruteindgangen og adapterne side om side. En rute med næste hop på VPN-interfacet og et indeks, der ikke matcher nogen aktuel adapter, er signaturen på denne fejl; det samme præfiks på et andet indeks er enten en rest eller den rute, du faktisk vil have. Læs begge lister, før du ændrer nogen af dem, for den interessante sammenligning er mellem nummeret i ruten og de numre, der findes nu. Hvis rutens indeks optræder på adapterlisten, er indekset ikke dit problem, og søgningen flytter til metrikker, politik eller den fjerne ende. Hvis det ikke optræder, skal der ikke diagnosticeres mere: ruten er knyttet til infrastruktur, der ikke findes længere.

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 skelner en indgang, der består gennem genstarter, fra en der forsvinder med adapteren, og den forskel afgør, om fejlen vender tilbage i morgen. En indgang i det persistente lager, der peger på et forsvundet indeks, er det værste tilfælde, fordi den overlever genstarter uden nogensinde at matche noget.

Bind præfikset til profilen, ikke til adapteren

En indbygget Windows VPN kan have sin egen ruteliste, så forbindelsen genbruger den rigtige adapter, hver gang den kommer op. Ruten følger derefter profilen i stedet for et nummer, du så én gang, og ingen script skal gætte et indeks efter hvert opkald. Det er også muligt at fortryde tilføjelsen af et præfiks via den tilsvarende fjernelseskommando, hvilket holder ændringen reviderbar. Præfikset gemmes sammen med forbindelsen i stedet for i et opstartsscript, så en profil kopieret til en anden bruger bærer hensigten med sig.

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

Referencen for Add-VpnConnectionRoute dokumenterer tilknytningen til forbindelsen, og telefonbogens omfang betyder noget: en profil pr. bruger og en profil for alle brugere er forskellige objekter. Denne mekanisme hører til Windows' egen VPN-klient, så en leverandøradapter, der styres af sin egen tjeneste, kan hente sine ruter fra en helt anden politikilde.

Ryd gamle ruter, før du tilføjer den nye

To ruter med samme præfiks og forskellige ejere er værre end én forkert rute, fordi vinderen afhænger af metrikker, som ingen skrev ned. Undersøg, hvad der allerede findes for præfikset, inklusive indgange i det persistente lager, og fjern kun det, der hører til det mislykkede forsøg. En rest fra et tidligere design er almindelig på dette område, da den fejlende rute normalt erstattede noget, der virkede. Notér, hvilke indgange der hører til hvilken forbindelse, før du fjerner noget, og gem listen i ændringsregistret.

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 præfiks, næste hop, lager og ejer sammen i stedet for at slette alt, der ligner. En anden forbindelse kan med rette afhænge af en del af det rum, og en fejende sletning gør en pæn reparation til en supportssag.

Genopkobl i en anden rækkefølge

Reproduzér betingelsen i stedet for at håbe på, at det første forsøg var repræsentativt. Afbryd, genopkobl, og bekræft den valgte vej til den samme fjernressource, mens tunnelen er oppe; når der er flere VPN'er i spil, så bring dem op i en anden rækkefølge, og se, om den valgte vej ændrer sig. Rækkefølge er den variabel, de fleste springer over, og den er den, der afslører en rute knyttet til den forkerte forbindelse.

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

Det resultat, du vil have, er ikke, at en adapter beholder sit nummer én gang. Det er, at ruten dukker op med det nummer, forbindelsen nu får, hver gang, og forsvinder, når forbindelsen lukkes. At genopkoble to gange er den billigste måde at skelne de udfald.

Vid, hvad ruten ikke kan

En profilrute giver en vej og intet andet. Den åbner ikke en fjern firewall, opretter ikke en returrute i den fjerne ende og løser ikke to lokaliteter, der bruger det samme adresseområde; hver af disse er en separat konfiguration med en separat ejer. At bekræfte vejen er derfor begyndelsen på accepttesten og ikke hele testen.

Hold præfikslisten sammen med profilen, og notér, under hvilket omfang den blev tilføjet, så den næste person kan læse det tilsigtede design i stedet for at udlede det af en rutetabel. Ruter, der kun findes i nogens hukommelse, er dem, der bliver genopbygget forkert efter den næste genopkobling. En kommentar på én linje i udrulningsnoterne koster mindre end en hel eftermiddag med genopdagelse.