Aïllament de clients Wi-Fi versus accés local per VPN: què us bloqueja

Poseu dos telèfons al mateix SSID de convidats i cap no veu l'altre, però tots dos arriben a internet. Afegiu un client VPN a un d'ells i la impressora a tres metres continua invisible mentre un servidor d'un altre continent respon als ping. No hi ha res trencat al túnel; hi intervenen dues decisions d'accés separades i només una tracta d'encaminament. El punt d'accés decideix si els clients sense fil poden parlar entre ells, i el client VPN decideix quines destinacions surten pel túnel. Confondre aquestes dues decisions produeix hores de canvis de configuració inútils.

Les dues portes són independents

L'aïllament de clients és una decisió de commutació. El punt d'accés accepta una trama d'una estació associada, mira la destinació, nota que la destinació és una altra estació del mateix pont i la descarta. L'adreça IP de l'estació és irrellevant per a aquesta decisió, i el VPN també.

L'encaminament és una altra decisió, presa al client. La taula d'encaminament del VPN decideix si un paquet per a 192.168.1.50 entra al túnel o surt per la interfície Wi-Fi. Si el paquet surt per Wi-Fi i el punt d'accés aïlla els clients, mor al punt d'accés. Si el paquet entra al túnel, el punt d'accés no veu mai la destinació original i no pot aïllar res.

Què bloqueja l'aïllament en un punt d'accés típic

Els fabricants ho distribueixen amb diversos noms: aïllament de clients, aïllament d'AP, aïllament d'estacions o una xarxa de convidats que ho implica. A OpenWrt l'opció per interfície és isolate dins la configuració sense fil, tal com es descriu a la documentació de xarxa sense fil, i un SSID de convidats normalment rep el seu propi pont i la seva zona de tallafoc. L'efecte és que les trames unicast entre clients no es ponten, de manera que un ping, una connexió SMB o un treball d'impressió a un veí falla encara que tots dos dispositius mostrin senyal complet.

Els protocols de descobriment pateixen primer i de manera més visible. El mDNS per a impressores i dispositius multimèdia va per multicast a 224.0.0.251, l'SSDP fa servir 239.255.255.250, i si aquestes trames creuen el pont depèn del fabricant i de si la conversió de multicast a unicast està activada. Un dispositiu que falta en una llista és una evidència més feble que una connexió directa fallida a una adreça coneguda.

Què canvia el VPN i què no pot canviar

Un túnel complet pren la ruta per defecte, així que les subxarxes locals només s'assoleixen si el client hi manté una ruta més específica. Els túnels dividits fan el contrari i preserven l'accés local per disseny. Cap dels dos ajustos no pot fer que un punt d'accés aïllant reenviï una trama entre dos dels seus clients, i per això permetre el trànsit local al client VPN és necessari però no suficient.

El cas invers és igual de comú. El punt d'accés permet el trànsit entre iguals, el client VPN exclou la subxarxa local del túnel i la impressora continua sense respondre perquè el tallafoc de l'amfitrió tracta la xarxa Wi-Fi com a pública. Tres capes, tres valors per defecte diferents, i només la ruta és visible a la majoria de registres del VPN.

Esbrineu quina porta és tancada

Comenceu amb una prova que tregui el VPN de l'equació: connecteu dos dispositius corrents al mateix SSID i proveu d'arribar d'un a l'altre per adreça. Si falla, el punt d'accés aïlla i cap ajust del VPN ho arreglarà. Si funciona, passeu al client i executeu ip route get 192.168.1.50 a Linux o Find-NetRoute -RemoteIPAddress 192.168.1.50 a Windows; la sortida indica la interfície que farà servir el paquet.

Quan la ruta apunta a la interfície Wi-Fi, el paquet surt sense xifrar i la pregunta passa a ser si el punt d'accés i el tallafoc de l'amfitrió ho permeten. Quan la ruta apunta al túnel, la destinació s'envia al servidor VPN, cosa equivocada per a un dispositiu de la mateixa LAN i que normalment vol dir que la llista permesa del túnel és massa àmplia.

Una connexió directa al port de la impressora és una prova millor que una llista de descobriment. nc -vz 192.168.1.50 9100 a Linux o Test-NetConnection 192.168.1.50 -Port 9100 a PowerShell us diu si l'adreça és assolible, abans que cap aparellament a nivell d'aplicació entri en discussió.

Trieu la solució per a la xarxa on sou

En una xarxa d'hotel o de convidats, l'aïllament és deliberat i no hauríeu d'intentar-lo derrotar. Tracteu el dispositiu local com a inassolible, feu servir el VPN per arribar a un amfitrió que pugui imprimir o compartir, i deixeu de tractar el SSID com una LAN.

A casa, desactivar l'aïllament al SSID principal és raonable quan els dispositius són vostres, mentre que el SSID de convidats continua aïllat. L'ajust viu a la configuració sense fil del punt d'accés i hi pertany, no a les excepcions del tallafoc de cada client.

En una oficina, assumiu que el punt d'accés, la VLAN i el tallafoc de l'amfitrió són intencionats. Escaleu amb els resultats de les proves en lloc de demanar que es desactivi l'aïllament, perquè una xarxa que separa clients normalment protegeix alguna cosa.

Verifiqueu l'aplicació, no només el ping

Un ping correcte demostra el camí, no el servei. Les impressores sovint accepten 9100 en brut o IPP al 631 però rebutgen el descobriment, i un recurs compartit necessita 445 més una resolució de noms que funcioni. Confirmeu el port que fa servir l'aplicació i després torneu a provar la tasca real al dispositiu.

Manteniu les dues capes separades a les notes: què permet la xarxa Wi-Fi i què encamina el VPN. El proper cop que un dispositiu desaparegui d'una llista, aquesta separació us dirà on mirar primer.