Wi-Fi-klientisolering kontra lokal VPN-åtkomst: vad som blockerar dig

Sätt två telefoner på samma gäst-SSID och ingen av dem ser den andra, men båda når internet. Lägg till en VPN-klient på en av dem och skrivaren tre meter bort förblir osynlig, medan en server på en annan kontinent svarar på ping. Inget är trasigt i tunneln; det är två separata åtkomstbeslut inblandade, och bara ett av dem handlar om routing. Åtkomstpunkten avgör om trådlösa klienter får tala med varandra, och VPN-klienten avgör vilka destinationer som lämnar tunneln. Att blanda ihop de två ger timmar av meningslösa konfigurationsändringar.

De två portarna är oberoende

Klientisolering är ett switchbeslut. Åtkomstpunkten tar emot en ram från en associerad station, tittar på destinationen, märker att destinationen är en annan station på samma brygga och släpper den. Stationens IP-adress är irrelevant för det beslutet, och det är VPN:en också.

Routing är ett annat beslut, fattat på klienten. VPN:ens routingtabell avgör om ett paket till 192.168.1.50 går in i tunneln eller lämnar via Wi-Fi-gränssnittet. Om paketet lämnar via Wi-Fi och åtkomstpunkten isolerar klienter, dör det vid åtkomstpunkten. Om paketet går in i tunneln ser åtkomstpunkten aldrig den ursprungliga destinationen och kan inte isolera något.

Vad isolering blockerar på en typisk åtkomstpunkt

Tillverkare levererar detta under flera namn: klientisolering, AP-isolering, stationsisolering eller ett gästnätverk som antyder det. I OpenWrt är alternativet per gränssnitt isolate inne i den trådlösa konfigurationen, som beskrivs i den trådlösa dokumentationen, och ett gäst-SSID får vanligtvis sin egen brygga och brandväggszon. Effekten är att unicast-ramar mellan klienter inte bryggas, så en ping, en SMB-anslutning eller ett utskriftsjobb till en granne misslyckas trots att båda enheterna visar full signal.

Upptäcktsprotokoll lider först och mest synligt. mDNS för skrivare och medieenheter går med multicast till 224.0.0.251, SSDP använder 239.255.255.250, och om dessa ramar korsar bryggan beror på tillverkaren och på om multicast-till-unicast-omvandling är påslagen. En enhet som saknas i en lista är svagare bevis än en misslyckad direkt anslutning till en känd adress.

Vad VPN:en ändrar, och vad den inte kan ändra

En full tunnel tar standardrutten, så lokala subnät nås bara om klienten behåller en mer specifik rutt för dem. Delade tunnlar gör det motsatta och bevarar lokal åtkomst enligt design. Ingen av inställningarna kan tvinga en isolerande åtkomstpunkt att vidarebefordra en ram mellan två av sina klienter, därför är det nödvändigt, men inte tillräckligt, att tillåta lokal trafik i VPN-klienten.

Det omvända fallet är lika vanligt. Åtkomstpunkten tillåter peer-trafik, VPN-klienten utesluter det lokala subnätet från tunneln, och skrivaren svarar fortfarande inte eftersom värdens brandvägg behandlar Wi-Fi-nätverket som offentligt. Tre lager, tre olika standardvärden, och bara rutten syns i de flesta VPN-loggar.

Ta reda på vilken port som är stängd

Börja med ett test som tar bort VPN:en från bilden: anslut två vanliga enheter till samma SSID och försök nå den ena från den andra via adress. Om det misslyckas isolerar åtkomstpunkten och ingen VPN-inställning åtgärdar det. Om det lyckas, gå till klienten och kör ip route get 192.168.1.50 på Linux eller Find-NetRoute -RemoteIPAddress 192.168.1.50 på Windows; utdata namnger gränssnittet paketet kommer att använda.

När rutten pekar på Wi-Fi-gränssnittet lämnar paketet okrypterat och frågan blir om åtkomstpunkten och värdens brandvägg tillåter det. När rutten pekar på tunneln skickas destinationen till VPN-servern, vilket är fel för en enhet på samma LAN och brukar betyda att tunnelns tillåtna lista är för bred.

En direkt anslutning till skrivarens port är ett bättre test än en upptäcktslista. nc -vz 192.168.1.50 9100 på Linux eller Test-NetConnection 192.168.1.50 -Port 9100 i PowerShell talar om ifall adressen över huvud taget går att nå, innan någon parning på applikationsnivå kommer in i diskussionen.

Välj lösningen för nätverket du är på

På ett hotell- eller gästnätverk är isolering avsiktlig och du bör inte försöka kringgå den. Behandla den lokala enheten som onåbar, använd VPN:en för att nå en värd som kan skriva ut eller dela, och sluta behandla SSID:t som ett LAN.

Hemma är det rimligt att stänga av isolering på huvud-SSID:t när enheterna är dina, medan gäst-SSID:t förblir isolerat. Inställningen bor i åtkomstpunktens trådlösa konfiguration, och den hör hemma där, inte i brandväggsundantag på varje klient.

På ett kontor bör du anta att åtkomstpunkten, VLAN:et och värdens brandvägg alla är avsiktliga. Eskalera med testresultaten i stället för att be om att isoleringen stängs av, eftersom ett nätverk som skiljer klienter vanligtvis skyddar något.

Verifiera applikationen, inte bara ping

En lyckad ping bevisar vägen, inte tjänsten. Skrivare accepterar ofta rå 9100 eller IPP på 631 men avvisar upptäckt, och en filshare kräver 445 plus fungerande namnmatchning. Bekräfta porten som applikationen använder och försök sedan igen med den faktiska uppgiften på enheten.

Håll de två lagren åtskilda i dina anteckningar: vad Wi-Fi-nätverket tillåter och vad VPN:en dirigerar. Nästa gång en enhet försvinner från en lista säger den uppdelningen dig var du ska leta först.