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

En skriver, et NAS eller en utviklingsmaskin på din egen pult slutter å svare i det øyeblikket jobb-VPN-en kobler til. Noen ganger retter én rutekommando det på sekunder; noen ganger er samme rute riktig og pakkene forsvinner likevel, som betyr at du ser på et annet problem med et lignende symptom. Beslutningen koker ned til tre spørsmål, og å stille dem i feil rekkefølge er grunnen til at folk bruker en hel kveld på å slette og legge til ruter på nytt.

Tre spørsmål før noen kommando

For det første: finnes det en oppføring for det lokale prefikset, og peker den på den fysiske adapteren? For det andre: får klienten en tillatelse eller avvisning for lokalnettet fra gatewayen ved tilkobling? For det tredje: trenger du bare utgående tilgang til LAN-et, eller må noe på internett også nå en tjeneste som kjører på maskinen din?

Det første spørsmålet skiller en rutefeil fra en filtreringsfeil. Det andre sier om en ruteretting i det hele tatt får virke. Det tredje endrer reparasjonen: en rute retter utgående trafikk, mens en utilgjengelig inngående tjeneste vanligvis er et problem med lytterbinding og returvei som en rute gjør verre.

Spørsmål én: rute, filter eller navn

Les tabellen før du legger noe til den. Grensesnittindeksen betyr noe, fordi hver rutekommando nedenfor er forankret i den:

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

Et direkte tilkoblet subnett beholder vanligvis en on-link-rute selv mens tunnelen er oppe, så en oppføring kan finnes og trafikken kan likevel feile. Den kombinasjonen er signaturen til et filter som kjører etter ruting, og det er tilfellet der en annen, mer spesifikk rute ikke endrer noe som helst.

Test etter adresse og etter navn hver for seg. Hvis ping 192.168.1.50 svarer og net view 192.168.1.50 ikke, var rutetabellen aldri problemet: tunnelen endret resolveren og det lokale navnet løses ikke lenger. Å legge til en rute for det er bortkastet arbeid.

Spørsmål to: tillater gatewayen tilgang til lokalt LAN?

En kommersiell klient installerer mer enn ruter. Den får en policy ved tilkobling, og den policyen kan inneholde en uttrykkelig tillatelse for lokalnettet. I Cisco IPsec-utrullinger bærer gruppepolicyen split-tunneling-innstillingen og et eget flagg for tilgang til lokalt LAN; avkrysningsboksen i klienten er en forespørsel som gatewayen kan avvise. I AnyConnect styrer profilen split-listene for inkludering og utelatelse og den samme tillatelsen. På Windows RRAS er ekvivalentene alternativet for standardgateway i profilen pluss de statiske rutene serveren tildeler.

Når flagget er av, er den dokumenterte atferden at klienten blokkerer trafikk til det direkte tilkoblede subnettet selv om det finnes en gyldig, mer spesifikk rute. Det er også derfor ruter klienten ikke eier kan forsvinne sekunder etter at du legger dem til: klienten bygger opp igjen tilstanden den ble bedt om å bygge, og kjemper ikke mot deg.

Klientloggen registrerer beslutningen ved tilkobling, og å lese den er raskere enn noe eksperiment på maskinen. Hvis loggen sier at lokal tilgang er blokkert, stopp: ingen kommandolinjeretting overlever det, og de eneste veiene som gjenstår er en policyendring, å nå ressursen gjennom tunnelen, eller å lukke klienten inne i en virtuell maskin og la verten bli på lokalnettet.

Spørsmål tre: hvilken retning trenger du?

Utgående trafikk til en nærliggende enhet er et rutingspørsmål. Pek LAN-prefikset mot den lokale gatewayen med en metrikk som er lav nok til å slå tunnelens standardrute:

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 formen fester en enkelt enhet, som er det du vil ha når én adresse er hele kravet. netsh-ekvivalenten registrerer samme beslutning etter grensesnittnavn i stedet for indeks:

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

Rutekommandoer feiler med Parameteren er feil når adressen og masken ikke stemmer, for eksempel en vertsadresse med /24-maske. Bruk nettverksadressen for en subnett-rute og en vertsmaske for én enkelt vert.

Inngående er annerledes. En VNC- eller SSH-server på samme maskin blir utilgjengelig når svar på en inngående tilkobling går ut gjennom VPN-gatewayen og aldri kommer tilbake. Sjekk hva tjenesten lytter på før du rører rutene:

netstat -ano | findstr :5900

En lytter bundet til én bestemt adresse vil ikke svare på det andre grensesnittet. Å binde den til alle grensesnitt er en bevisst beslutning, tatt sammen med en brannmurregel begrenset til nettverket du stoler på. Først etter det gjenoppretter ruterettingen returveien.

Bruk den minste endringen som passer

Det andre vanlige trekket er å fjerne avkrysningen for «Bruk standardgateway på fjernnettverket» i de avanserte IPv4-egenskapene. Det holder internettrafikken lokal, men gjør to ting samtidig: VPN-en slutter å være standardveien, og klienten slutter å motta ruter for fjernnettverket, inkludert multicast. Fjern avkrysningen, og det fjernede LAN-et forsvinner med mindre serveren skyver de spesifikke fjernprefiksene hver klient trenger.

Den asymmetrien avgjør arbeidsrekkefølgen. Hvis fjernsiden må forbli fullt tilgjengelig, skyv fjernsubnett fra serveren og la den lokale standarden være. Hvis du ikke kan endre serveren, legg til en vedvarende rute til fjernprefikset gjennom adressen tunnelen tildelte, og kontroller med route print at prefikset peker på VPN-grensesnittet mens standarden fortsatt peker på den fysiske gatewayen.

Bekreft deretter at reparasjonen overlever en gjentilkobling, fordi ikke-vedvarende ruter dør med adapteren, og et skript som kjøres etter hver tilkobling er det ærlige stedet for dem. Test én lokal enhet og én fjernressurs i samme økt, koble fra, koble til igjen og test på nytt. Hvis den lokale enheten fortsatt feiler mens ruten ser riktig ut, gå tilbake til spørsmål to: klienten filtrerer, og svaret er en policyendring snarere enn en andre konkurrerende rute.