Soluciones de puente Wi-Fi para digital signage y dispositivos remotos

Un puente Wi-Fi conecta dispositivos de red cableados a internet o a una red de nivel superior a través de una conexión Wi-Fi existente. Técnicamente se trata de un puente cliente (client bridge): un router se conecta a la red Wi-Fi existente —tal como lo haría un portátil o un smartphone— y ofrece en su parte posterior su propia LAN cableada con puertos Ethernet. Todo lo que conecte a estos puertos queda así conectado indirectamente a la red Wi-Fi, sin necesidad de disponer de hardware Wi-Fi propio.

Este modo de funcionamiento se denomina modo cliente Wi-Fi o «WiFi as WAN»: el router no utiliza su módulo Wi-Fi para crear su propia red, sino para conectarse a una red ajena, igual que lo haría un dispositivo final corriente. El verdadero reto está en la siguiente cuestión: ¿cómo se hacen visibles los dispositivos situados detrás del puente dentro de la red ajena?

La respuesta más obvia sería el bridging transparente en la capa 2 (Layer 2): el puente reenviaría entonces, sin modificarla, la dirección MAC propia de cada dispositivo conectado (el identificador de hardware único de un dispositivo de red) hacia la red Wi-Fi, de modo que cada dispositivo aparecería como un participante independiente. En la práctica, esto falla con regularidad: las redes ajenas y restrictivas —Wi-Fi corporativas, redes de invitados en hoteles, pabellones u obras— rara vez están diseñadas para aceptar un número arbitrario de direcciones MAC ajenas y solicitudes IP procedentes de una única conexión.

El camino más robusto es el enrutamiento NAT (Network Address Translation): el puente se presenta hacia el exterior como un único dispositivo —una dirección MAC, una dirección IP— y traduce internamente entre esta única dirección externa y las numerosas direcciones de los dispositivos de su propia LAN situada detrás. Para la red ajena, esto tiene el aspecto de un único dispositivo final discreto. Precisamente esta característica hace que los puentes Wi-Fi basados en NAT puedan utilizarse también en redes que nunca autorizarían un bridging de capa 2 real.

Una breve aclaración, porque los términos se confunden a menudo: un repetidor o un sistema mesh se limitan a ampliar el alcance de la misma red Wi-Fi, sin introducir una red nueva ni una traducción de direcciones, y un radioenlace (Wi-Fi punto a punto) conecta dos ubicaciones —por ejemplo, dos edificios— a mayor distancia. Se trata de dos tareas distintas de la que realiza un puente cliente, que hace utilizable una red Wi-Fi ajena para dispositivos cableados.

Así era una petición real que dio el pistoletazo de salida a esta solución: un cliente quería operar varias pantallas de digital signage en una ubicación remota, conectadas por cable a un router Wi-Fi Teltonika que hacía de puente hacia la red existente in situ. Sin embargo, la red del lugar no era propia, sino una red Wi-Fi de invitados o corporativa ajena, sobre cuya configuración el cliente no tenía ningún acceso. Además, las pantallas debían poder activarse de forma remota mediante Wake-on-LAN —una señal que reactiva por red un dispositivo en reposo—, por ejemplo para enviarlas a un modo de ahorro de energía fuera del horario de uso y devolverlas a pleno funcionamiento a tiempo para el siguiente uso.

Las redes de invitados restrictivas suelen presentar cinco obstáculos que hacen fracasar a un puente sencillo:

1. Falta de soporte WDS. El Wireless Distribution System (WDS) es un procedimiento que permite conectar varios puntos de acceso en una única red transparente y común. Muchas redes de invitados no lo admiten en absoluto: un puente que dependa de WDS ni siquiera llega a entrar en esa red.

2. 802.1X obligatorio. 802.1X es un estándar de autenticación en el que cada dispositivo debe identificarse ante la red mediante certificado o credenciales antes de obtener acceso. Las redes Wi-Fi corporativas lo exigen con frecuencia para cada participante individual: un obstáculo que un puente sencillo no supera sin más.

3. Restricciones de direcciones MAC. Muchas redes solo permiten un número limitado de direcciones MAC por conexión. Un puente que intenta reenviar sin cambios las direcciones MAC de todos los dispositivos conectados queda bloqueado rápidamente.

4. Captive portals. Un captive portal es la página de inicio de sesión que se abre automáticamente en muchos hotspots y redes de invitados en el primer intento de conexión, y que solo desbloquea el acceso real a la red tras una confirmación o un inicio de sesión. Un dispositivo sin pantalla —como un router o un reproductor de digital signage— no puede manejar este portal por sí mismo.

5. Particularidades del DHCP. DHCP (Dynamic Host Configuration Protocol) es el servicio que asigna automáticamente una dirección IP a los dispositivos de la red. Si varios dispositivos situados detrás del puente deben recibir cada uno su propia dirección desde la red ajena, se necesita un DHCP relaying adicional, algo que en una red con reglas de firewall desconocidas suele ser un pozo sin fondo.

Para el cliente, esto significaba lo siguiente: sin una solución bien pensada, cualquiera de estos cinco obstáculos podría haber paralizado el proyecto, y aunque el puente hubiera logrado entrar en la red, activar las pantallas de forma remota mediante Wake-on-LAN habría representado un problema propio. Más sobre esto en el siguiente apartado.

La respuesta a los cinco obstáculos es el puente cliente basado en NAT descrito en el apartado de fundamentos anterior: un router Teltonika de la serie RUT se conecta a la red de invitados en modo cliente Wi-Fi, como un único dispositivo, con una dirección MAC y una dirección IP. No se necesita soporte WDS, porque no se produce ningún bridging transparente. El propio router se encarga del inicio de sesión 802.1X, en representación de todos los dispositivos situados detrás. Las restricciones de MAC no surten efecto, porque de todos modos solo es visible una dirección hacia el exterior. Un captive portal puede, cuando es necesario, resolverse una sola vez de antemano, y un nuevo inicio de sesión periódico puede automatizarse mediante monitorización y scripts —no prometemos una automatización del cien por cien para cualquier tipo de portal imaginable, pero sí una solución verificada para la ubicación objetivo concreta—. Y el DHCP relaying resulta innecesario, porque los dispositivos situados detrás del puente obtienen sus direcciones de la LAN propia gestionada por Ascend, en lugar de la red ajena.

Queda la pregunta del caso práctico: ¿cómo se despiertan de forma remota los dispositivos situados detrás de un puente de este tipo? Wake-on-LAN (WOL) funciona, en su origen, de una forma sumamente sencilla: se envía a la red local un magic packet, un paquete de difusión (broadcast) especial de la capa de red 2, que despierta del reposo al dispositivo correspondiente a partir de su dirección MAC. El problema: un paquete de difusión no cruza por sí solo los límites de red, y mucho menos el límite NAT de un puente, ni siquiera a través de un túnel hacia internet. Un magic packet enviado de forma remota simplemente no llega detrás del puente si nadie lo introduce ahí de forma específica.

Para resolver justamente esto hemos desarrollado nuestros propios scripts de reenvío de WOL: reciben el comando de activación a través del uplink gestionado del puente y, a continuación, envían el magic packet de forma específica a la LAN local situada detrás del puente, es decir, adonde realmente debe llegar. Así puede activarse de forma remota una pantalla o un terminal en la ubicación remota, sin que nadie tenga que hacer nada in situ. Requisito por parte del dispositivo: Wake-on-LAN debe estar activado en la BIOS o en el adaptador de red (NIC) del dispositivo de destino; esto lo comprobamos junto con usted antes del despliegue.

Ascend se lo ofrece todo desde un único proveedor: el hardware (routers Teltonika preconfigurados), el software (los scripts de reenvío de WOL y la configuración NAT), el asesoramiento sobre la configuración adecuada para su ubicación objetivo y la configuración completa, preparada en el centro de datos de Ascend antes de que el dispositivo llegue siquiera al lugar de despliegue.

De numerosos despliegues de puentes se han consolidado algunas prácticas que pueden aplicarse a cualquier proyecto.

Revisar el perfil Wi-Fi de antemano. Infórmenos, a ser posible antes de la configuración, de qué autenticación se exige en la ubicación objetivo, si existen restricciones de MAC y si hay un captive portal. Cuanto mejor conozcamos la red de destino, con mayor fiabilidad funcionará el puente desde el primer día.

Probar Wake-on-LAN antes del despliegue. Compruebe en un dispositivo piloto que Wake-on-LAN está activado en la BIOS o en el adaptador de red antes de desplegar varias ubicaciones a la vez.

Utilizar la monitorización desde el principio. Un puente que se queda sin conexión sin que nadie lo note es peor que uno que nunca ha funcionado, porque nadie percibe que falta. La gestión remota está activa desde la puesta en marcha.

¿No basta con una sola línea? Si una única conexión no es suficiente y desea combinar varias líneas en un ancho de banda agrupado, lea más sobre nuestro Multi-WAN Bonding con Viprinet.