Aislamiento de clientes Wi-Fi frente al acceso local por VPN: qué te bloquea

Pon dos teléfonos en la misma SSID de invitados y ninguno ve al otro, pero ambos llegan a internet. Añade un cliente VPN en uno de ellos y la impresora a tres metros sigue invisible mientras un servidor en otro continente responde a los ping. Nada está roto en el túnel; intervienen dos decisiones de acceso distintas y solo una tiene que ver con el enrutamiento. El punto de acceso decide si los clientes inalámbricos pueden hablar entre sí, y el cliente VPN decide qué destinos salen por el túnel. Confundir esas dos decisiones produce horas de cambios de configuración inútiles.

Las dos puertas son independientes

El aislamiento de clientes es una decisión de conmutación. El punto de acceso acepta una trama de una estación asociada, mira el destino, advierte que el destino es otra estación del mismo puente y la descarta. La dirección IP de la estación es irrelevante para esa decisión, y el VPN también.

El enrutamiento es otra decisión, tomada en el cliente. La tabla de rutas del VPN decide si un paquete para 192.168.1.50 entra en el túnel o sale por la interfaz Wi-Fi. Si el paquete sale por Wi-Fi y el punto de acceso aísla a los clientes, muere en el punto de acceso. Si el paquete entra en el túnel, el punto de acceso nunca ve el destino original y no puede aislar nada.

Qué bloquea el aislamiento en un punto de acceso típico

Los fabricantes lo distribuyen con varios nombres: aislamiento de clientes, aislamiento de AP, aislamiento de estaciones o una red de invitados que lo implica. En OpenWrt la opción por interfaz es isolate dentro de la configuración inalámbrica, como se describe en la documentación inalámbrica, y una SSID de invitados suele recibir su propio puente y su zona de cortafuegos. El efecto es que las tramas unicast entre clientes no se puentean, así que un ping, una conexión SMB o un trabajo de impresión a un vecino falla aunque ambos dispositivos muestren señal completa.

Los protocolos de descubrimiento sufren primero y de forma más visible. mDNS para impresoras y dispositivos multimedia va por multicast a 224.0.0.251, SSDP usa 239.255.255.250, y si esas tramas cruzan el puente depende del fabricante y de si está activada la conversión de multicast a unicast. Un dispositivo que falta en una lista es una evidencia más débil que una conexión directa fallida a una dirección conocida.

Qué cambia el VPN y qué no puede cambiar

Un túnel completo toma la ruta por defecto, así que las subredes locales solo se alcanzan si el cliente mantiene una ruta más específica para ellas. Los túneles divididos hacen lo contrario y preservan el acceso local por diseño. Ninguno de los dos ajustes puede hacer que un punto de acceso aislante reenvíe una trama entre dos de sus clientes, por eso permitir el tráfico local en el cliente VPN es necesario pero no suficiente.

El caso inverso es igual de común. El punto de acceso permite el tráfico entre pares, el cliente VPN excluye la subred local del túnel y la impresora sigue sin responder porque el cortafuegos del anfitrión trata la red Wi-Fi como pública. Tres capas, tres valores por defecto distintos, y solo la ruta es visible en la mayoría de los registros del VPN.

Averigua qué puerta está cerrada

Empieza con una prueba que saque el VPN de la ecuación: conecta dos dispositivos corrientes a la misma SSID e intenta llegar de uno a otro por dirección. Si falla, el punto de acceso aísla y ningún ajuste del VPN lo arreglará. Si funciona, pasa al cliente y ejecuta ip route get 192.168.1.50 en Linux o Find-NetRoute -RemoteIPAddress 192.168.1.50 en Windows; la salida nombra la interfaz que usará el paquete.

Cuando la ruta apunta a la interfaz Wi-Fi, el paquete sale sin cifrar y la pregunta pasa a ser si el punto de acceso y el cortafuegos del anfitrión lo permiten. Cuando la ruta apunta al túnel, el destino se envía al servidor VPN, lo cual es erróneo para un dispositivo en la misma LAN y normalmente significa que la lista permitida del túnel es demasiado amplia.

Una conexión directa al puerto de la impresora es una prueba mejor que una lista de descubrimiento. nc -vz 192.168.1.50 9100 en Linux o Test-NetConnection 192.168.1.50 -Port 9100 en PowerShell te dice si la dirección es alcanzable, antes de que ningún emparejamiento a nivel de aplicación entre en la discusión.

Elige la solución para la red en la que estás

En una red de hotel o de invitados, el aislamiento es deliberado y no deberías intentar derrotarlo. Trata el dispositivo local como inalcanzable, usa el VPN para llegar a un anfitrión que pueda imprimir o compartir, y deja de tratar la SSID como una LAN.

En casa, desactivar el aislamiento en la SSID principal es razonable cuando los dispositivos son tuyos, mientras que la SSID de invitados sigue aislada. El ajuste vive en la configuración inalámbrica del punto de acceso y pertenece allí, no a las excepciones del cortafuegos de cada cliente.

En una oficina, supón que el punto de acceso, la VLAN y el cortafuegos del anfitrión son intencionados. Escala con los resultados de las pruebas en lugar de pedir que se desactive el aislamiento, porque una red que separa clientes normalmente protege algo.

Verifica la aplicación, no solo el ping

Un ping correcto demuestra la ruta, no el servicio. Las impresoras suelen aceptar 9100 en bruto o IPP en 631 pero rechazan el descubrimiento, y un recurso compartido necesita 445 más una resolución de nombres que funcione. Confirma el puerto que usa la aplicación y luego reintenta la tarea real en el dispositivo.

Mantén las dos capas separadas en tus notas: qué permite la red Wi-Fi y qué enruta el VPN. La próxima vez que un dispositivo desaparezca de una lista, esa separación te dirá dónde mirar primero.