Wi-Fi-klienta izolado kontraŭ loka VPN-aliro: kio vin blokas
Du aparatoj en la sama SSID ankoraŭ povas ne atingi unu la alian. Komparu, kion blokas la Wi-Fi-klienta izolado kaj kion enkursigas la VPN-tunelo.
Metu du telefonojn en la saman gastan SSID kaj neniu vidas la alian, sed ambaŭ atingas la interreton. Aldonu VPN-klienton al unu el ili kaj la presilo tri metrojn for restas nevidebla, dum servilo sur alia kontinento respondas al ping. Nenio estas difektita en la tunelo; du apartaj aliraj decidoj partoprenas, kaj nur unu el ili temas pri enkursigo. La alirpunkto decidas ĉu sendrataj klientoj rajtas interparoli, kaj la VPN-kliento decidas kiuj celoj eliras tra la tunelo. Konfuzi tiujn du produktas horojn da senutilaj agordaj ŝanĝoj.
La du pordegoj estas sendependaj
Klienta izolado estas komuta decido. La alirpunkto akceptas kadron de unu asociita stacio, rigardas la celon, rimarkas ke la celo estas alia stacio sur la sama ponto, kaj forĵetas ĝin. La IP-adreso de la stacio ne gravas por tiu decido, kaj same ne la VPN.
Enkursigo estas malsama decido, farata en la kliento. La enkursiga tabelo de la VPN decidas ĉu paketo por 192.168.1.50 eniras la tunelon aŭ eliras tra la Wi-Fi-aparataro. Se la paketo eliras tra Wi-Fi kaj la alirpunkto izolas klientojn, ĝi mortas ĉe la alirpunkto. Se la paketo eniras la tunelon, la alirpunkto neniam vidas la originan celon kaj povas izoli nenion.
Kion izolado blokas en tipa alirpunkto
Fabrikantoj liveras ĉi tion sub pluraj nomoj: klienta izolado, AP-izolado, stacia izolado, aŭ gastreto kiu implicas ĝin. En OpenWrt la opcio por ĉiu interfaco estas isolate ene de la sendrata agordo, kiel priskribite en la sendrata dokumentaro, kaj gasto-SSID kutime ricevas propran ponton kaj fajroŝirmilan zonon. La efekto estas ke unicast-kadroj inter klientoj ne estas pontataj, do ping, SMB-ligo aŭ presa tasko al najbaro malsukcesas eĉ kiam ambaŭ aparatoj montras plenan signalon.
Malkovraj protokoloj suferas unue kaj plej videble. mDNS por presiloj kaj aŭdvidaj aparatoj iras per multicast al 224.0.0.251, SSDP uzas 239.255.255.250, kaj ĉu tiuj kadroj transpontas dependas de la fabrikanto kaj de tio ĉu konvertado de multicast al unicast estas ŝaltita. Aparato mankanta en listo estas pli malforta pruvo ol malsukcesa rekta ligo al konata adreso.
Kion la VPN ŝanĝas, kaj kion ĝi ne povas ŝanĝi
Plena tunelo prenas la defaŭltan itineron, do lokaj subretoj atingeblas nur se la kliento konservas pli specifan itineron por ili. Fenditaj tuneloj faras la malon kaj konservas lokan aliron laŭplane. Neniu agordo povas devigi izolan alirpunkton plusendi kadron inter du el ĝiaj klientoj, tial permesi lokan trafikon en la VPN-kliento estas necesa sed ne sufiĉa.
La inversa kazo same oftas. La alirpunkto permesas samtavolan trafikon, la VPN-kliento ekskludas la lokan subreton el la tunelo, kaj la presilo ankoraŭ ne respondas ĉar la gastiga fajroŝirmilo traktas la Wi-Fi-reton kiel publikan. Tri tavoloj, tri malsamaj defaŭltoj, kaj nur la itineron videblas en plej multaj VPN-protokoloj.
Determinu kiun pordegon fermas
Komencu per testo kiu forigas la VPN el la bildo: konektu du ordinarajn aparatojn al la sama SSID kaj provu atingi unu el la alia per adreso. Se tio malsukcesas, la alirpunkto izolas kaj neniu VPN-agordo riparos ĝin. Se ĝi sukcesas, iru al la kliento kaj rulu ip route get 192.168.1.50 en Linux aŭ Find-NetRoute -RemoteIPAddress 192.168.1.50 en Windows; la eligo nomas la interfacon kiun la paketo uzos.
Kiam la itinero montras al la Wi-Fi-interfaco, la paketo eliras neĉifrita kaj la demando fariĝas ĉu la alirpunkto kaj la gastiga fajroŝirmilo permesas ĝin. Kiam la itinero montras al la tunelo, la celo estas sendata al la VPN-servilo, kio malĝustas por aparato en la sama loka reto kaj kutime signifas ke la permeslisto de la tunelo estas tro larĝa.
Rekta ligo al la pordo de la presilo estas pli bona testo ol malkovra listo. nc -vz 192.168.1.50 9100 en Linux aŭ Test-NetConnection 192.168.1.50 -Port 9100 en PowerShell diras al vi ĉu la adreso entute atingeblas, antaŭ ol iu ajn aplikaĵnivela parigo eniras la diskuton.
Elektu la korekton por la reto en kiu vi estas
En hotelo aŭ gastreto, izolado estas intenca kaj vi ne devus provi venki ĝin. Traktu la lokan aparaton kiel neatingeblan, uzu la VPN por atingi gastiganton kiu povas presi aŭ kunhavigi, kaj ĉesu trakti la SSID kiel lokan reton.
Hejme, malŝalti izoladon en la ĉefa SSID estas racia kiam la aparatoj estas viaj, dum la gasto-SSID restas izolita. La agordo loĝas en la sendrata agordo de la alirpunkto, kaj ĝi apartenas tien, ne en fajroŝirmilaj esceptoj en ĉiu kliento.
En oficejo, supozu ke la alirpunkto, la VLAN kaj la gastiga fajroŝirmilo estas ĉiuj intencaj. Eskaladu kun la testrezultoj anstataŭ peti malŝalti la izoladon, ĉar reto kiu apartigas klientojn kutime protektas ion.
Kontrolu la aplikaĵon, ne nur la ping
Sukcesa ping pruvas la vojon, ne la servon. Presiloj ofte akceptas krudan 9100 aŭ IPP sur 631 sed rifuzas malkovron, kaj dosierkomunaĵo bezonas 445 plus funkciantan nomrezolucion. Konfirmu la pordon kiun la aplikaĵo uzas, poste reprovu la realan taskon sur la aparato.
Tenu la du tavolojn aparte en viaj notoj: kion la Wi-Fi-reto permesas, kaj kion la VPN enkursigas. La venontan fojon kiam aparato malaperos el listo, tiu divido diros al vi kie unue rigardi.