Wi-Fi kliensizoláció szemben a VPN helyi hozzáférésével: mi blokkol téged

Tegyél két telefont ugyanarra a vendég SSID-re, és egyik sem látja a másikat, mégis mindkettő eléri az internetet. Adj hozzá VPN-klienst az egyikhez, és a három méterre lévő nyomtató láthatatlan marad, miközben egy másik kontinensen lévő szerver válaszol a pingekre. Az alagútban semmi sem romlott el; két külön hozzáférési döntés játszik közre, és csak az egyik szól az útválasztásról. A hozzáférési pont dönti el, beszélhetnek-e egymással a vezeték nélküli kliensek, a VPN-kliens pedig azt dönti el, mely célok hagyják el az alagutat. A kettő összekeverése órákig tartó értelmetlen konfigurációmódosításokat szül.

A két kapu független

A kliensizoláció kapcsolási döntés. A hozzáférési pont fogad egy keretet egy társított állomástól, megnézi a célt, észreveszi, hogy a cél egy másik állomás ugyanazon a hídon, és eldobja. Az állomás IP-címe nem számít ebben a döntésben, és a VPN sem.

Az útválasztás másik döntés, amely a kliensen születik. A VPN útválasztási táblája dönti el, hogy egy 192.168.1.50 címre szóló csomag belép-e az alagútba, vagy a Wi-Fi interfészen keresztül távozik. Ha a csomag a Wi-Fi-n keresztül távozik, és a hozzáférési pont izolálja a klienseket, a hozzáférési pontnál meghal. Ha a csomag belép az alagútba, a hozzáférési pont soha nem látja az eredeti célt, és semmit sem tud izolálni.

Mit blokkol az izoláció egy tipikus hozzáférési ponton

A gyártók több néven szállítják: kliensizoláció, AP-izoláció, állomásizoláció vagy olyan vendéghálózat, amely ezt magában foglalja. Az OpenWrt-ben az interfészenkénti opció a vezeték nélküli konfiguráción belüli isolate, ahogy a vezeték nélküli dokumentáció leírja, és a vendég SSID általában saját hidat és tűzfalzónát kap. A hatás az, hogy a kliensek közötti unicast keretek nem kerülnek áthidalásra, így a ping, az SMB-kapcsolat vagy a szomszédnak küldött nyomtatási feladat meghiúsul, pedig mindkét eszköz teljes jelet mutat.

A felderítési protokollok szenvednek először és a legláthatóbban. A nyomtatók és médialejátszók mDNS-e multicasttal megy a 224.0.0.251 címre, az SSDP a 239.255.255.250 címet használja, és hogy ezek a keretek átlépik-e a hidat, a gyártótól és a multicast–unicast átalakítás bekapcsoltságától függ. Egy listáról hiányzó eszköz gyengébb bizonyíték, mint egy ismert címre indított sikertelen közvetlen kapcsolat.

Mit változtat a VPN, és mit nem tud megváltoztatni

A teljes alagút átveszi az alapértelmezett útvonalat, ezért a helyi alhálózatok csak akkor érhetők el, ha a kliens konkrétabb útvonalat tart fenn nekik. A megosztott alagutak az ellenkezőjét teszik, és tervezésüknél fogva megőrzik a helyi hozzáférést. Egyik beállítás sem kényszerítheti az izoláló hozzáférési pontot arra, hogy keretet továbbítson két kliense között, ezért a helyi forgalom engedélyezése a VPN-kliensben szükséges, de nem elégséges.

A fordított eset ugyanilyen gyakori. A hozzáférési pont engedi a kliensek közötti forgalmat, a VPN-kliens kizárja a helyi alhálózatot az alagútból, és a nyomtató mégsem válaszol, mert a gazdagép tűzfala a Wi-Fi-hálózatot nyilvánosnak tekinti. Három réteg, három különböző alapértelmezés, és a legtöbb VPN-naplóban csak az útvonal látszik.

Derítsd ki, melyik kapu zárva

Kezdd egy teszttel, amely kiveszi a VPN-t a képből: csatlakoztass két közönséges eszközt ugyanarra az SSID-re, és próbáld elérni az egyiket a másikról cím alapján. Ha ez meghiúsul, a hozzáférési pont izolál, és semmilyen VPN-beállítás nem javítja meg. Ha sikerül, lépj a kliensre, és futtasd a ip route get 192.168.1.50 parancsot Linuxon vagy a Find-NetRoute -RemoteIPAddress 192.168.1.50 parancsot Windows-on; a kimenet megnevezi az interfészt, amelyet a csomag használni fog.

Amikor az útvonal a Wi-Fi interfészre mutat, a csomag titkosítás nélkül távozik, és a kérdés az lesz, engedik-e a hozzáférési pont és a gazdagép tűzfala. Amikor az útvonal az alagútra mutat, a cél a VPN-kiszolgálóhoz kerül, ami helytelen egy ugyanazon a LAN-on lévő eszköznél, és általában azt jelenti, hogy az alagút engedélyezési listája túl széles.

A közvetlen kapcsolat a nyomtató portjára jobb teszt, mint egy felderítési lista. A nc -vz 192.168.1.50 9100 Linuxon vagy a Test-NetConnection 192.168.1.50 -Port 9100 PowerShellben megmondja, egyáltalán elérhető-e a cím, mielőtt bármilyen alkalmazásszintű párosítás szóba kerülne.

Válaszd ki a javítást ahhoz a hálózathoz, amelyen vagy

Szállodai vagy vendéghálózaton az izoláció szándékos, és nem kellene megpróbálnod kijátszani. Tekintsd a helyi eszközt elérhetetlennek, használd a VPN-t egy nyomtatni vagy megosztani képes gazdagép eléréséhez, és ne kezeld tovább az SSID-t LAN-ként.

Otthon a fő SSID izolációjának kikapcsolása ésszerű, ha az eszközök a tieid, míg a vendég SSID izolált marad. A beállítás a hozzáférési pont vezeték nélküli konfigurációjában él, és oda tartozik, nem pedig minden kliens tűzfalkivételei közé.

Egy irodában tételezd fel, hogy a hozzáférési pont, a VLAN és a gazdagép tűzfala mind szándékos. A teszteredményekkel eszkalálj, ahelyett hogy az izoláció kikapcsolását kérnéd, mert a klienseket elkülönítő hálózat általában véd valamit.

Az alkalmazást ellenőrizd, ne csak a pinget

A sikeres ping az útvonalat bizonyítja, nem a szolgáltatást. A nyomtatók gyakran elfogadják a nyers 9100-at vagy az IPP-t a 631-en, de elutasítják a felderítést, a fájlmegosztáshoz pedig 445 és működő névfeloldás kell. Erősítsd meg az alkalmazás által használt portot, majd próbáld újra a tényleges feladatot az eszközön.

Tartsd külön a két réteget a jegyzeteidben: mit engedélyez a Wi-Fi-hálózat, és mit irányít a VPN. Amikor legközelebb eltűnik egy eszköz egy listáról, ez a szétválasztás megmondja, hol keress először.