A volte può essere necessario un bridge wireless per collegare due LAN cablate, oppure per fornire l’accesso alla rete wireless a un dispositivo che ha solo la scheda ethernet.
Finora avevo usato il DWL-G700AP, cui avevo cambiato firmware, tuttavia, dopo il cambio della Fonera con il TP-Link TD-W8970 (di cui parlerò), ho voluto usare la Fonera per questa funzione, in quanto ha OpenWRT e quindi permette di configurarla meglio.
Essenzialmente ci sono queste modalità di bridge:
- Routed: non è esattamente un vero e proprio bridge, in quanto la stazione wireless agisce da router per i client ethernet ad essa collegati, creando una NAT (IPv4). Con IPv6 non so come si comporti. Va bene qualunque access point, non c’è alcuna modifica da fare. La stazione invece deve poter essere configurata per usare la wireless come WAN, ma con firmware avanzati, quali OpenWRT, DD-WRT etc non c’è problema. Questa scelta è ideale se dovete fare cose come navigazione internet etc, non ve bene invece per usare servizi sui computer routati, a meno di port forwarding. Tale modalità è scelta anche dai telefoni Android per il tethering USB della connessione WiFi.
- Bridge stile repeater: è la soluzione da adottare se non potete modificare le opzioni dell’access point o vi mancano quelle più avanzate. Utilizza una modalità analoga a quella dei repeater wireless. La usavo con il DWL-G700AP e volendo anche DD-WRT ci riesce. Non so esattamente come funzioni, forse vengono utilizzate delle estensioni proprietarie dei driver. Come vantaggio ha il fatto che non dovete in alcun modo cambiare le impostazioni dell’access point e che avete un bridge vero e proprio, ovvero ciò che è collegato alla stazione fa parte della stessa LAN del resto. Nel mio caso ho riscontrato anche degli svantaggi: il DWL funzionava a casa mia, invece non andava con il Technicolor di Fastweb, inoltre non si poteva più accedere alla configurazione del dispositivo tramite la wireless e il DHCP mandava il MAC della stazione anziché del client ad essa connesso. Nel caso di DD-WRT c’era un problema simile alla prossima tipologia: non andavano i pacchetti multicast.
- Bridge WDS: il WDS, ovvero Wireless Distribution System, è un’estensione di 802.11, ma non è uno standard. 1 Deve essere abilitata sia sull’access point che sulla stazione, quindi non è detto che possiate utilizzarla. Tuttavia una volta abilitata potete tranquillamente aggiungere le interfacce wireless ai bridge ethernet normali. L’ho sperimentata sia con la Fonera, che con il mio notebook (tutti con chipset Atheros, a dir la verità) e ha funzionato. Questa soluzione ha un problema, che può essere più o meno grosso in base alle vostre esigenze: vengono inoltrati solo i pacchetti TCP, UDP unicast, DHCP e ARP. Questo vuol dire che molti servizi funzioneranno, ma non saranno possibili funzionalità quali auto scoperta dei nodi della rete. Non potrete utilizzare quindi i computer vicini della rete di Windows e altro come mDNS e DNSSD, protocollo di cui io personalmente ho bisogno per la mia stampante Lexmark (per non utilizzare il suo indirizzo IP).
- Soluzione ibrida tra routed e bridged: è la soluzione che ho adottato, la più complicata. In pratica il bridge avviene tra l’interfaccia fisica ethernet e un’interfaccia virtuale di tipo tap, il wireless viene usato solo come canale per mettere in comunicazione la tap della stazione e la tap dell’access point. In poche parole mettete in comunicazione le due reti tramite una VPN. Quindi come requisito ha la possibilità di creare VPN sull’access point e sulla stazione. Se su entrambi c’è OpenWRT o simili non ci sono problemi. Come punti a favore ha il fatto che sarà come avere due reti collegate con il cavo. Come svantaggio ha il fatto che richiede più software, c’è più overhead e tutti gli svantaggi di una VPN con TAP.
Volevo aggiungere alcuni punti sulla mia implementazione (su OpenWRT): per evitare i problemi di instradamenti, ho creato sull’access point un alias all’interfaccia LAN. È una funzionalità intrinseca al kernel Linux: potete creare un sacco di alias a una singola scheda in modo da renderla parte di diverse reti ed è possibile anche con la wireless senza la creazione di un secondo SSID.
Ecco come creare l’alias (su /etc/config/network
):
config interface 'lan_alias' option ifname 'br-lan' option proto 'static' option ipaddr '172.35.100.1' option netmask '255.255.255.0'
Vedrete sotto all’interfaccia lan
anche l’interfaccia lan_alias
(il nome potete deciderlo voi). Se vi interessa metterla in un firewall, mettetela come LAN. Assicuratevi inoltre che DHCP sia disattivo per quest’interfaccia.
Ho poi connesso la wireless con indirizzo IP statico appartenente alla classe 172.35.100.0/24
.
Ho implementato la VPN con OpenVPN, in modalità p2p e senza codifica (tanto c’è già WPA2).
La configurazione è analoga nella stazione e nell’access point. Bisogna aggiungere queste righe al file /etc/config/openvpn
:
config openvpn bridge_wlan option enable 1 option mode p2p option remote 172.35.100.2 # IP della stazione nell'AP e viceversa nella stazione option port 21195 # O qualsiasi, a vostra scelta. Deve essere chiusa dall'esterno option dev tap0 # O un'altra, se la usate già option persist-tun 1 option auth none option cipher none option log /tmp/openvpn.log option verb 2
Infine si aggiunge tap0
al bridge dell’interfaccia LAN, si configura la LAN della stazione con IP statico uguale a quello dell’interfaccia LAN dell’altro router (non dell’alias) e si è a posto.
Una nota su barrier breaker: ho notato che funziona solo un’istanza di OpenVPN alla volta. Ho intenzione di indagare su questo fatto, perché penso sia un bug dovuto alla sostituzione del vecchio init con procd.
Footnotes
- Client Mode Wireless dal wiki di OpenWRT.
^top
2 commenti
Thank you for this clarification. Yes, this is croerct, of course, but of little practical value, as it restricts the use of DD-WRT with both OpenVpn and Chillispot to the mega version which requires routers with more than 4MB flash memory. That means the majority of routers, including the WRT54G and WRT54GL are out, as they have 4MB only. Yes, the Asus WL500g series will work but even the very popular Ubiquiti routers (Nano, Loco, Bullet, etc. will be out of bounds. Only the Pico is then an option. In any case, we have a OpenVPN server still in operation, to cater for such scenarios, but have moved to a vpn network system with much a much lesser footprint, n2n. No, it is not as secure as openVPN, nor does it claim to be. But then again we are using the channel only for remote configuration. There is no actual hotspot traffic going over this connection, so the minimal encryption offered by n2n is just fine.It would be good if DD-WRT could decide to support something like n2n in their smaller builds and yes, when is it moving from the depreciated chillispot to the well maintained coova-chilli?
Thank you for this clarification. Yes, this is correct, of course, but of little practical value, as it restricts the use of DD-WRT with both OpenVpn and Chillispot to the mega version which requires routers with more than 4MB flash memory. That means the majority of routers, including the WRT54G and WRT54GL are out, as they have 4MB only. Yes, the Asus WL500g series will work but even the very popular Ubiquiti routers (Nano, Loco, Bullet, etc. will be out of bounds. Only the Pico is then an option. In any case, we have a OpenVPN server still in operation, to cater for such scenarios, but have moved to a vpn network system with much a much lesser footprint, n2n. No, it is not as secure as openVPN, nor does it claim to be. But then again we are using the channel only for remote configuration. There is no actual hotspot traffic going over this connection, so the minimal encryption offered by n2n is just fine.It would be good if DD-WRT could decide to support something like n2n in their smaller builds and yes, when is it moving from the depreciated chillispot to the well maintained coova-chilli?