Izolimi i klientëve Wi-Fi kundrejt aksesit lokal të VPN: çfarë ju bllokon
Dy pajisje në të njëjtin SSID mund të mos arrijnë ende njëra-tjetrën. Krahasoni çfarë bllokon izolimi i klientëve Wi-Fi me atë që drejton tuneli VPN.
Vendosni dy telefona në të njëjtin SSID mysafirësh dhe asnjëri nuk e sheh tjetrin, por të dy arrijnë internetin. Shtoni një klient VPN në njërin prej tyre dhe printeri tre metra larg mbetet i padukshëm, ndërsa një server në një kontinent tjetër përgjigjet ping-ve. Asgjë nuk është prishur në tunel; janë të përfshira dy vendime aksesi të ndara dhe vetëm njëri prej tyre ka të bëjë me rrugëzimin. Pika e aksesit vendos nëse klientët pa tela mund të flasin me njëri-tjetrin, dhe klienti VPN vendos cilat destinacione dalin nga tuneli. Ngatërrimi i këtyre dyve prodhon orë ndryshimesh konfigurimi të padobishme.
Dy portat janë të pavarura
Izolimi i klientëve është një vendim komutimi. Pika e aksesit pranon një kornizë nga një stacion i lidhur, shikon destinacionin, vëren se destinacioni është një stacion tjetër në të njëjtin urë dhe e hedh atë. Adresa IP e stacionit është e parëndësishme për atë vendim, dhe VPN-i gjithashtu.
Rrugëzimi është një vendim tjetër, i marrë në klient. Tabela e rrugëzimit të VPN-it vendos nëse një paketë për 192.168.1.50 hyn në tunel apo del përmes ndërfaqes Wi-Fi. Nëse paketa del përmes Wi-Fi dhe pika e aksesit izolon klientët, ajo vdes në pikën e aksesit. Nëse paketa hyn në tunel, pika e aksesit nuk e sheh kurrë destinacionin origjinal dhe nuk mund të izolojë asgjë.
Çfarë bllokon izolimi në një pikë aksesi tipike
Prodhuesit e ofrojnë këtë me disa emra: izolim i klientëve, izolim AP, izolim stacionesh ose një rrjet mysafirësh që e nënkupton. Në OpenWrt opsioni për çdo ndërfaqe është isolate brenda konfigurimit pa tela, siç përshkruhet në dokumentacionin pa tela, dhe një SSID mysafirësh zakonisht merr urën dhe zonën e vet të murit të zjarrit. Efekti është që kornizat unicast midis klientëve nuk urazohen, prandaj një ping, një lidhje SMB ose një punë printimi drejt një fqinji dështon edhe pse të dyja pajisjet tregojnë sinjal të plotë.
Protokollet e zbulimit vuajnë të parët dhe më dukshëm. mDNS për printerë dhe pajisje media shkon me multicast drejt 224.0.0.251, SSDP përdor 239.255.255.250, dhe nëse ato korniza kalojnë urën varet nga prodhuesi dhe nga fakti nëse konvertimi nga multicast në unicast është aktiv. Një pajisje që mungon në një listë është provë më e dobët sesa një lidhje e drejtpërdrejtë e dështuar drejt një adrese të njohur.
Çfarë ndryshon VPN-i dhe çfarë nuk mund të ndryshojë
Një tunel i plotë merr rrugën e parazgjedhur, prandaj nënrrjetet lokale arrihen vetëm nëse klienti mban një rrugë më specifike për to. Tunelet e ndara bëjnë të kundërtën dhe e ruajnë aksesin lokal sipas projektimit. Asnjëri prej konfigurimeve nuk mund ta detyrojë një pikë aksesi izoluese të përcjellë një kornizë midis dy klientëve të saj, prandaj lejimi i trafikut lokal në klientin VPN është i nevojshëm, por jo i mjaftueshëm.
Rasti i kundërt është po aq i zakonshëm. Pika e aksesit lejon trafik midis barabartëve, klienti VPN e përjashton nënrrjetin lokal nga tuneli, dhe printeri prapë nuk përgjigjet sepse muri i zjarrit i hostit e trajton rrjetin Wi-Fi si publik. Tre shtresa, tre parazgjedhje të ndryshme, dhe vetëm rruga është e dukshme në shumicën e regjistrave të VPN-it.
Zbuloni cila portë është e mbyllur
Filloni me një test që e heq VPN-in nga fotografia: lidhni dy pajisje të zakonshme në të njëjtin SSID dhe provoni të arrini njërën nga tjetra sipas adresës. Nëse dështon, pika e aksesit po izolon dhe asnjë konfigurim VPN nuk do ta rregullojë. Nëse ka sukses, kaloni te klienti dhe ekzekutoni ip route get 192.168.1.50 në Linux ose Find-NetRoute -RemoteIPAddress 192.168.1.50 në Windows; dalja emërton ndërfaqen që do të përdorë paketa.
Kur rruga tregon ndërfaqen Wi-Fi, paketa del e pafshehur dhe pyetja bëhet nëse pika e aksesit dhe muri i zjarrit i hostit e lejojnë. Kur rruga tregon tunelin, destinacioni po dërgohet te serveri VPN, gjë që është e gabuar për një pajisje në të njëjtin LAN dhe zakonisht do të thotë që lista e lejuar e tunelit është shumë e gjerë.
Një lidhje e drejtpërdrejtë me portën e printerit është test më i mirë sesa një listë zbulimi. nc -vz 192.168.1.50 9100 në Linux ose Test-NetConnection 192.168.1.50 -Port 9100 në PowerShell ju tregon nëse adresa është e arritshme fare, përpara se ndonjë çiftim në nivel aplikacioni të hyjë në diskutim.
Zgjidhni rregullimin për rrjetin ku ndodheni
Në një rrjet hoteli ose mysafirësh, izolimi është i qëllimshëm dhe nuk duhet të provoni ta mposhtni. Trajtojeni pajisjen lokale si të paarritshme, përdorni VPN-in për të arritur një host që mund të printojë ose të ndajë, dhe reshtni së trajtuari SSID-në si LAN.
Në shtëpi, çaktivizimi i izolimit në SSID-në kryesore është i arsyeshëm kur pajisjet janë tuajat, ndërsa SSID-ja e mysafirëve mbetet e izoluar. Konfigurimi jeton në konfigurimin pa tela të pikës së aksesit dhe aty i takon, jo në përjashtimet e murit të zjarrit në çdo klient.
Në zyrë, supozoni se pika e aksesit, VLAN-i dhe muri i zjarrit i hostit janë të gjithë të qëllimshëm. Eskaloni me rezultatet e testeve në vend që të kërkoni çaktivizimin e izolimit, sepse një rrjet që i ndan klientët zakonisht mbron diçka.
Verifikoni aplikacionin, jo vetëm ping
Një ping i suksesshëm provon rrugën, jo shërbimin. Printerët shpesh pranojnë 9100 të papërpunuar ose IPP në 631, por refuzojnë zbulimin, dhe ndarja e skedarëve kërkon 445 plus zgjidhje funksionale të emrave. Konfirmoni portën që përdor aplikacioni, pastaj riprovoni detyrën reale në pajisje.
Mbani dy shtresat të ndara në shënimet tuaja: çfarë lejon rrjeti Wi-Fi dhe çfarë drejton VPN-i. Herën tjetër që një pajisje zhduket nga një listë, ai ndarje do t'ju thotë ku të shikoni së pari.