Router in VPN-clientmodus: waarom LAN-apparaten verdwijnen

De overtuiging dat de clientmodus zelf de LAN-toegang doodt, stuurt mensen naar het verkeerde instellingenmenu, en de echte oorzaken zijn meestal twee. De tunnel verwijdert de LAN-brug niet en verhindert niet dat bekabelde en draadloze clients elkaar bereiken. Wat lokale toegang breekt, is een inspectiefunctie in het doorstuurpad van de router of een LAN-adresbereik dat verschoof toen de firmware dat deed. Beide veroorzaken dezelfde klacht, en geen van beide wordt opgelost door het VPN-profiel opnieuw te installeren.

De mythe, en wat de clientmodus werkelijk verandert

De clientmodus voegt een tunnelinterface en een standaardroute toe die erdoorheen loopt, en stuurt vervolgens LAN-verkeer die tunnel in. De brug tussen de bekabelde poorten en de draadloze radio's blijft onaangeroerd, net als lokale switching. Wat verandert, is beleid: welk verkeer wordt doorgestuurd, waar het wordt vertaald en welke resolver de clients krijgen.

Dat onderscheid is belangrijk omdat een kapotte LAN meestal betekent dat een van die drie beleidsregels is gewijzigd, niet dat de router ophield een switch te zijn. Een router die nog zijn eigen beheerpagina beantwoordt, is het bewijs dat de LAN-interface leeft. Een router die helemaal niets beantwoordt, heeft een ander probleem, zoals een gewijzigd LAN-adres of een client op het verkeerde subnet.

Dus de nuttige eerste stap is uitzoeken welke laag kapot is, niet de laag veranderen die je vermoedt.

Test drie doelen voordat je een instelling aanraakt

Test vanaf een bekabelde client drie doelen afzonderlijk en noteer elk resultaat: het eigen LAN-adres van de router, een ander apparaat op dezelfde switch op IP, en iets dat alleen via de tunnel bereikbaar is. Doe ze in die volgorde, omdat elk resultaat een andere laag uitsluit. Gebruik in de eerste ronde adressen in plaats van namen, omdat een naamfout DNS in een connectiviteitsvraag mengt.

Het patroon van antwoorden is de diagnose. Een router die antwoordt terwijl lokale apparaten dat niet doen, wijst op lokale switching of een filterfunctie in plaats van routing. Lokale apparaten die antwoorden terwijl de tunnelzijde dat niet doet, wijzen op de tunnelroute of de externe firewall. Als alles op adres antwoordt maar namen falen, is dat een resolvervraag, en geen routebewerking lost dat op.

Houd de tabel naast de testresultaten. Hij verandert een vage klacht in één regel waarop je kunt handelen.

De beveiligingslaag in het doorstuurpad

Consumentenrouters worden steeds vaker geleverd met een inspectiefunctie die doorgestuurd verkeer bekijkt, en die draait in hetzelfde pad dat pakketten van LAN naar tunnel draagt. Wanneer die inspectie het tunnelverkeer niet kan classificeren, kan het doorsturen vastlopen terwijl de tunnel zelf blijft draaien en de router een gezonde verbinding meldt. Niets in het VPN-log laat dit zien, omdat de VPN daadwerkelijk verbinding maakte.

De diagnose is een gecontroleerd experiment, geen blijvende wijziging. Noteer de huidige instelling, schakel de functie voor de duur van één test uit, breng de tunnel weer omhoog en test één lokale host op adres. Doorsturen dat terugkomt, is het bewijs dat je nodig had, en de afweging wordt dan een beslissing in plaats van een gok. Als er niets verandert, schakel hem dan meteen weer in en ga naar de adresseringsoorzaak.

Een betaalde beveiligingsfunctie uitgeschakeld laten zodat een tunnel blijft werken, is een afweging die je bewust maakt en opschrijft. Het is ook de moeite waard te vragen of de tunnel op een ander apparaat thuishoort, want een router die alles moet inspecteren en een router die alles moet doorsturen zijn twee verschillende taken.

De tweede oorzaak: het LAN-bereik is verschoven

Firmware-updates zetten het LAN-adres routinematig terug naar de standaardwaarde van de fabrikant, en sommige routers hebben een expliciete modusschakelaar die beslist of de LAN een privébereik houdt of er een van het bovenliggende apparaat erft. Een client die 192.168.8.x verwacht, kan op 10.64.0.x belanden, en dan verloopt een SSH-sessie naar een host terwijl de tunnel volledig gezond is.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Lees het prefix en de gateway uit de lease voordat je de routerpagina opent. De eerste twee commando's laten zien wat de client werkelijk heeft ontvangen, en de derde laat zien welke interface de client voor een lokaal adres zou gebruiken, en zo verraadt een achtergebleven route of een verouderd subnet zich. Vergelijk dat dan met de LAN-pagina en de modus waarin de router staat.

Als het bereik niet terug kan, werk dan elk object bij dat het noemt: DHCP-reserveringen, elke statische route naar het oude subnet en elke firewallregel die het vorige prefix draagt. Een bereik dat botst met het externe subnet van de tunnel is de vervelendere variant, omdat lokale apparaten bereikbaar blijven terwijl externe bestemmingen stil naar de LAN worden gestuurd.

Opnieuw verbinden en opnieuw testen in pakketvolgorde

Na een van beide wijzigingen verbind je de tunnel opnieuw en herhaal je de tests in pakketvolgorde: router, lokale host, externe host, dan namen, dan de toepassing. De toepassing eerst testen verbergt welke laag nog kapot is, en een nieuwe poging van de browser tegen een gecachte naam kan op een routingfout lijken.

Noteer de firmwareversie, het LAN-prefix en de status van de inspectiefunctie naast het VPN-profiel. Alle drie zijn configuratie die de volgende update kan overschrijven, en twee regels notities besparen het uur dat je net hebt doorgebracht.