Wi-Fi-clientisolatie versus lokale VPN-toegang: wat je blokkeert

Zet twee telefoons op dezelfde gast-SSID en geen van beide ziet de ander, toch bereiken beide het internet. Voeg een VPN-client toe op een van beide en de printer drie meter verder blijft onzichtbaar, terwijl een server op een ander continent op pings antwoordt. Niets is kapot in de tunnel; er spelen twee afzonderlijke toegangsbeslissingen, en slechts één gaat over routering. Het toegangspunt beslist of draadloze clients met elkaar mogen praten, en de VPN-client beslist welke bestemmingen de tunnel verlaten. Die twee verwarren levert uren nutteloze configuratiewijzigingen op.

De twee poorten zijn onafhankelijk

Clientisolatie is een schakelbeslissing. Het toegangspunt neemt een frame van één geassocieerd station aan, kijkt naar de bestemming, merkt dat de bestemming een ander station op dezelfde bridge is, en laat het vallen. Het IP-adres van het station is irrelevant voor die beslissing, en de VPN ook.

Routering is een andere beslissing, genomen op de client. De routetabel van de VPN bepaalt of een pakket voor 192.168.1.50 de tunnel in gaat of via de Wi-Fi-interface naar buiten gaat. Als het pakket via Wi-Fi naar buiten gaat en het toegangspunt isoleert clients, sterft het bij het toegangspunt. Als het pakket de tunnel in gaat, ziet het toegangspunt de oorspronkelijke bestemming nooit en kan het niets isoleren.

Wat isolatie blokkeert op een typisch toegangspunt

Fabrikanten leveren dit onder verschillende namen: clientisolatie, AP-isolatie, stationisolatie of een gastnetwerk dat het impliceert. In OpenWrt is de optie per interface isolate binnen de draadloze configuratie, zoals beschreven in de draadloze documentatie, en een gast-SSID krijgt meestal een eigen bridge en firewallzone. Het effect is dat unicastframes tussen clients niet worden overbrugd, dus een ping, een SMB-verbinding of een afdruktaak naar een buur mislukt ook al tonen beide apparaten vol signaal.

Ontdekkingsprotocollen lijden het eerst en het zichtbaarst. mDNS voor printers en media-apparaten gaat via multicast naar 224.0.0.251, SSDP gebruikt 239.255.255.250, en of die frames de bridge oversteken hangt af van de fabrikant en van of multicast-naar-unicast-conversie aan staat. Een apparaat dat op een lijst ontbreekt is zwakker bewijs dan een mislukte directe verbinding naar een bekend adres.

Wat de VPN verandert, en wat hij niet kan veranderen

Een volledige tunnel neemt de standaardroute, dus lokale subnetten zijn alleen bereikbaar als de client er een specifiekere route voor houdt. Split-tunnels doen het omgekeerde en behouden lokale toegang per ontwerp. Geen van beide instellingen kan een isolerend toegangspunt dwingen een frame tussen twee van zijn clients door te sturen, daarom is lokaal verkeer toestaan in de VPN-client nodig maar niet voldoende.

Het omgekeerde geval komt net zo vaak voor. Het toegangspunt staat verkeer tussen clients toe, de VPN-client sluit het lokale subnet uit van de tunnel, en de printer antwoordt nog steeds niet omdat de firewall van de host het Wi-Fi-netwerk als openbaar behandelt. Drie lagen, drie verschillende standaardwaarden, en alleen de route is zichtbaar in de meeste VPN-logs.

Stel vast welke poort dicht is

Begin met een test die de VPN uit het beeld haalt: verbind twee gewone apparaten met dezelfde SSID en probeer het ene vanaf het andere via adres te bereiken. Als dat mislukt, isoleert het toegangspunt en geen enkele VPN-instelling lost dat op. Als het lukt, ga naar de client en voer ip route get 192.168.1.50 uit op Linux of Find-NetRoute -RemoteIPAddress 192.168.1.50 op Windows; de uitvoer noemt de interface die het pakket gebruikt.

Wijst de route naar de Wi-Fi-interface, dan verlaat het pakket onversleuteld en wordt de vraag of het toegangspunt en de firewall van de host dat toestaan. Wijst de route naar de tunnel, dan wordt de bestemming naar de VPN-server gestuurd, wat fout is voor een apparaat op hetzelfde LAN en meestal betekent dat de toegestane lijst van de tunnel te breed is.

Een directe verbinding naar de poort van de printer is een betere test dan een ontdekkingslijst. nc -vz 192.168.1.50 9100 op Linux of Test-NetConnection 192.168.1.50 -Port 9100 in PowerShell vertelt je of het adres überhaupt bereikbaar is, voordat enige koppeling op applicatieniveau ter sprake komt.

Kies de oplossing voor het netwerk waar je bent

Op een hotel- of gastnetwerk is isolatie bewust en moet je niet proberen die te omzeilen. Behandel het lokale apparaat als onbereikbaar, gebruik de VPN om een host te bereiken die kan printen of delen, en behandel de SSID niet langer als een LAN.

Thuis is isolatie uitschakelen op de hoofd-SSID redelijk wanneer de apparaten van jou zijn, terwijl de gast-SSID geïsoleerd blijft. De instelling woont in de draadloze configuratie van het toegangspunt, en daar hoort hij, niet in firewall-uitzonderingen op elke client.

Op kantoor moet je aannemen dat het toegangspunt, de VLAN en de firewall van de host allemaal bewust zijn. Escaleer met de testresultaten in plaats van te vragen isolatie uit te schakelen, want een netwerk dat clients scheidt beschermt meestal iets.

Controleer de toepassing, niet alleen de ping

Een geslaagde ping bewijst het pad, niet de dienst. Printers accepteren vaak ruwe 9100 of IPP op 631 maar weigeren ontdekking, en een bestandsshare vereist 445 plus werkende naamresolutie. Bevestig de poort die de toepassing gebruikt en probeer daarna de echte taak op het apparaat opnieuw.

Houd de twee lagen gescheiden in je notities: wat het Wi-Fi-netwerk toestaat en wat de VPN routeert. De volgende keer dat een apparaat uit een lijst verdwijnt, vertelt die scheiding je waar je het eerst moet kijken.