VPN blokkerer lokalt LAN på Windows: rute eller klientpolitikk?

Ein skrivar, eit NAS eller ein utviklingsmaskin på din eigen pult sluttar å svare i det augeblikket jobb-VPN-en koplar til. Nokre gonger rettar éin rutekommando det på sekundar; nokre gonger er same ruta riktig og pakkane forsvinn likevel, som tyder på at du ser på eit anna problem med eit liknande symptom. Avgjerda kokar ned til tre spørsmål, og å stille dei i feil rekkefølgje er grunnen til at folk brukar ein heil kveld på å slette og leggje til ruter på nytt.

Tre spørsmål før nokon kommando

For det første: finst det ein oppføring for det lokale prefikset, og peikar han på den fysiske adapteren? For det andre: får klienten ei løyve eller avvising for lokalnettet frå gatewayen ved tilkopling? For det tredje: treng du berre utgåande tilgang til LAN-et, eller må noko på internett også nå ein teneste som køyrer på maskinen din?

Det første spørsmålet skil ein rutefeil frå ein filtreringsfeil. Det andre seier om ein rutefiks i det heile får verke. Det tredje endrar reparasjonen: ei rute rettar utgåande trafikk, medan ei utilgjengeleg inngåande teneste vanlegvis er eit problem med lyttarbinding og returveg som ei rute gjer verre.

Spørsmål éin: rute, filter eller namn

Les tabellen før du legg noko til han. Grensesnittindeksen betyr noko, fordi kvar rutekommando nedanfor er forankra i han:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Eit direkte tilkopla subnett held vanlegvis ei on-link-rute sjølv medan tunnelen er oppe, så ein oppføring kan finnast og trafikken kan likevel feile. Den kombinasjonen er signaturen til eit filter som køyrer etter ruting, og det er tilfellet der ei anna, meir spesifikk rute ikkje endrar noko som helst.

Test etter adresse og etter namn kvar for seg. Viss ping 192.168.1.50 svarar og net view 192.168.1.50 ikkje, var rutetabellen aldri problemet: tunnelen endra resolvaren og det lokale namnet blir ikkje lenger løyst. Å leggje til ei rute for det er bortkasta arbeid.

Spørsmål to: tillèt gatewayen tilgang til lokalt LAN?

Ein kommersiell klient installerer meir enn ruter. Han får ein politikk ved tilkopling, og den politikken kan innehalde eit uttrykkeleg løyve for lokalnettet. I Cisco IPsec-utrullar ber gruppepolitikken split-tunneling-innstillinga og eit eige flagg for tilgang til lokalt LAN; avkryssingsboksen i klienten er ei førespurnad som gatewayen kan avvise. I AnyConnect styrer profilen split-listene for inkludering og utelating og det same løyvet. På Windows RRAS er ekvivalentane alternativet for standardgateway i profilen pluss dei statiske rutene serveren tildeler.

Når flagget er av, er den dokumenterte åtferda at klienten blokkerer trafikk til det direkte tilkopla subnettet sjølv om det finst ei gyldig, meir spesifikk rute. Det er også derfor ruter klienten ikkje eig kan forsvinne sekund etter at du legg dei til: klienten byggjer opp att tilstanden han vart beden om å byggje, og kjempar ikkje mot deg.

Klientloggen registrerer avgjerda ved tilkopling, og å lese han er raskare enn noko eksperiment på maskinen. Viss loggen seier at lokal tilgang er blokkert, stopp: ingen kommandolinjeretting overlever det, og dei einaste vegane som står att er ei politikkendring, å nå ressursen gjennom tunnelen, eller å lukke klienten inne i ein virtuell maskin og la verten bli på lokalnettet.

Spørsmål tre: kva retning treng du?

Utgåande trafikk til ein nærliggande eining er eit rutingspørsmål. Peik LAN-prefikset mot den lokale gatewayen med ein metrikk som er låg nok til å slå standardruta til tunnelen:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

Den andre forma festar ei enkel eining, som er det du vil ha når éin adresse er heile kravet. netsh-ekvivalenten registrerer same avgjerd etter grensesnittnamn i staden for indeks:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Rutekommandoar feilar med Parameteren er feil når adressa og maska ikkje stemmer, til dømes ei vertsadresse med /24-maske. Bruk nettverksadressa for ei subnett-rute og ei vertsmaske for éin enkel vert.

Inngåande er annleis. Ein VNC- eller SSH-server på same maskin blir utilgjengeleg når svar på ei inngåande tilkopling går ut gjennom VPN-gatewayen og aldri kjem tilbake. Sjekk kva tenesta lyttar på før du rører rutene:

netstat -ano | findstr :5900

Ein lyttar bunden til éi bestemt adresse vil ikkje svare på det andre grensesnittet. Å binde han til alle grensesnitt er ei medviten avgjerd, teken saman med ein brannmurregel avgrensa til nettverket du stolar på. Først etter det gjenopprettar rutefiksen returvegen.

Bruk den minste endringa som passar

Det andre vanlege trekket er å fjerne avkryssinga for «Bruk standardgateway på fjernnettverket» i dei avanserte IPv4-eigenskapane. Det held internettrafikken lokal, men gjer to ting samstundes: VPN-en sluttar å vere standardvegen, og klienten sluttar å motta ruter for fjernnettverket, inkludert multicast. Fjern avkryssinga, og det fjernare LAN-et forsvinn med mindre serveren skyv dei spesifikke fjernprefiksa kvar klient treng.

Den asymmetrien avgjer arbeidsrekkjefølgja. Viss fjernsida må halde fram med å vere fullt tilgjengeleg, skyv fjernsubnett frå serveren og la den lokale standarden vere. Viss du ikkje kan endre serveren, legg til ei varig rute til fjernprefikset gjennom adressa tunnelen tildelte, og kontroller med route print at prefikset peikar på VPN-grensesnittet medan standarden framleis peikar på den fysiske gatewayen.

Stadfest deretter at reparasjonen overlever ein ny tilkopling, fordi ikkje-varige ruter døyr med adapteren, og eit skript som køyrer etter kvar tilkopling er den ærlege staden for dei. Test éi lokal eining og éin fjernressurs i same økt, kople frå, kople til att og test på nytt. Viss den lokale eininga framleis feilar medan ruta ser riktig ut, gå tilbake til spørsmål to: klienten filtrerer, og svaret er ei politikkendring snarare enn ei andre konkurrerande rute.