In giro sembra che esistano solo delle schede porcate con driver, parcate anche questi, esclusivamente per Windows XP (sottolineo XP, non altre versioni di windows).

Ho deciso quindi di risolvere una volta per tutte il problema. Inizialmente ho pensato ad un wireless bridge come l’USR 5430, questo attrezzo è un semplice client wifi che fa da ponte fra la porta ethernet del pc e la rete wireless. Purtroppo apparecchi come questi non sono facili da trovare. In realtà alcuni access point permettono di essere configurati come client per svolgere la stessa funzione. Però negli access point economici fra le caratteristiche non è quasi mai elencata questa funzionalità, anche se presente.

Alla fine ho ripiegato sul protocollo WDS per il collegamento wireless di due AP, questo purtroppo richiede una configurazione particolare di entrambi gli AP (sia quello principale che quello collegato alla porta ethernet del mio pc), ma almeno è disponibile in molti access point in circolazione (fra cui il mio). Dato che i problemi non finiscono mai, la standardizzazione del protocollo WDS non è ancora ultimata, quindi è un rischio tentare di farlo funzionare fra due AP di marca diversa. Comunque non è stato un problema trovare un AP identico a quello che avevo. L’ho comprato, collegato e configurato il tutto ed ora ho finito di preoccuparmi dei driver della scheda wifi. Anche windows svista 64bit ora ha il suo accesso ad internet.

Per chi è interessato ecco la configurazione che ho in casa adesso:

• Router ADSL fastweb
• AP principale con switch 4 porte collegato via ethernet al router e ad un serverino domestico
• AP secondario collegato via ethernet al mio PC
• altri pc con scheda wifi

Gli access point sono entrambi Hamlet HNWS254_R. Quello principale è configurato in modalità repeater, cioè opera sia da Access Point che da bridge con il protocollo WDS verso l’AP secondario. L’altro AP opera solo in modalità bridge, cioè comunica con WDS verso l’AP principale e non permette cliente wireless.

Volendo Fastweb ti da anche un indirizzo pubblico ma se lo fa pagare. Visto che l’unica mia esigenza di avere l’indirizzo pubblico è per fare ssh dall’ufficio sulla mia macchina a casa, ho provato a pensare a qualche soluzione alternativa all’ip pubblico. Direi che la cosa più ovvia è che invece di essere la macchina esterna a collegarsi verso quella di casa deve essere quest’ultima ad avviare la connessione verso l’esterno.

Ho trovato alcune soluzioni già pronte per fare circa quello che volevo ma, visto che avevo voglia di divertirmi un po’, non le ho usate e mi sono messo a pensare ad una soluzione più immediata possibile e senza l’utilizzo di programmi specifici.

Per comunicare al mio computer di casa cosa deve fare ho deciso di utilizzare una pagina web, su un server prefissato, della quale posso modificare i contenuti. Il computer di casa ricaricherà regolarmente questa pagina per capire cosa deve fare (in pratica se e a chi collegarsi).

Quello che ho deciso di usare è:

• Qualche semplice script di shell.
• l’utility netcat.

Sul server di casa (H) metto uno script che fa queste operazioni:

1. carica la pagina web prefissata per capire l’host esterno a cui collegarsi
2. se non esiste un host esterno a cui collegarsi, aspetta un po’ e ricomincia da 1
3. apre la connessione sia verso l’host esterno che verso il demone ssh locale e associa queste due connessioni
4. terminate le connessioni ricomincia da 1

Il punto 3 si realizza con netcat attraverso un comando come questo:

nc hostremoto porta -c "nc locahost 22"

In realtà ho avuto un problema con l’opzione -c che faceva i capricci per passare i parametri al secondo comando nc. Ho risolto facedo uno script “tossh” con dento “nc localhost 22″ e richiamato questo script nell’opzione -c.

Su l’host remoto (R) c’è il client ssh che vuole fare la connessione, ma che invece deve riceverla. L’accoppiamento fra connessione entrante (dal computer di casa) e uscente (dal client ssh) la realizziamo di nuovo attraverso netcat:

nc -lp portalocale -c "nc -lp porta" &
ssh -p portalocale -u utente localhost

dove porta è lo stesso numero di porta utilizzato nel comando sul computer di casa. Per come ho strutturato il primo comando bisogna che queste istruzioni vengano eseguite entrambe prima che il server di casa tenti di collegarsi.

Ora ho un problema che mi impedisce di determinare quando la sessione ssh è terminata. I comandi netcat non chiudono mai la connessione TCP ma terminano solo quando è l’host remoto a chiuderla. Terminare il netcat su (R) non è un problema (in realtà invertendo l’utilizzo di porta e portalocale i comandi terminano da soli). Il problema è su (H) dove rimane la connessione TCP fra un netcat e il demone ssh.

Se qualcuno vuole aiutarmi a risolvere il problemuccio si faccia avanti …

Lo script ancora incompleto che gira su H è questo:

#!/bin/sh
WEBS='www.xyz.it'
WEBA='path/to/test'
ADDR="http://$WEBS/$WEBA"
PARAM=`echo GET $ADDR | nc $WEBS 80`
while [ "$PARAM" == "" ]
do
   sleep 5
   PARAM=`echo GET $ADDR | nc $WEBS 80`
done
nc -ve "tossh" $PARAM


La soluzione è piuttosto specifica per la mia situazione e non va bene per realizzare un bridge in generale fra una lan via cavo e una cella wireless.

Il problema che devo risolvere è di far raggiungere agli host wireless il modem router sulla lan via cavo. Il server-bridge che ho realizzato non riesce ad operare in quanto la sua scheda wi-fi non cattura il traffico wireless non destinato esplicitamente a se.

Visto che sul lato via cavo è presente una sola macchina (il router), ho pensato di realizzare un NAT degli indirizzi MAC. Quando una macchina sul lato wireless manda una richiesta ARP per ottenere il MAC address del router, il server-bridge la intercetta e risponde con il MAC address della propria interfaccia WiFi. In questo modo gli host wireless, senza saperlo, invieranno il traffico per il firewall al server-bridge.

Il server-bridge dovrà avere delle altre regole per fare in modo di inoltrare al router i pacchetti ip che gli arrivano ma i cui indirizzi ip di destinazione non gli appartengono.

Per realizzare tutto questo ho utilizzato ebtables, l’equivalente di iptables che lavora a livello 2 anziché a livello 3.

Ecco le regole che ho usato:

Come si intuisce questo meccanismo non può essere generico perché bisogna scrivere esplicitamente delle regole per ogni macchina presente sulla LAN via cavo. Di buono questa soluzione ha che può essere implementata anche con la più schifosa delle schede wifi purché funzioni con linux.

Ho indagato la questione ed ho concluso che il bridge non ha nulla che non va, semplicemente l’interfaccia wireless non lavora in modalità promiscua, cioè riceve i frame ethernet indirizzati a lei o in multicast/broadcast ma non intercetta quelli inviati ad indirizzi MAC di altri host.

A quanto pare non è una cosa insolita che le interfaccie wireless non possano funzionare in modalità promiscua.

Ho elaborato una soluzione che permette di risolvere il problema, l’ho già provata e funziona, la sto utilizzando proprio in questo momento. Vi scrivo dal mio pc che via wireless comunica con il server a 20 cm di distanza  a sua volta collegato con un cavo allo switch e poi al router ADSL.

Rimando al prossimo post la descrizione nei dettagli e le considerazioni.

Purtroppo le prime prove non hanno dato esito positivo.

Realizzare il bridge è stato piuttosto facile. Dopo aver ricompilato il kernel per abilitare il bridging, ho installato le bridge-utils e con i seguenti comanti ho creato il bridge e inserito le 2 interfacce:

  brctl addbr br0

  brctl addif eth0

  brctl addif eth1 

Infine ho configurato un indirizzo ip per la nuova interfaccia di rete br0, visto che non posso più utilizzare  direttamente eth0 e eth1.

Tutto è pronto, da una verifica il server bridge riesce a comunicare sia sugli host collegati attraverso eth0, sia su quelli collegati atraverso eth1 (la rete wireless). Purtroppo gli host su un lato del bridge non comunicano con quelli sull’altro lato.

Il bridge non funziona, dovrò indagare il perché. Intanto ho deciso di spostare le mie prove in ambiente virtuale usando vmware, visto che sono impazzito ad attaccare e staccare cavi di rete e monitor.

I precedenti post:

• primo post
• secondo post

La questione ora è scegliere l’architettura logica della rete e quindi la configurazione degli host.

Mi vengono in mente 3 possibili scenari:

1. Modem-router ADSL configurato come router e Home Server a sua volta configurato come router.

   Il primo sarebbe configurato più o meno come quando era l’unico router, assumerebbe quindi l’indirizzo IP pubblico assegnato dal provider internet per l’ADSL gestendo gli indirizzi privati della LAN interna facendo una traslazione degli indirizzi e un Masquerading, la differenza sta nel fatto che bisogna comunicargli una route statica per dirgli che tutto ciò è destinato alle macchine interne deve essere fatto passare dall’Home Server.

   L’Home Server fa da router ed è il default gateway per la LAN domestica e sa che tutto il traffico in uscita deve essere destinato al modem-router ADSL.

2. Modem-router ADSL configurato come modem e Home Server come router.

   In questo caso è l’Home Server che acquisisce l’indirizzo IP pubblico e si occupa di fare la traslazione degli indirizzi verso la LAN interna. Anche in questo caso l’Home Server è il default gateway per i computer di casa.

3. Modem-router ADSL configurato come router e Home Server come bridge.

   In questo caso la configurazione del modem-router ADSL rimarrebbe identica a quella attuale, cioè di quando opera collegato allo switch ethernet o ad un access point.

   L’Home Server invece, sfruttando le funzionalità di bridging di linux, operebbe come una specie di hub o switch fra l’interfaccia ethernet e quella wi-fi. Gli host della LAN comunicherebbero direttamente con il modem-router ADSL senza rendersi conto (a livello IP) di passare attraverso l’Home Server.

In realtà non so se l’ultimo scenario sia realizzabile, cercherò di scoprirlo. Il più semplice da realizzare è probabilmente il primo mentre quello logicamente più pulito è il secondo ma l’ultimo presenta degli evidenti vantaggi su tutti gli altri. Il fattore più importante è che non necessita di riconfigurazione del modem-router ADSL e degli host. L’unica configurazione che devo fare è quella dell’Home Server. Conseguenza di questo è che in qualsiasi momento posso decidere di staccare l’Home Server e collegare i computer con uno switch senza dover riconfigurare il modem-router. Proprio per questo motivo cercherò di realizzare, capendo prima se è possibile, l’ultimo scenario.

Nel prossimo post inizierò a raccontare qualche dettaglio implementativo.

Al di là dei motivi per cui ancora non abbiamo comprato un nuovo AP, mi sono chiesto se posso utilizzare la rete wireless facendone a meno.

Uno dei 4 computer è un piccolo server linux che avevo realizzato con vecchi componenti per metterci sopra alcuni piccoli servizi ad uso privato. La mia idea è quella di utilizzare questo server, che comunque rimarrebbe acceso tutto il giorno, al posto dell’access point.

Quello che vorrei provare a fare non è trasformare il server in AP, per fare questo è necessario che la modalità Master sia supportata sia dalla scheda wireless che dai driver, e spesso non lo è. Vorrei invece sfruttale la modalità Ad-Hoc che sicuramente è supportata da tutte le schede wireless.

In realtà, almeno sulla carta, la mia sceda wi-fi (chipset ZyDAS 1211) e i suoi driver per linux supportano la modalità Master, magari in futuro tenterò anche la realizzazione di un access point.

Nella modalità Ad-Hoc la rete è formata da una singola cella dove ogni host wireless comunica direttamente con gli altri, senza passare da un access point. A casa mia avevo un solo AP e quindi una sola cella, inoltre si trovava al margine dell’area da coprire, per cui non rischierei nemmeno di ridurre l’area di copertura togliendo l’AP dal centro della cella. Direi che la modalità Ad-Hoc va benissimo per le mie esigenze.

Rimane da decidere come far funzionare il server, se come router della rete domestica o in altro modo. Nei prossimi post svilupperò la questione.