Soluzioni bridge Wi-Fi per digital signage e dispositivi remoti

Un bridge Wi-Fi collega dispositivi di rete cablati a Internet o a una rete di livello superiore tramite una connessione Wi-Fi esistente. Dal punto di vista tecnico si tratta di un bridge client: un router si autentica sulla rete Wi-Fi esistente – esattamente come farebbe un laptop o uno smartphone – e mette a disposizione, sul retro, una propria LAN cablata con porte Ethernet. Tutto ciò che si collega a queste porte risulta così indirettamente collegato al Wi-Fi, senza disporre di un proprio modulo Wi-Fi.

Questa modalità operativa si chiama modalità client Wi-Fi o "WiFi as WAN": il router non usa il proprio modulo Wi-Fi per creare una rete propria, ma per collegarsi – come un normale dispositivo terminale – a una rete esterna. La vera sfida sta nella domanda successiva: come diventano visibili, nella rete esterna, i dispositivi dietro al bridge?

La risposta più ovvia sarebbe il bridging trasparente a livello 2 (Layer 2) – il bridge inoltrerebbe allora, per ogni dispositivo collegato, il suo indirizzo MAC (l'identificativo hardware univoco di un dispositivo di rete) invariato sulla rete Wi-Fi, così che ogni dispositivo appaia come un partecipante autonomo. Nella pratica questo fallisce regolarmente: reti esterne e restrittive – Wi-Fi aziendali, reti guest in hotel, fiere o cantieri – raramente sono predisposte ad accettare un numero qualsiasi di indirizzi MAC e richieste IP esterni provenienti da un'unica linea.

L'approccio più robusto è il NAT routing (Network Address Translation): verso l'esterno il bridge si presenta come un unico dispositivo – un indirizzo MAC, un indirizzo IP – e all'interno traduce tra questo unico indirizzo esterno e i tanti indirizzi dei dispositivi nella propria LAN retrostante. Per la rete esterna questo appare come un singolo dispositivo terminale, del tutto anonimo. Proprio questa caratteristica rende i bridge Wi-Fi basati su NAT utilizzabili anche in reti che non autorizzerebbero mai un vero bridging di Layer 2.

Una breve distinzione, perché i termini vengono spesso confusi: un repeater o un sistema mesh si limita a estendere la portata della stessa rete Wi-Fi, senza introdurre una nuova rete o una traduzione di indirizzi, mentre un collegamento a ponte radio (Wi-Fi punto-punto) collega due sedi – ad esempio due edifici – a distanze maggiori. Sono compiti diversi da quello di un bridge client, che rende utilizzabile una rete Wi-Fi esterna per dispositivi cablati.

Ecco come si presentava una richiesta reale che ha dato origine a questa soluzione: un cliente voleva far funzionare, in una sede remota, diversi display digital signage – collegati via cavo a un router Wi-Fi Teltonika usato come bridge verso la rete presente sul posto. La rete sul posto, però, non era una rete propria, bensì una rete Wi-Fi guest o aziendale di terzi, sulla cui configurazione il cliente non aveva alcun accesso. Inoltre i display dovevano poter essere riattivati da remoto tramite Wake-on-LAN – un segnale che riattiva via rete un dispositivo in stato di sospensione – ad esempio per metterli in modalità di risparmio energetico fuori dagli orari di utilizzo e riaccenderli in tempo prima dell'uso successivo.

Le reti guest restrittive comportano tipicamente cinque ostacoli che fanno fallire un bridge semplice:

1. Mancato supporto WDS. Il Wireless Distribution System (WDS) è un metodo che collega più access point in un'unica rete condivisa e trasparente. Molte reti guest non lo supportano affatto – un bridge basato su WDS, in quel caso, non riesce nemmeno ad accedere alla rete.

2. Obbligo di 802.1X. L'802.1X è uno standard di autenticazione in cui ogni dispositivo deve identificarsi presso la rete tramite certificato o credenziali prima di ottenere l'accesso. Le reti Wi-Fi aziendali lo richiedono spesso per ogni singolo partecipante – un ostacolo che un bridge semplice non supera facilmente.

3. Limiti sugli indirizzi MAC. Molte reti ammettono solo un numero limitato di indirizzi MAC per linea. Un bridge che cerca di inoltrare invariati gli indirizzi MAC di tutti i dispositivi collegati viene bloccato rapidamente.

4. Captive portal. Un captive portal è la pagina di accesso che si apre automaticamente in molti hotspot e reti guest al primo tentativo di connessione, e che sblocca il vero accesso alla rete solo dopo una conferma o un login. Un dispositivo senza schermo – come un router o un player digital signage – non può gestire da solo questo portale.

5. Particolarità del DHCP. Il DHCP (Dynamic Host Configuration Protocol) è il servizio che assegna automaticamente un indirizzo IP ai dispositivi in rete. Se più dispositivi dietro al bridge devono ricevere ciascuno un proprio indirizzo dalla rete esterna, serve un relay DHCP aggiuntivo – in una rete con regole firewall sconosciute, spesso un pozzo senza fondo.

Per il cliente questo significava: senza una soluzione ben studiata, ciascuno di questi cinque ostacoli avrebbe potuto bloccare il progetto – e anche se il bridge fosse riuscito ad accedere alla rete, riattivare i display da remoto via Wake-on-LAN avrebbe rappresentato un problema a sé. Ne parliamo nella prossima sezione.

La risposta ai cinque ostacoli è il bridge client basato su NAT descritto nella parte introduttiva: un router Teltonika della serie RUT si autentica in modalità client Wi-Fi sulla rete guest – come un unico dispositivo, con un indirizzo MAC e un indirizzo IP. Il supporto WDS non serve, perché non avviene alcun bridging trasparente. Il login 802.1X lo gestisce il router stesso, per conto di tutti i dispositivi retrostanti. I limiti sugli indirizzi MAC diventano irrilevanti, perché verso l'esterno è comunque visibile un solo indirizzo. Un captive portal può, dove necessario, essere gestito una volta sola in anticipo, e un nuovo login periodico può essere supportato tramite monitoraggio e script – non promettiamo un'automazione al cento per cento per ogni tipo di portale immaginabile, ma offriamo comunque una soluzione verificata per la sede di destinazione specifica. E il relay DHCP diventa superfluo, perché i dispositivi dietro al bridge ricevono i propri indirizzi dalla LAN propria, gestita da Ascend, anziché dalla rete esterna.

Resta la domanda del caso pratico: come si riattivano da remoto i dispositivi dietro un bridge di questo tipo? Il Wake-on-LAN (WOL) funziona, all'origine, in modo estremamente semplice – un cosiddetto magic packet, uno speciale pacchetto broadcast a livello di rete 2, viene inviato nella rete locale e riattiva dallo stato di sospensione il dispositivo corrispondente in base al suo indirizzo MAC. Il problema: un pacchetto broadcast non attraversa da solo i confini di rete – tanto meno il confine NAT di un bridge, nemmeno attraverso un tunnel su Internet. Un magic packet inviato da remoto semplicemente non arriva dietro al bridge, se nessuno lo inietta lì in modo mirato.

Proprio per questo abbiamo sviluppato i nostri script di inoltro WOL: ricevono il comando di riattivazione tramite l'uplink gestito del bridge e inviano poi il magic packet in modo mirato nella LAN locale dietro al bridge – esattamente dove deve arrivare. In questo modo un display o un terminale nella sede remota può essere riattivato da remoto, senza che nessuno sul posto debba fare nulla. Prerequisito lato dispositivo: il Wake-on-LAN deve essere attivato nel BIOS o sulla scheda di rete (NIC) del dispositivo di destinazione – lo verifichiamo insieme prima del rollout.

Ascend fornisce tutto da un unico interlocutore: l'hardware (router Teltonika preconfigurati), il software (gli script di inoltro WOL e la configurazione NAT), la consulenza sul setup più adatto alla sede di destinazione e la configurazione completa – preparata nel data center Ascend prima ancora che il dispositivo veda la sede di utilizzo.

Da numerosi rollout di bridge sono emerse alcune pratiche che si sono dimostrate valide e che si possono applicare a qualsiasi progetto.

Verificare in anticipo il profilo Wi-Fi. È utile comunicarci, possibilmente prima della configurazione, quale autenticazione è richiesta nella sede di destinazione, se esistono limiti sugli indirizzi MAC e se è presente un captive portal. Quanto più precisamente conosciamo la rete di destinazione, tanto più affidabile sarà il funzionamento del bridge fin dal primo giorno.

Testare il Wake-on-LAN prima del rollout. Su un dispositivo pilota è opportuno verificare che il Wake-on-LAN sia attivato nel BIOS o sulla scheda di rete, prima di distribuire più sedi contemporaneamente.

Usare il monitoraggio fin dall'inizio. Un bridge che va offline senza che nessuno se ne accorga è peggio di uno che non funziona fin da subito – perché nessuno nota che manca. La gestione remota è attiva fin dalla messa in servizio.

Una sola linea non basta? Se una singola linea non è sufficiente e serve unire più linee in un'unica banda aggregata, si trovano maggiori informazioni sul nostro Multi-WAN Bonding con Viprinet.