 |
|
5. Generalità sulla configurazione di una rete Wireless.
5.1 Passi fondamentali
Una volta che hai recuperato il materiale e hai ricompilato tutto il necessario sei pronto per seguire i 3 passi per la configurazione di una rete Wireless.
- Configurazione di basso livello: é necessario far riconoscere al kernel la nostra scheda Wireless (cose del tipo ioport, interrupts, dma...): devi cercare un qualche tipo di messaggio, sui file di log, che ti confermi l'avvenuto riconoscimento e la relativa configurazione.
- Configurazione a livello Data-link: per ogni particolare scheda Wireless esiste un'utility in grado di settare i tipici valori Wireless data-link. Ad esempio Proxim Symphony utilizza "rl2cfg" mentre nelle schede pcmcia i settaggi sono presenti nei files di configurazione del supporto pcmcia. Devi settare tutte le tue schede Wireless in modo coerente, altrimenti non potranno dialogare.
- Settaggi IP. A questo dovresti essere in grado di utilizzare i comandi ifconfig e route per cambiare i settaggi IP.
- Trucchetti per migliorare le performance ed evitare conflitti. Adesso la tua rete fondamentalmente funziona: puoi aggiustare alcuni settaggi riguardanti proxy arp, icmp echo redirect, bridging, cambio dei canali e così via per ottimizzare la configurazione ed evitare conflitti uccidi-banda!
N.B.: passi 1, 2 e 3 corrispondono ai livelli 1, 2 and 3 dello standard ISO/OSI, mentre il passo 4 é un addendum per risolvere alcune problematiche, tra cui quelle generate dall'adozione della maschera 255.255.255.255. Infatti la maschera 32 bit viola lo standard TCP/IP forzando una rete ad usare lo stesso indirizzo per il broadcast e per l'host, mentre l'indirizzo di rete non esiste.
Qualcuno potrebbe criticare questo punto di vista, ma se seguissimo alla lettera lo standard inizieremmo a perdere una marea di indirizzi IP (sempre più preziosi); per ogni sottorete 2 indirizzi sono riservati (network and broadcast) e comunque, seguendo lo standard, non si avrebbe certamente la necessaria flessibilità sull'assegnazione di indirizzi IP alle interfacce richiesta dai sistemi Wireless (allocazione di tipo geografica!). Per maggiori informazioni vedi Appendix A.
Si può infine notare come il passo 2 non sia presente nelle schede Wired, in quanto non vi sono particolari settaggi da operare.
5.2 Configurazione di basso livello
E' il classico problema dell'amministratore del sistema: far riconoscere al PC il proprio hardware.
Le schede Wireless sono più complesse sotto questo punto di vista, perché molte hanno il plug Pcmcia e quindi prima di tutto é necessario "far vedere" al kernel il proprio adattare Pcmcia, in seguito sarà possibile provare ad installare il driver specifico per la scheda Wireless Pcmcia.
Quindi nelle configurazioni Pcmcia é necessario:
- installare i sorgenti del kernel, scaricandoli da http://www.kernel.org e scompattandoli su /usr/src/linux (vedi comandi tar and gzip)
- installare i sorgenti per il supporto pcmcia, da ftp://projects.sourceforge.net/pub/pcmcia-cs e scompattarli su /usr/src/pcmcia (vedi sempre utilities tar and gzip)
- configurare e ricompilare il kernel: leggi attentamente il README presente nella directory del Kernel (/usr/src/linux)
- configurare e ricompilare i sorgenti pcmcia: sotto /usr/src/pcmcia usare configure eppoi make. Assicurati che ci sia il driver che ti interessa, altrimenti dovrai installarlo seguendo le relative istruzioni (di solito basta scompattare con "tar zxvf driver.tgz" il driver pcmcia direttamente sotto la directory pcmcia). Dopodiché digita "make all" per compilare. Alla fine digita "make install".
- Dopo aver installato correttamente i drivers pcmcia potrai trovare i relativi file di configurazione sotto la directory /etc/pcmcia .
mentre per la configurazione senza Pcmcia:
- Se il driver della tua scheda non é presente (in effetti non lo é mai!) nel Kernel, dovrai scaricarlo, installarlo e ricompilarlo in una nuova directory.
Una volta che conosci il nome del driver é il momento di caricarlo: nel caso di Pcmcia ci penserà il demone relativo (attivabile tramite /etc/rc.d/init.d/pcmcia start per le distribuzioni RedHat), mentre per le altre schede basterà dare "modprobe module_name options". Tra le opzioni vi sono ioport, irq e i settaggi data-link relativi al driver Wireless (vedi Par 5.3). Ad ogni modo ci sono una serie di strumenti molto comodi per controllare il riconoscimento a basso livello del driver:
- "tail /var/log/messages" che mostra le ultime informazioni scritte sul log di sistema (syslog)
- "dmesg" for ulteriori info sul log
- /proc directory: files ioports, devices, irq e sottodirectories specifiche per il driver.
5.3 Configurazione a livello Data-link
Cosa significa?
Le reti classiche hanno bisogno solo di essere fisicamente connesse le une con le altre e di avere i giusti settaggi TCP/IP. Al contrario le reti Wireless networks richiedono settaggi Data-link che indicanti:
- A che tipo di rete Wireless appartengo? (Adhoc o Infrastructure)
- Che canale devo usare?
- A che sottorete (BSSID) appartengo e qual'é il mio ESSID?
- La mia comunicazione é protetta da qualche algoritmo crittografico? Qual'è la chiave?
Ci sono quindi una serie di settaggi da configurare, la ragione di ciò deriva dall'architettura Wireless: potrebbe esserci qualcuno, nel raggio di copertura Wireless, che potrebbe intercettare dei pacchetti e usare servizi relativi ad un altra rete wireless solamente puntanto la propria antenna nella giusta direzione e settando gli opportuni parametri TCP/IP.
Inoltre più reti Wireless (magari ognuna relativa ad un piano di un edificio) potrebbero interferire una con l'altra.
Ecco allora:
- Opzioni a load-time module: "modprobe ray_cs essid='LINUX'" per esempio o
- Utilities a run-time driver: "rl2cfg eth1 master".
5.4 Settaggi IP + trucchetti
Questo é il terzo problema che dobbiamo affrontare. Qui i problemi arrivano quando ci si evolve verso una rete più grossa.
Ricordati che la rete Wireless non ti stressa se non sei tu a stressarla!
Una configurazione semplice
Tutti gli hosts si "vedono"
A - - - - - C
\ /
| \ / |
/\
| / \ |
/ \
B - - - - - D
Una configurazione come questa é molto semplice e non richiede particolari attenzioni (almeno a livello IP): hai soltanto bisogno di assegnare un indirizzo IP ad ogni host e una maschera generale coerente con tutte le altre macchine.
Una configurazione più complessa
A non vede B direttamente
A <- - - -
NO\ |
TALK\ C
\ |
B <- - - -
In questo caso A e B possono comunicare tra loro soltanto tramite C.
Se la rete é in infrastructure mode e C é l'Access Point allora tutto ok. In Adhoc mode é invece designare un host per essere un "master" (so che il termine non é molto formale, ma l'importante é capirsi!), un host che sia cioé in grado di creare un BSS e a cui gli altri possano collegarsi specificando il relativo BSSID.
In questo caso la connettività globale viene raggiunta a livello IP: A e B usando la stessa interfaccia di C, quindi se provi anche solo a fare ping da A verso B riceverai una marea di pacchetti ICMP REDIRECT da C, con cui C t'informa che la destinazione é già sulla rete da cui proviene la richiesta.
Soluzione: digita "echo 0 > /proc/sys/net/ipv4/conf/ethx/send_redirects" (dove ethx é l'interfaccia su C verso A e B) per annullare il problema.
Un altro problema: che maschera assegnare ad A, B e C? Se si da una maschera ad A che includa B non funziona nulla, perché A non utilizzerà C come gateway ma farà la richiesta ARP con indirizzo MAC destinazione sconosciuto.
Potresti dire: uso il proxy arp! Peccato che il proxy arp serva per rispondere al sorgente solamente nel caso in cui il destinatario appartenga ad una diversa interfaccia rispetto al sorgente e questo non é il caso.
Conviene quindi settare la più piccola maschera possibile (Win9x permette 255.255.255.254, WinNT invece 255.255.255.248), e devi essere sicuro che A and B non appartengano alla stessa sottorete.
Esempi:
- IP(A) = x.y.z.2/31, IP(B) = x.y.z.3/31. Così non va perché A chiede B nella sua sottorete (ARP request) e C non può rispondere perché, per lui, A e B appartengono alla stessa interfaccia (quindi niente proxy arp).
- IP(A) = x.y.z.1/31, IP(B)= x.y.z.2/31. Adesso si, perché A chiede a C (A manda i suoi pacchetti a B usando l'indirizzo MAC di C) per arrivare a B.
In generale, con una maschera 255.255.255.254, il giochetto funziona tra 2 IP che NON differiscono soltanto per l'ultimo bit.
Mi rendo conto che tutto ciò é una forzatura del TCP/IP, ma é l'unico metodo per ottenere un elevato livello di flessibilità.
Nota: Usando un Access Point (rete in Infrastructure mode) non esiste più il problema dei pacchetti ICMP REDIRECT perché il problema viene già risolto a livello data-link (praticamente tutti gli Access Point sono dei bridge...). Ma gli Access Points sono costosi (qualche milione o più) ed é più economico usare un P133, 32MB Ram per forwardare i pacchetti, anche con 2 o più schede di rete.
Accesso ad Internet
A - - - - - C - - Internet
\ /
| \ / |
/\
| / \ |
/ \
B - - - - - D
Ci sono una serie di possibilità:
- C'é un unico indirizzo IP pubblico. Devi soltanto settare indirizzi IP privati (192.168.x.y per esempio) sulla rete Wireless e abilitare, su C, il forwarding e il masquering (NAT). A, B e D utilizzeranno C come default Gateway.
- Possiedi una maschera pubblica (classe) visibile da Internet e C é il tuo default GW verso Internet per la tua rete. Hai bisogno, come prima, di abilitare il forwarding su C e di settare default GW su A, B ed D facendolo puntare su C.
- Possiedi una maschera pubblica (classe) visibile da Internet e C NON é il tuo default GW verso Internet, Hai 2 possibili soluzioni: modificare il tuo default GW facendolo puntare a C per la tua rete. Simmetricamente C punterà sul tuo default GW per andare su Internet. Altrimenti potresti abilitare il proxy arp su C (echo 1 > /proc/sys/net/ipv4/conf/ethx/proxy_arp dove ethx é l'interfaccia verso il default GW)e settare default GW su C per puntare sul default GW per andare su Internet. Il Proxy arp é una forzatura TCP/IP ma lavora bene.
Reti miste: Wired e Wireless
Internet
\
\ E
\ /
\ / Wireless
A - - - - - C - - F
\ / \
| \ / | \
Wired /\ G
| / \ |
/ \
B - - - - - D
Adesso C unisce 2 reti: a destra Wireless e a sinistra Wired.
In aggiunta puoi avere l'accesso ad Internet ed in totale hai bisogno di 3 schede di rete su C.
Che indirizzi devi assegnare alle macchine? 2 soluzioni possibili:
- Dividere la rete in 2 sottoreti: ad esempio 192.168.1.0/24 e 192.168.2.0/24. Questa soluzione é molto veloce ma non é assolutamente scalabile né flessibile (almeno in ambito Wireless), perché se utilizzi indirizzi Internet pubblici rischi di perderne una marea.
- Abilitare il proxy arp su C per tutte e 2 le interfacce. I parametri di rete sono, in questo caso, gli stessi (net address and netmask) per Wireless e Wired, ma con il proxy-arp abilitato é possbile scegliere quali indirizzi IP sono su Wired e quali su Wireless.
Esaminiamo ora la soluzione 2
Ad esempio considera di avere una sottorete pubblica su Internet del tipo x.y.z.0/24.
Le interfacce sono:
- ifconfig eth0 x.y.z.C netmask 255.255.255.255 (Wired)
- ifconfig eth1 x.y.z.C netmask 255.255.255.255 (Wireless)
- ifconfig eth2 x.y.z.C netmask 255.255.255.255 (to Internet)
Le routes statiche su eth2:
- route add IPGW dev eth2
- route add default gw IPGW
Queste route servono per indirizzare tutto Internet verso il nostra Default GW: come puoi notare é necessario prima dire a Linux che il router é sull'interfaccia eth2, poi mandare la default route verso di esso.
Routes statiche su eth0:
- route add x.y.z.A dev eth0
- route add x.y.z.B dev eth0
- route add x.y.z.D dev eth0
Hosts A,B e D sulla rete Wired
Routes statiche su eth1:
- route add x.y.z.E dev eth1
- route add x.y.z.F dev eth1
- route add x.y.z.G dev eth1
Hosts E,F e G sulla rete Wireless.
Nota che la flessibilità é molto elevata, però devi settare manualmente ogni hosts (al limite puoi destinare un micro-classe su un'interfaccia).
Next Previous Contents
Hosting by: hurra.com
Generated: 2007-01-26 17:56:19