Illamento de clientes Wi-Fi fronte ao acceso local por VPN: que te bloquea

Pon dous teléfonos na mesma SSID de convidados e ningún ve o outro, pero ambos chegan a internet. Engade un cliente VPN nun deles e a impresora a tres metros segue invisible mentres un servidor noutro continente responde aos ping. Nada está roto no túnel; interveñen dúas decisións de acceso distintas e só unha ten que ver co encamiñamento. O punto de acceso decide se os clientes sen fíos poden falar entre si, e o cliente VPN decide que destinos saen polo túnel. Confundir esas dúas decisións produce horas de cambios de configuración inútiles.

As dúas portas son independentes

O illamento de clientes é unha decisión de conmutación. O punto de acceso acepta unha trama dunha estación asociada, mira o destino, decátase de que o destino é outra estación da mesma ponte e descártaa. O enderezo IP da estación é irrelevante para esa decisión, e o VPN tamén.

O encamiñamento é outra decisión, tomada no cliente. A táboa de rutas do VPN decide se un paquete para 192.168.1.50 entra no túnel ou sae pola interface Wi-Fi. Se o paquete sae por Wi-Fi e o punto de acceso illa os clientes, morre no punto de acceso. Se o paquete entra no túnel, o punto de acceso nunca ve o destino orixinal e non pode illar nada.

Que bloquea o illamento nun punto de acceso típico

Os fabricantes distribúeno con varios nomes: illamento de clientes, illamento de AP, illamento de estacións ou unha rede de convidados que o implica. En OpenWrt a opción por interface é isolate dentro da configuración sen fíos, como se describe na documentación sen fíos, e unha SSID de convidados adoita recibir a súa propia ponte e a súa zona de cortafuegos. O efecto é que as tramas unicast entre clientes non se pontan, así que un ping, unha conexión SMB ou un traballo de impresión a un veciño falla aínda que ambos os dispositivos mostren sinal completa.

Os protocolos de descuberta sofren primeiro e de forma máis visible. mDNS para impresoras e dispositivos multimedia vai por multicast a 224.0.0.251, SSDP usa 239.255.255.250, e se esas tramas cruzan a ponte depende do fabricante e de se está activada a conversión de multicast a unicast. Un dispositivo que falta nunha lista é unha evidencia máis feble que unha conexión directa fallida a un enderezo coñecido.

Que cambia o VPN e que non pode cambiar

Un túnel completo toma a ruta por defecto, así que as subredes locais só se alcanzan se o cliente mantén unha ruta máis específica para elas. Os túneles divididos fan o contrario e preservan o acceso local por deseño. Ningún dos dous axustes pode facer que un punto de acceso illante reenvíe unha trama entre dous dos seus clientes, por iso permitir o tráfico local no cliente VPN é necesario pero non suficiente.

O caso inverso é igual de común. O punto de acceso permite o tráfico entre pares, o cliente VPN exclúe a subrede local do túnel e a impresora segue sen responder porque o cortafuegos do anfitrión trata a rede Wi-Fi como pública. Tres capas, tres valores por defecto distintos, e só a ruta é visible na maioría dos rexistros do VPN.

Averigua que porta está pechada

Comeza cunha proba que saque o VPN da ecuación: conecta dous dispositivos correntes á mesma SSID e intenta chegar dun a outro por enderezo. Se falla, o punto de acceso illa e ningún axuste do VPN o arranxará. Se funciona, pasa ao cliente e executa ip route get 192.168.1.50 en Linux ou Find-NetRoute -RemoteIPAddress 192.168.1.50 en Windows; a saída nomea a interface que usará o paquete.

Cando a ruta apunta á interface Wi-Fi, o paquete sae sen cifrar e a pregunta pasa a ser se o punto de acceso e o cortafuegos do anfitrión o permiten. Cando a ruta apunta ao túnel, o destino envíase ao servidor VPN, o que é erróneo para un dispositivo na mesma LAN e normalmente significa que a lista permitida do túnel é demasiado ampla.

Unha conexión directa ao porto da impresora é unha proba mellor que unha lista de descuberta. nc -vz 192.168.1.50 9100 en Linux ou Test-NetConnection 192.168.1.50 -Port 9100 en PowerShell diche se o enderezo é alcanzable, antes de que ningún emparellamento a nivel de aplicación entre na discusión.

Escolle a solución para a rede na que estás

Nunha rede de hotel ou de convidados, o illamento é deliberado e non deberías intentar derrotalo. Trata o dispositivo local como inalcanzable, usa o VPN para chegar a un anfitrión que poida imprimir ou compartir, e deixa de tratar a SSID como unha LAN.

Na casa, desactivar o illamento na SSID principal é razoable cando os dispositivos son teus, mentres que a SSID de convidados segue illada. O axuste vive na configuración sen fíos do punto de acceso e pertence alí, non ás excepcións do cortafuegos de cada cliente.

Nunha oficina, supón que o punto de acceso, a VLAN e o cortafuegos do anfitrión son intencionados. Escala cos resultados das probas en lugar de pedir que se desactive o illamento, porque unha rede que separa clientes normalmente protexe algo.

Verifica a aplicación, non só o ping

Un ping correcto demostra a ruta, non o servizo. As impresoras adoitan aceptar 9100 en bruto ou IPP no 631 pero rexeitan a descuberta, e un recurso compartido necesita 445 máis unha resolución de nomes que funcione. Confirma o porto que usa a aplicación e despois volve tentar a tarefa real no dispositivo.

Mantén as dúas capas separadas nas túas notas: que permite a rede Wi-Fi e que encamiña o VPN. A próxima vez que un dispositivo desapareza dunha lista, esa separación dirate onde mirar primeiro.