VPN blockerar lokalt LAN i Windows: rutt eller klientpolicy?

En skrivare, ett NAS eller en utvecklingsmaskin på ditt eget skrivbord slutar svara i samma ögonblick som jobb-VPN:et ansluter. Ibland löser ett ruttkommando det på sekunder; ibland är samma rutt korrekt och paketen försvinner ändå, vilket betyder att du tittar på ett annat problem med ett liknande symptom. Beslutet kokar ner till tre frågor, och att ställa dem i fel ordning är anledningen till att folk lägger en hel kväll på att ta bort och lägga till rutter igen.

Tre frågor före varje kommando

För det första: finns det en post för det lokala prefixet, och pekar den på den fysiska adaptern? För det andra: får klienten ett tillstånd eller ett avslag för det lokala nätverket från gatewayen vid anslutning? För det tredje: behöver du bara utgående åtkomst till LAN:et, eller måste något på internet också nå en tjänst som körs på din maskin?

Den första frågan skiljer ett routingfel från ett filtreringsfel. Den andra säger om en ruttkorrigering får verka alls. Den tredje ändrar reparationen: en rutt rättar utgående trafik, medan en oåtkomlig inkommande tjänst oftast är ett problem med lyssnarbindning och returväg som en rutt förvärrar.

Fråga ett: rutt, filter eller namn

Läs tabellen innan du lägger till något i den. Gränssnittsindexet spelar roll, eftersom varje ruttkommando nedan är förankrat i det:

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

Ett direkt anslutet undernät behåller normalt en on-link-rutt även när tunneln är uppe, så en post kan finnas och trafiken kan ändå misslyckas. Den kombinationen är signaturen för ett filter som körs efter routingen, och det är fallet där en andra, mer specifik rutt inte ändrar någonting alls.

Testa separat efter adress och efter namn. Om ping 192.168.1.50 svarar och net view 192.168.1.50 inte, var routingtabellen aldrig problemet: tunneln ändrade resolvern och det lokala namnet löses inte längre. Att lägga till en rutt för det är bortkastat arbete.

Fråga två: tillåter gatewayen åtkomst till lokalt LAN?

En kommersiell klient installerar mer än rutter. Den får en policy vid anslutning, och den policyn kan innehålla ett uttryckligt tillstånd för det lokala nätverket. I Cisco IPsec-distributioner bär grupppolicyn inställningen för split-tunneling och en separat flagga för åtkomst till lokalt LAN; kryssrutan i klienten är en begäran som gatewayen kan avvisa. I AnyConnect styr profilen split-listorna för inkludering och uteslutning och samma tillstånd. På Windows RRAS är motsvarigheterna alternativet för standardgateway i profilen plus de statiska rutter som servern tilldelar.

När flaggan är av är det dokumenterade beteendet att klienten blockerar trafik till det direkt anslutna undernätet trots att en giltig, mer specifik rutt finns. Det är också därför rutter som klienten inte äger kan försvinna sekunder efter att du lagt till dem: klienten bygger upp det tillstånd den blev tillsagd att bygga, och slåss inte mot dig.

Klientloggen registrerar beslutet vid anslutning, och att läsa den är snabbare än något experiment på maskinen. Om loggen säger att lokal åtkomst är blockerad, stanna: ingen kommandoradsrättelse överlever det, och de enda vägarna som återstår är en policyändring, att nå resursen genom tunneln, eller att stänga in klienten i en virtuell maskin och låta värden stanna på det lokala nätverket.

Fråga tre: vilken riktning behöver du?

Utgående trafik till en närliggande enhet är en routingfråga. Peka LAN-prefixet mot den lokala gatewayen med ett mått som är lågt nog att slå tunnelns standardrutt:

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 andra formen fäster en enda enhet, vilket är vad du vill när en adress är hela kravet. netsh-motsvarigheten registrerar samma beslut efter gränssnittsnamn i stället för index:

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

Ruttkommandon misslyckas med Parametern är felaktig när adressen och masken inte stämmer, till exempel en värdadress med /24-mask. Använd nätverksadressen för en undernätsrutt och en värdmask för en enda värd.

Inkommande är annorlunda. En VNC- eller SSH-server på samma maskin blir oåtkomlig när svar på en inkommande anslutning går ut genom VPN-gatewayen och aldrig kommer tillbaka. Kontrollera vad tjänsten lyssnar på innan du rör rutter:

netstat -ano | findstr :5900

En lyssnare bunden till en specifik adress svarar inte på det andra gränssnittet. Att binda den till alla gränssnitt är ett medvetet beslut, fattat tillsammans med en brandväggsregel begränsad till nätverket du litar på. Först efter det återställer ruttkorrigeringen returvägen.

Tillämpa den minsta ändring som passar

Det andra vanliga draget är att ta bort krysset för ”Använd standardgateway på fjärrnätverket” i de avancerade IPv4-egenskaperna. Det håller internettrafiken lokal, men gör två saker samtidigt: VPN:et slutar vara standardvägen, och klienten slutar ta emot rutter för fjärrnätverket, inklusive multicast. Ta bort krysset och fjärr-LAN:et försvinner om inte servern skjuter ut de specifika fjärrprefix som varje klient behöver.

Den asymmetrin avgör arbetsordningen. Om fjärrsidan måste förbli fullt nåbar, skjut ut fjärrundernät från servern och låt den lokala standarden vara. Om du inte kan ändra servern, lägg till en beständig rutt till fjärrprefixet via den adress tunneln tilldelade, och kontrollera med route print att prefixet pekar på VPN-gränssnittet medan standarden fortfarande pekar på den fysiska gatewayen.

Bekräfta sedan att reparationen överlever en återanslutning, eftersom icke-beständiga rutter dör med adaptern, och ett skript som körs efter varje anslutning är den ärliga platsen för dem. Testa en lokal enhet och en fjärrresurs i samma session, koppla från, anslut igen och testa på nytt. Om den lokala enheten fortfarande misslyckas medan rutten ser korrekt ut, gå tillbaka till fråga två: klienten filtrerar, och svaret är en policyändring snarare än en andra konkurrerande rutt.