VPN blokerer lokalt LAN på Windows: rute eller klientpolitik?
Adgang til lokalt LAN på Windows bryder sammen af to forskellige grunde: en manglende rute eller en gatewaypolitik, der dropper undernettet. Tre kontroller afgør hvilken.
En printer, et NAS eller en udviklingsmaskine på dit eget skrivebord holder op med at svare i det øjeblik, arbejds-VPN'et forbinder. Nogle gange retter en rutekommando det på sekunder; andre gange er den samme rute korrekt, og pakkerne forsvinder stadig, hvilket betyder, at du ser på et andet problem med et lignende symptom. Beslutningen kommer ned til tre spørgsmål, og at stille dem i den forkerte rækkefølge er grunden til, at folk bruger en hel aften på at slette og tilføje ruter igen.
Tre spørgsmål før nogen kommando
For det første: findes der en post for det lokale præfiks, og peger den på den fysiske adapter? For det andet: modtager klienten en tilladelse eller afvisning af lokalt netværk fra gatewayen ved forbindelse? For det tredje: har du kun brug for udgående adgang til LAN'et, eller skal noget på internettet også nå en tjeneste, der kører på din maskine?
Det første spørgsmål adskiller en rutefejl fra en filtreringsfejl. Det andet fortæller, om en ruterettelse overhovedet må virke. Det tredje ændrer reparationen: en rute retter udgående trafik, mens en utilgængelig indgående tjeneste normalt er et lytterbinding- og returvejsproblem, som en rute gør værre.
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
Spørgsmål et: rute, filter eller navn
Læs tabellen, før du tilføjer noget til den. Interfaceindekset betyder noget, fordi hver rutekommando nedenfor er forankret i det:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricEt direkte tilsluttet undernet beholder normalt en on-link-rute, selv mens tunnelen er oppe, så en post kan findes, og trafikken kan stadig fejle. Den kombination er signaturen på et filter, der kører efter routing, og det er tilfældet, hvor en anden, mere specifik rute ikke ændrer noget som helst.
Test efter adresse og efter navn hver for sig. Hvis ping 192.168.1.50 svarer, og net view 192.168.1.50 ikke gør, var rutetabellen aldrig problemet: tunnelen ændrede resolveren, og det lokale navn opløses ikke længere. At tilføje en rute til det er spildt arbejde.
Spørgsmål to: tillader gatewayen adgang til lokalt LAN?
En kommerciel klient installerer mere end ruter. Den får en politik ved forbindelse, og den politik kan indeholde en udtrykkelig tilladelse til lokalt netværk. I Cisco IPsec-installationer bærer gruppepolitikken split-tunneling-indstillingen og et separat flag for adgang til lokalt LAN; afkrydsningsfeltet i klienten er en anmodning, som gatewayen kan afvise. I AnyConnect styrer profilen split-listerne for medtagelse og udeladelse og den samme tilladelse. På Windows RRAS er ækvivalenterne indstillingen for standardgateway i profilen plus de statiske ruter, som serveren tildeler.
Når flaget er slukket, er den dokumenterede adfærd, at klienten blokerer trafik til det direkte tilsluttede undernet, selvom der findes en gyldig, mere specifik rute. Det er også derfor, at ruter, som klienten ikke ejer, kan forsvinde sekunder efter, at du tilføjer dem: klienten genopbygger den tilstand, den blev bedt om at bygge, og kæmper ikke mod dig.
Klientloggen registrerer beslutningen ved forbindelse, og at læse den er hurtigere end noget eksperiment på maskinen. Hvis loggen siger, at lokal adgang er blokeret, så stop: ingen kommandolinjerettelse overlever det, og de eneste veje tilbage er en politikændring, at nå ressourcen gennem tunnelen eller at lukke klienten inde i en virtuel maskine og lade værten blive på det lokale netværk.
Spørgsmål tre: hvilken retning har du brug for?
Udgående trafik til en nærliggende enhed er et rutingspørgsmål. Peg LAN-præfikset mod den lokale gateway med en metrik, der er lav nok til at 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 -pDen anden form fastgør en enkelt enhed, hvilket er det, du vil have, når én adresse er hele kravet. Netsh-ækvivalenten registrerer den samme beslutning efter interface-navn i stedet for indeks:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentRutekommandoer fejler med Parameteren er forkert, når adressen og masken ikke stemmer overens, for eksempel en værtsadresse med en /24-maske. Brug netværksadressen til en undernetsrute og en værtsmaske til en enkelt vært.
Indgående er anderledes. En VNC- eller SSH-server på samme maskine bliver utilgængelig, når svar på en indgående forbindelse forlader gennem VPN-gatewayen og aldrig vender tilbage. Kontroller, hvad tjenesten lytter på, før du rører ved ruter:
netstat -ano | findstr :5900En lytter bundet til én bestemt adresse svarer ikke på det andet interface. At binde den til alle interfaces er en bevidst beslutning, truffet sammen med en firewallregel afgrænset til det netværk, du stoler på. Først derefter gendanner ruterettelsen returvejen.
Anvend den mindste ændring, der passer
Det andet almindelige træk er at fjerne markeringen af “Brug standardgateway på fjernnetværk” under de avancerede IPv4-egenskaber. Det holder internettrafikken lokal, men det gør to ting på én gang: VPN'et holder op med at være standardvejen, og klienten holder op med at modtage ruter til fjernnetværket, inklusive multicast. Fjern markeringen, og det fjernede LAN forsvinder, medmindre serveren skubber de specifikke fjernpræfikser, som hver klient har brug for.
Den asymmetri afgør arbejdsrækkefølgen. Hvis fjernsiden skal forblive fuldt tilgængelig, skub fjernundernet fra serveren, og lad den lokale standard være. Hvis du ikke kan ændre serveren, tilføj en vedvarende rute til fjernpræfikset gennem den adresse, tunnelen tildelte, og kontroller med route print, at præfikset peger på VPN-interfacet, mens standarden stadig peger på den fysiske gateway.
Bekræft derefter, at reparationen overlever en genopkobling, fordi ikke-vedvarende ruter dør med adapteren, og et script, der kører efter hver forbindelse, er det ærlige sted for dem. Test én lokal enhed og én fjernressource i samme session, afbryd, genopkobl, og test igen. Hvis den lokale enhed stadig fejler, mens ruten ser rigtig ud, gå tilbage til spørgsmål to: klienten filtrerer, og svaret er en politikændring snarere end en anden konkurrerende rute.