Lokaal netwerk onbereikbaar terwijl de VPN verbonden is? Vier controles

De tunnel komt op, het intranet verschijnt en de printer stopt met antwoorden. Op de LAN is niets stukgegaan; de client is van pad veranderd voor adressen die hij niet langer als lokaal beschouwt. Loop de vier controles hieronder in volgorde langs en stop zodra er één een concrete afwijking laat zien, want hetzelfde symptoom heeft vier veelvoorkomende oorzaken en slechts één ervan wordt verholpen door de VPN aan te passen.

Eerst: kijk naar de routetabel die de client heeft geïnstalleerd

Open de routetabel van de client terwijl de VPN verbonden is. Gebruik op Linux ip route, op Windows route print of Get-NetRoute, en op macOS netstat -rn. Je zoekt naar een standaardroute door de tunnel en naar wat er met de fysieke standaardroute is gebeurd.

Een full-tunnelclient voegt vaak twee halve standaardroutes toe, 0.0.0.0/1 en 128.0.0.0/1, in plaats van 0.0.0.0/0 te vervangen. De oorspronkelijke standaardroute blijft zichtbaar maar verliest elke lookup, waardoor de tabel intact kan lijken terwijl al het verkeer buiten het subnet verschuift. Als de VPN-client een split-tunneloptie biedt en het beleid dat toestaat, is dat de schoonste reparatie.

Moet de tunnel de standaard blijven, pin dan in plaats daarvan het lokale subnet vast. Op Linux noemt de route de fysieke interface en de gateway; voeg op Windows -p toe om hem blijvend te maken en lees het interfacenummer uit route print in plaats van het te raden:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Een vastgezette route houdt alleen stand zolang het adres dat hij noemt hetzelfde blijft. Een laptop die bij elke verbinding een nieuw nummer krijgt voor de Wi-Fi-adapter zal de regel opnieuw breken, dus controleer het interfaceadres voordat je concludeert dat de reparatie is mislukt.

Ten tweede: bevestig dat het adres überhaupt lokaal was

Als de bestemming binnen het verbonden subnet ligt, geldt de standaardroute van de tunnel nooit en is de VPN niet de oorzaak. Een printer op 192.168.1.40 op een client met 192.168.1.0/24 gebruikt de verbonden route; als dat adres faalt, kijk dan naar het apparaat, de switch of de firewall op de client in plaats van naar de VPN.

Het geval dat mensen misleidt is een openbaar adres voor een lokale server. Vanuit de LAN het WAN-adres van de router bereiken en terugkomen vereist hairpin-NAT, en veel routers implementeren dat simpelweg niet voor port forwarding. Test het privéadres naast het openbare. Als het privéadres werkt en het openbare niet, heeft de VPN alleen een NAT-beperking blootgelegd die er al was.

Een hostnaam maakt het erger. Als de lokale naam nu naar het openbare adres verwijst, blijft de client het pad proberen dat niet kan terugkeren. Gebruik het privéadres voor de test en repareer daarna de naam in plaats van nog een port forwarding toe te voegen.

Ten derde: kijk wie de namen nu beantwoordt

Een bedrijfsresolver kent het intranet en weet meestal niets van een NAS-hostnaam, de Bonjour-naam van een printer of de lokale alias van een router. Wanneer de VPN zijn DNS-servers pusht, worden die namen niet meer opgelost terwijl hun adressen nog steeds bereikbaar zijn. Bevraag de naam rechtstreeks en vergelijk het antwoord met het adres waarvan je weet dat het apparaat het heeft.

Op Linux laat resolvectl query nas.local zien welke resolver antwoordde. Op Windows noemt nslookup nas.local de server, en ipconfig /all toont de volgorde van de resolvers. Als het lokale suffix nu door de bedrijfsresolver wordt afgehandeld, leid dat suffix dan terug naar de lokale resolver of gebruik het IP-adres voor het apparaat.

Detectie is een aparte laag. mDNS en broadcast steken geen gerouteerde tunnel over, dus een apparaat kan via het adres bereikbaar zijn terwijl de naam onzichtbaar blijft. Een reflector of een lokale DNS-regel lost dat op; een route niet.

Ten vierde: controleer of de andere machine ook op een VPN zit

Wanneer de machine die je wilt bereiken ook een VPN-client draait, kan jouw sessie aankomen terwijl het antwoord via de andere tunnel vertrekt. Dat levert een verbinding op die tot stand komt en daarna blijft hangen, of een RDP- en SSH-poging die aan jouw kant zonder fout in een time-out loopt. Controleer de routetabel en het standaardpad van de andere host voordat je je eigen client de schuld geeft.

Controleer ook het adres waarop de dienst luistert. Een listener die alleen aan het tunneladres gebonden is, accepteert verbindingen van de VPN en weigert ze van de LAN, zelfs wanneer de routing perfect is. Dat is een dienstconfiguratie, geen netwerkpad, en het komt vaak voor bij beheerinterfaces die op het VPN-adres zijn vastgezet.

Houd een beheerpad aan dat niet van de tunnel afhangt: een statische route die jouw bronnetwerk noemt, een andere interface die aan de LAN hangt, of een console die de tunnel volledig omzeilt. Dat pad ontwerpen nadat de sessie wegvalt is veel moeilijker dan het toevoegen vóór de volgende verbinding.

Pas de reparatie toe die past bij de controle die faalde

Als de routetabel een halve-standaard-overname liet zien, kies dan split tunnel wanneer het beleid het toestaat en een vastgezette lokale route wanneer niet. Als het adres openbaar bleek, schakel de test en de naam dan om naar het privéadres. Als de resolver van eigenaar wisselde, beperk je tot het lokale suffix of gebruik het adres. Als de andere host in een tunnel zit, repareer dan zijn retourpad of zijn listenerbinding.

Verander één ding en herhaal daarna dezelfde controle. Een route die voor het verkeerde subnet is toegevoegd, een resolversuffix met een typefout en een vastgezette route op een interface die nieuwe nummers krijgt, zien er allemaal uit als de oorspronkelijke storing. De herhaling is wat een reparatie van een toeval scheidt.

Schrijf de route, het adres en de resolver op die werkten terwijl de VPN verbonden was. De volgende herverbinding verandert minstens één ervan, en de notitie maakt de volgende storing een korte vergelijking in plaats van een nieuw onderzoek.