VPN blokkeert lokaal LAN op Windows: route of clientbeleid?

Een printer, een NAS of een ontwikkelmachine op uw eigen bureau stopt met antwoorden op het moment dat de werk-VPN verbindt. Soms lost één routecommando het in seconden op; soms is dezelfde route correct en verdwijnen de pakketten alsnog, wat betekent dat u naar een ander probleem met een vergelijkbaar symptoom kijkt. De beslissing komt neer op drie vragen, en ze in de verkeerde volgorde stellen is de reden dat mensen een hele avond bezig zijn met het verwijderen en opnieuw toevoegen van routes.

Drie vragen vóór elk commando

Ten eerste: is er een vermelding voor het lokale prefix, en wijst die naar de fysieke adapter? Ten tweede: krijgt de client bij het verbinden een toestemming of weigering voor het lokale netwerk van de gateway? Ten derde: hebt u alleen uitgaande toegang tot het LAN nodig, of moet iets op internet ook een dienst bereiken die op uw machine draait?

De eerste vraag scheidt een routeringsfout van een filterfout. De tweede zegt of een routecorrectie überhaupt mag werken. De derde verandert de reparatie: een route herstelt uitgaand verkeer, terwijl een onbereikbare inkomende dienst meestal een probleem is met de listener-binding en de terugweg dat een route verergert.

Vraag één: route, filter of naam

Lees de tabel voordat u er iets aan toevoegt. De interface-index is belangrijk, omdat elk routecommando hieronder eraan verankerd is:

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

Een direct aangesloten subnet behoudt normaal een on-link-route, zelfs als de tunnel actief is, dus een vermelding kan bestaan en het verkeer kan alsnog falen. Die combinatie is de signatuur van een filter dat na de routering draait, en dat is het geval waarin een tweede, specifiekere route helemaal niets verandert.

Test afzonderlijk op adres en op naam. Als ping 192.168.1.50 antwoordt en net view 192.168.1.50 niet, was de routeringstabel nooit het probleem: de tunnel heeft de resolver veranderd en de lokale naam wordt niet meer opgelost. Daarvoor een route toevoegen is verspilde arbeid.

Vraag twee: staat de gateway lokale LAN-toegang toe?

Een commerciële client installeert meer dan routes. Hij krijgt bij het verbinden een beleid, en dat beleid kan een expliciete toestemming voor het lokale netwerk bevatten. In Cisco IPsec-implementaties draagt het groepsbeleid de split-tunneling-instelling en een aparte vlag voor toegang tot het lokale LAN; het selectievakje in de client is een verzoek dat de gateway kan weigeren. In AnyConnect beheert het profiel de split-lijsten voor opnemen en uitsluiten en dezelfde toestemming. Op Windows RRAS zijn de equivalenten de optie voor de standaardgateway in het profiel plus de statische routes die de server toewijst.

Als de vlag uit staat, is het gedocumenteerde gedrag dat de client verkeer naar het direct aangesloten subnet blokkeert, ook al bestaat er een geldige, specifiekere route. Daarom kunnen routes die niet van de client zijn ook seconden na het toevoegen verdwijnen: de client bouwt de toestand opnieuw op die hem is opgedragen, en vecht niet tegen u.

Het clientlog legt de beslissing bij het verbinden vast, en het lezen ervan is sneller dan welk experiment op de machine dan ook. Als het log zegt dat lokale toegang geblokkeerd is, stop: geen enkele opdrachtregelcorrectie overleeft dat, en de enige overgebleven wegen zijn een beleidswijziging, de bron via de tunnel bereiken, of de client in een virtuele machine opsluiten en de host op het lokale netwerk laten.

Vraag drie: welke richting hebt u nodig?

Uitgaand verkeer naar een nabijgelegen apparaat is een routeringsvraag. Wijs het LAN-prefix naar de lokale gateway met een metriek die laag genoeg is om de standaardroute van de tunnel te verslaan:

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

De tweede vorm zet één apparaat vast, wat u wilt wanneer één adres de hele eis is. Het netsh-equivalent legt dezelfde beslissing vast op interfacenaam in plaats van index:

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

Routecommando's falen met De parameter is onjuist wanneer het adres en het masker niet overeenkomen, bijvoorbeeld een hostadres met een /24-masker. Gebruik het netwerkadres voor een subnetroute en een hostmasker voor één host.

Inkomend is anders. Een VNC- of SSH-server op dezelfde machine wordt onbereikbaar wanneer antwoorden op een inkomende verbinding via de VPN-gateway naar buiten gaan en nooit terugkomen. Controleer waar de dienst naar luistert voordat u routes aanraakt:

netstat -ano | findstr :5900

Een listener die aan één specifiek adres is gebonden, antwoordt niet op de andere interface. Hem aan alle interfaces binden is een bewuste beslissing, genomen samen met een firewallregel die beperkt is tot het netwerk dat u vertrouwt. Pas daarna herstelt de routereparatie de terugweg.

Pas de kleinste wijziging toe die past

De andere gebruikelijke stap is het uitvinken van ‘Standaardgateway op extern netwerk gebruiken’ in de geavanceerde IPv4-eigenschappen. Dat houdt internetverkeer lokaal, maar doet twee dingen tegelijk: de VPN is niet langer de standaardroute, en de client ontvangt geen routes meer voor het externe netwerk, inclusief multicast. Vink het uit en het externe LAN verdwijnt, tenzij de server de specifieke externe prefixen pusht die elke client nodig heeft.

Die asymmetrie bepaalt de werkvolgorde. Als de externe kant volledig bereikbaar moet blijven, push dan externe subnetten vanaf de server en laat de lokale standaard met rust. Als u de server niet kunt wijzigen, voeg dan een blijvende route naar het externe prefix toe via het adres dat de tunnel heeft toegewezen, en controleer met route print dat het prefix naar de VPN-interface wijst terwijl de standaard nog steeds naar de fysieke gateway wijst.

Bevestig daarna dat de reparatie een herverbinding overleeft, want niet-blijvende routes sterven met de adapter en een script dat na elke verbinding draait is de eerlijke plek ervoor. Test één lokaal apparaat en één externe bron in dezelfde sessie, verbreek de verbinding, verbind opnieuw en test opnieuw. Als het lokale apparaat nog steeds faalt terwijl de route er goed uitziet, ga terug naar vraag twee: de client filtert, en het antwoord is een beleidswijziging en niet een tweede concurrerende route.