Ei VPN-rute festa til ein grensesnittindeks bryt saman ved gjentilkopling

Ruta fungerte i veker og byrja så å senda trafikk ingen stad, medan målet var uendra og ingenting var redigert. Det som endra seg, er nummeret: ei rute oppretta mot ein bestemd grensesnittindeks viser til ein adapter som ikkje finst lenger etter ei gjentilkopling, og målprefikset held fram med å peika på infrastruktur som er bytt ut. Å leggja til varigheit i den kommandoen hjelper ikkje, for problemet var aldri om ruta overlevde ein omstart. Løysinga er å knyta intensjonen til tilkoplinga, som ved design overlever adapterbytte.

Sjekk kva ruta faktisk peikar på

Byrja med å lesa ruteoppføringa og adaprane side om side. Ei rute med neste hopp på VPN-grensesnittet og ein indeks som ikkje passar med nokon gjeldande adapter, er signaturen på denne feilen; same prefiks på ein annan indeks er anten ein rest eller ruta du faktisk vil ha. Les begge listene før du endrar noka av dei, for den interessante samanlikninga er mellom nummeret i ruta og nummeret som finst no. Viss indeksen til ruta viser seg i adapterlista, er ikkje indeksen problemet ditt, og søket flyttar seg til målingar, policy eller den fjerne enden. Viss han ikkje viser seg, er det ingenting meir å diagnostisera: ruta er knytt til infrastruktur som ikkje finst 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 skil ei oppføring som held seg gjennom omstartar frå ei som forsvinn med adapteren, og den skilnaden avgjer om feilen kjem tilbake i morgon. Ei oppføring i det varige lageret som peikar på ein forsvunnen indeks er det verste tilfellet, fordi ho overlever omstartar utan å nokon gong passa med noko.

Bind prefikset til profilen, ikkje til adapteren

Ein innebygd Windows-VPN kan bera si eiga ruteliste, slik at tilkoplinga brukar den rette adapteren på nytt kvar gong han kjem opp. Då følgjer ruta profilen i staden for eit nummer du observerte éin gong, og ingen skript må gjeta ein indeks etter kvart anrop. Å leggja til eit prefiks er også reversibelt via den tilsvarande fjerningkommandoen, noko som held endringa reviderbar. Prefikset blir lagra med tilkoplinga i staden for i eit oppstartsskript, så ein profil kopiert til ein annan brukar ber intensjonen med seg.

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

Referansen for Add-VpnConnectionRoute dokumenterer koplinga til tilkoplinga, og omfanget til telefonboka har noko å seia: ein profil per brukar og ein profil for alle brukarar er ulike objekt. Denne mekanismen høyrer til Windows sin eigen VPN-klient, så ein leverandøradapter som blir styrt av sin eigen teneste, kan henta rutene sine frå ei heilt anna policykjelde.

Rydd gamle ruter før du legg til den nye

To ruter med same prefiks og ulike eigarar er verre enn éi feil rute, fordi vinnaren avheng av målingar som ingen skreiv ned. Undersøk kva som allereie finst for prefikset, inkludert oppføringar i det varige lageret, og fjern berre det som høyrer til det mislukka forsøket. Ein rest frå eit tidlegare design er vanleg på dette området, sidan den feilande ruta vanlegvis erstatta noko som fungerte. Noter kva oppføringar som høyrer til kva tilkopling før du fjernar noko, og hald lista 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 eigar saman i staden for å sletta alt som ser likt ut. Ei anna tilkopling kan med rette vera avhengig av ein del av det rommet, og ei feiande sletting gjer ein ryddig reparasjon om til ei støttesak.

Kople til på nytt i ein annan rekkjefølgje

Reproduser vilkåret i staden for å håpa at det første forsøket var representativt. Kople frå, kople til på nytt, og stadfest den valde vegen til den same eksterne ressursen medan tunnelen er oppe; med fleire VPN-ar i spel, ta dei opp i ein annan rekkjefølgje og sjå om den valde vegen endrar seg. Rekkjefølgje er variabelen dei fleste hoppar over, og han er den som avdekkjer ei rute knytt til feil tilkopling.

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

Resultatet du vil ha, er ikkje at ein adapter held på nummeret sitt éin gong. Det er at ruta dukkar opp med kva nummer tilkoplinga enn får, kvar gong, og forsvinn når tilkoplinga blir stengd. Å kople til på nytt to gonger er den billegaste måten å skilja desse utfalla.

Vit kva ruta ikkje kan gjera

Ei profilrute gir ein veg og ingenting anna. Ho opnar ikkje ein ekstern brannmur, opprettar ikkje ei returrute i den fjerne enden og løyser ikkje to nettstader som brukar same adresseområde; kvar av desse er ein eigen konfigurasjon med eigen eigar. Å stadfesta vegen er derfor byrjinga på aksepttesten og ikkje heile testen.

Hald prefikslista saman med profilen og noter kva omfang ho vart lagd til under, slik at neste person kan lesa det tilsikta designet i staden for å utleia det frå ein rutetabell. Ruter som berre finst i nokon sitt minne, er dei som blir bygde opp feil etter neste gjentilkopling. Ein kommentar på éi line i distribusjonsnotata kostar mindre enn ein heil ettermiddag med gjenoppdaging.