Izolarea clienților Wi-Fi față de accesul local prin VPN: ce vă blochează

Puneți două telefoane în același SSID de oaspeți și niciunul nu îl vede pe celălalt, dar amândouă ajung la internet. Adăugați un client VPN pe unul dintre ele și imprimanta de la trei metri rămâne invizibilă, în timp ce un server de pe alt continent răspunde la ping. Nimic nu este stricat în tunel; sunt implicate două decizii de acces separate, iar doar una dintre ele este despre rutare. Punctul de acces decide dacă clienții fără fir pot vorbi între ei, iar clientul VPN decide ce destinații ies prin tunel. Confundarea celor două produce ore de modificări de configurare inutile.

Cele două porți sunt independente

Izolarea clienților este o decizie de comutare. Punctul de acces primește un cadru de la o stație asociată, se uită la destinație, observă că destinația este o altă stație pe același pod și îl aruncă. Adresa IP a stației este irelevantă pentru acea decizie, iar VPN-ul la fel.

Rutarea este o altă decizie, luată pe client. Tabelul de rutare al VPN-ului decide dacă un pachet către 192.168.1.50 intră în tunel sau iese prin interfața Wi-Fi. Dacă pachetul iese prin Wi-Fi și punctul de acces izolează clienții, moare la punctul de acces. Dacă pachetul intră în tunel, punctul de acces nu vede niciodată destinația originală și nu poate izola nimic.

Ce blochează izolarea pe un punct de acces tipic

Producătorii livrează asta sub mai multe nume: izolarea clienților, izolarea AP, izolarea stațiilor sau o rețea de oaspeți care o implică. În OpenWrt opțiunea pe interfață este isolate în configurația wireless, așa cum este descris în documentația wireless, iar un SSID de oaspeți primește de obicei propriul pod și zona de firewall. Efectul este că cadrele unicast între clienți nu sunt punte, așa că un ping, o conexiune SMB sau o lucrare de imprimare către un vecin eșuează chiar dacă ambele dispozitive arată semnal complet.

Protocoalele de descoperire au de suferit primele și cel mai vizibil. mDNS pentru imprimante și dispozitive media merge prin multicast către 224.0.0.251, SSDP folosește 239.255.255.250, iar dacă acele cadre traversează podul depinde de producător și de activarea conversiei din multicast în unicast. Un dispozitiv lipsă dintr-o listă este o dovadă mai slabă decât o conexiune directă eșuată către o adresă cunoscută.

Ce schimbă VPN-ul și ce nu poate schimba

Un tunel complet preia ruta implicită, așa că subrețelele locale sunt accesibile doar dacă clientul păstrează o rută mai specifică pentru ele. Tunelurile divizate fac invers și păstrează accesul local prin proiectare. Niciuna dintre setări nu poate obliga un punct de acces care izolează să transmită un cadru între doi dintre clienții săi, de aceea permiterea traficului local în clientul VPN este necesară, dar nu suficientă.

Cazul invers este la fel de frecvent. Punctul de acces permite trafic între perechi, clientul VPN exclude subrețeaua locală din tunel, iar imprimanta tot nu răspunde pentru că firewall-ul gazdei tratează rețeaua Wi-Fi ca publică. Trei straturi, trei valori implicite diferite, și doar ruta este vizibilă în majoritatea jurnalelor VPN.

Stabiliți care poartă este închisă

Începeți cu un test care scoate VPN-ul din imagine: conectați două dispozitive obișnuite la același SSID și încercați să ajungeți de la unul la altul după adresă. Dacă eșuează, punctul de acces izolează și nicio setare VPN nu va repara asta. Dacă reușește, treceți la client și rulați ip route get 192.168.1.50 pe Linux sau Find-NetRoute -RemoteIPAddress 192.168.1.50 pe Windows; ieșirea numește interfața pe care o va folosi pachetul.

Când ruta indică interfața Wi-Fi, pachetul iese necriptat și întrebarea devine dacă punctul de acces și firewall-ul gazdei permit asta. Când ruta indică tunelul, destinația este trimisă către serverul VPN, ceea ce este greșit pentru un dispozitiv din aceeași rețea locală și de obicei înseamnă că lista permisă a tunelului este prea largă.

O conexiune directă la portul imprimantei este un test mai bun decât o listă de descoperire. nc -vz 192.168.1.50 9100 pe Linux sau Test-NetConnection 192.168.1.50 -Port 9100 în PowerShell vă spune dacă adresa este accesibilă, înainte ca orice împerechere la nivel de aplicație să intre în discuție.

Alegeți remedierea pentru rețeaua în care sunteți

Într-o rețea de hotel sau de oaspeți, izolarea este deliberată și nu ar trebui să încercați să o învingeți. Tratați dispozitivul local ca inaccesibil, folosiți VPN-ul pentru a ajunge la o gazdă care poate imprima sau partaja și nu mai tratați SSID-ul ca pe o rețea locală.

Acasă, dezactivarea izolării pe SSID-ul principal este rezonabilă când dispozitivele sunt ale dumneavoastră, în timp ce SSID-ul de oaspeți rămâne izolat. Setarea locuiește în configurația wireless a punctului de acces și acolo îi este locul, nu în excepțiile de firewall de pe fiecare client.

La birou, presupuneți că punctul de acces, VLAN-ul și firewall-ul gazdei sunt toate intenționate. Escaladați cu rezultatele testelor în loc să cereți dezactivarea izolării, pentru că o rețea care separă clienții protejează de obicei ceva.

Verificați aplicația, nu doar ping

Un ping reușit dovedește calea, nu serviciul. Imprimantele acceptă adesea 9100 brut sau IPP pe 631, dar refuză descoperirea, iar partajarea fișierelor are nevoie de 445 plus rezolvare de nume funcțională. Confirmați portul folosit de aplicație, apoi reîncercați sarcina reală pe dispozitiv.

Țineți cele două straturi separate în notițe: ce permite rețeaua Wi-Fi și ce rutează VPN-ul. Data viitoare când un dispozitiv dispare dintr-o listă, această separare vă va spune unde să priviți mai întâi.