ZeroShell    Forum
   Feed Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Zeroshell on LinkedIn LinkedIn       Facebook      Twitter ZeroTruth una interfaccia per il Captive Portal

      Cosa è?
      Screenshots
      Licenza
      Annunci
      Mailing List
      Forum
      English Forum
      Documentazione
      FAQ
      Hardware
      Download
      Update On-line
      Kerberos Tutorial  
      Note Legali
      Contattami


  Più in dettaglio:
      Hotspot Router
      Accounting
      Shibboleth SP
      Grafici e Prestazioni
      Net Balancer
      Router UMTS
      Proxy con Antivirus
      Filtri Web
      WiFi Access Point
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS e LDAP
      Certificati X.509
      RADIUS
      VPN
      Firewall


Valid HTML 4.01 Transitional




Access Point Wireless con Multiple SSID e VLAN

Lo scopo di questo documento è descrivere la realizzazione di un Access Point per WiFi usando Zeroshell su di un sistema con a bordo una scheda di rete Wifi con chipset Atheros. Il documento è suddiviso nelle seguenti sezioni:

Perché realizzare un Access Point Wireless con i driver Linux del progetto MadWifi?

Grazie all'utilizzo dei moduli MadWifi per Kernel Linux è possibile realizzare un Access Point Wireless utilizzando un Personal Computer o un Dispositivo Embedded che disponga di una scheda di rete WiFi (PCI o MiniPCI) con Chipset Atheros. Questa possibilità è disponibile a partire dalla versione 1.0.beta8 di Zeroshell, che introduce il supporto al WiFi sia in modalità AP (Access Point) che STA (in cui un router/bridge Zeroshell può associarsi come client in una Wireless LAN).
La scelta di utilizzare i driver MadWifi per Atheros, combinata con l'utilizzo dei pacchetti wpa_supplicant e hostapd, è motivata dalla loro capacità di svolgere le funzioni di un AccessPoint con caratteristiche avanzate, quali per esempio:
  • Autenticazione degli accessi e cifratura del traffico wireless mediante WPA/WPA2 (RSN). È supportata sia la modalità WPA-PSK, in cui un client per associarsi ad un SSID deve conoscere la Pre-Shared Key, sia la modalità WPA-EAP, nota anche come WPA Enterprise, in cui un utente può autenticarsi con Username e Password o con un certificato digitale X.509 convalidati da un server Radius. Sono supportati entrambi gli algoritmi di criptazione TKIP e il più sicuro CCMP basato su AES;
  • Gestione della modalità Multiple SSID (detta anche Virtual SSID), grazie alla quale, per ognuna delle schede di rete WiFi presenti nel sistema è possibile creare fino a 4 Access Point virtuali indipendenti tra loro. È chiaro, che tali SSID virtuali, appartenenti ad una stessa scheda di rete WiFi, condividono il canale radio utilizzato e quindi anche la banda disponibile. Tuttavia, per ognuno degli SSID virtuali è possibile stabilire uno schema di autenticazione e di encryption (plain-text, WPA-PSK, WPA Enterprise o WEP a 128 bit) indipendente.
    Dei quattro possibili SSID uno può anche lavorare in modalità Managed ed associarsi come client di una WLAN. Ciò risulta utile, per esempio, per estendere il raggio di copertura della propria rete Wireless costruendo dei repeater che lavorando in WDS (Wireless Distribution System) non necessitano di essere interconnessi tra loro da una rete Wired.
  • Compatibilità sia con reti su canali nella banda dei 5GHz (802.11a) che nella banda dei 2.4GHz (802.11b e 802.11g). In particolare, nel caso in cui si scelga la modalità 802.11g risulta comunque garantita la compatibilità per i client più vecchi che dispongono solo di 802.11b.
Zeroshell identifica ogni singolo SSID virtuale come fosse un'interfaccia Ethernet (ETHnn). Ciò consente di operare sulle reti Wi-Fi, usando l'interfaccia web, come si è abituati a operare con le interfacce wired. In altre parole, sugli SSID è possibile:
  • Aggiungere indirizzi IP, route statiche e abilitare il protocollo RIP v2 per acquisire e propagare le route dinamiche;
  • Applicare classi di QoS per effettuare il traffic shaping assegnando diversi livelli di priorità, banda massima e garantita ai diversi tipi di traffico (VoIP, P2P, SSH, HTTP, ...);
  • Effettuare il bridging con interfacce Ethernet, VLAN 802.1q, VPN LAN-to-LAN o altri SSID. In particolare, la possibilità di mettere in bridge, cioè collegare in Layer 2, un Virtual SSID che lavora in modalità Client con uno che lavora come Access Point, consente di realizzare i cosiddetti Repeater WiFi (o WDS) che estendono il raggio di copertura della WLAN;
  • Attivare servizi quali il DHCP e il Captive Portal nonché applicare filtri al traffico mediante il Firewall.
  • Applicare il bonding, cioè aggregare due o più interfacce in maniera da incrementare la banda (load balancing) e l'affidabilità (fault tolerance). Naturalmente, affinché un bonding wireless abbia senso è necessario che i Virtual SSID che lo compongono appartengano a interfacce WiFi distinte in maniera da bilanciare il traffico su più canali radio distinti.

Gestire le interfacce wireless e i Multi SSID con il wifi-manager

Benché usando l'interfaccia web di Zeroshell (vedi figura) sia possibile gestire le interfacce di rete che rappresentano gli SSID, le operazioni di creazione e gestione di quest'ultimi per quel che riguarda i parametri wireless quali il canale da impiegare, la potenza di trasmissione in dBm e l'encryption da utilizzare vengono gestiti tramite uno script che si invoca con il comando di shell wifi-manager da una console seriale RS232 o VGA oppure tramite una sessione remota SSH. Sotto si può vedere la schermata principale del wifi-manager:

root@gw-adsl root> wifi-manager

[wifi0]  Chipset  AR5413 802.11abg NIC (rev 01)
-- If -- Mode -- SSID --------------------------- Hide -- Security -
>> ETH02  AP     WLAN with Captive Portal          no     Plaintext
   ETH03  AP     WLAN with Pre-Shared Key          no     WPA-PSK  
   ETH04  AP     WLAN with 802.1x Radius Auth.     no     WPA-EAP  
   ETH05  AP     WLAN with WEP                     no     WEP128

[wifi1]  Chipset  AR5413 802.11abg NIC (rev 01)
-- If -- Mode -- SSID --------------------------- Hide -- Security -
   ETH06 STA     wrap-psk                          no     WPA-PSK  

COMMANDS
  <N> New SSID               <M> Modify SSID
  <D> Delete SSID            <I> Show Information
  <C> Std/Channel/Tx-Power
  <L> List Stations          <S> Channel Scanning
  <R> Restarting Devices     <Q> Quit

>>

Come si può notare, il sistema di esempio, realizzato con un PC Embedded ALIX 2C2, dispone di 2 interfacce WiFi con chipset Atheros AR5413 802.11abg capaci di lavorare sia in 802.11b/g che in 802.11a. Sull'interfaccia wireless wifi0 sono definiti 4 Access Point virtuali che condividono la stessa frequenza radio, ma ognuno con uno schema di autenticazione e criptazione indipendente:
  • L'interfaccia ETH02 corrisponde alla WLAN il cui SSID è "WLAN with Captive Portal". Su di essa non è definita alcuna cifratura (Plaintext), ma l'autenticazione viene delegata successivamente al Captive Portal;
  • L'interfaccia ETH03 corrisponde ad un SSID "WLAN with Pre-Shared Key" con protezione WPA-PSK al quale si accede conoscendo la chiave condivisa impostata in fase di creazione del SSID. Questa modalità di protezione, che sostituisce quella con WEP ormai facilmente vulnerabile catturando una certa quantità di pacchetti, è ritenuta sufficientemente sicura purché si utilizzi una Preshared Key di dimensione e complessità adeguate. Naturalmente, come per il WEP, l'amministratore deve comunicare la chiave a tutti gli utenti che devono poter accedere alla rete wireless e si deve occupare di cambiarla periodicamente. Ciò è fattibile in piccole realtà come quelle domestiche o SOHO, ma diventa oneroso al crescere degli utenti e del numero di Access Point;
  • L'interfaccia ETH04 fa riferimento all'Access Point virtuale con SSID "WLAN with 802.1x Radius Auth." e su cui è configurato uno schema di cifratura WPA-EAP. Tale metodo di protezione è il più sicuro e flessibile ed è pertanto utilizzabile in grosse realtà. Non a caso si fa riferimento al WPA-EAP anche come WPA Enterprise. La sua flessibilità, è dovuta al fatto che le chiavi di cifratura non sono generate dall'amministratore, ma automaticamente da un server RADIUS tramite 802.1x che autentica l'utente tramite username e password (usando PEAP con MsCHAPv2 o EAP-TTLS) oppure con certificato digitale X.509 personale (usando EAP-TLS). Durante la configurazione del SSID con WPA-EAP, si può scegliere se utilizzare il server RADIUS locale di Zeroshell oppure fare riferimento ad un server RADIUS esterno. Nel primo caso non è necessario configurare alcuno Shared Secret, mentre nel caso di RADIUS esterno bisogna specificarlo.
  • Sull'ultima interfaccia è definita la cifratura WEP a 128 bit. Se non è strettamente necessario a causa della presenza di vecchi client non compatibili con WPA/WPA2, si dovrebbe evitare di usare WEP, vista la bassa protezione che garantisce.
Sull'interfaccia wifi1 è definito un solo SSID in modalità client. Tale interfaccia si connetterà alla rete wireless di nome "WRAP-PSK" protetta con una Pre-shared Key. Si noti, che su di una stessa WiFi card si può avere al massimo un SSID che funzioni da client. Gli eventuali altri SSID devono invece corrispondere a dei Virtual Access Point. Peraltro, visto che tutti gli SSID appartenenti ad una stessa WiFi card condividono il canale, quest'ultimo coinciderà con il canale radio della WLAN esterna. Ciò comporterà un inevitabile condivisione di banda.

Considerata la semplicità del wifi-manager, risulta inutile descriverne ora ogni singolo comando il cui uso dovrebbe essere abbastanza intuitivo. L'unica nota riguarda la voce "Std/Channel/Tx-Power" che si aziona con il tasto C del menu. Con questo è possibile impostare lo standard (802.11a, 802.11b e 802.11g e prossimamente con la nuova versione dei driver MadWiFi anche 802.11n ancora in draft), il canale radio in base alle frequenze disponibili per lo standard scelto e la potenza di trasmissione espressa in dBm o mW. In particolare, bisogna impostare con cura quest'ultimo parametro evitando di superare il limite di potenza consentito per legge nel luogo in cui ci si trova.

Come già accennato, una volta creati e configurati gli SSID con il wifi-manager, sia che essi corrispondano a dei Virtual Access Point che a delle connessioni client, questi appaiono in tutto e per tutto come delle interfacce ethernet (ETHnn) che possono essere manipolate dall'interfaccia web di Zeroshell. Nell'esempio illustrato nella figura sotto, i quattro Multi SSID e l'interfaccia wired ETH00 vengono messi in bridge in unica interfaccia BRIDGE00(ETH00,ETH02,ETH03,ETH04,ETH05).


Interfaccia Web di configurazione del Wi-Fi
Interfaccia Web di configurazione. Fai click sull'immagine per ingrandire.


Così facendo, tutte e 4 le WLAN, indipendentemente dal modo con cui si accede (WPA-PSK, WPA-EAP, Captive Portal o WEP), condividono lo stesso layer 2 della LAN raggiungibile tramite l'interfaccia Ethernet ETH00. Il fatto di condividere il livello di Data Link fa si che si possa sfruttare sui vari SSID componenti il bridge il dhcp server della LAN se esistente oppure di attivare un'unica subnet nel dhcp che si agganci all'interfaccia bridge. Ovviamente, visto che il Firewall e il classificatore QoS agiscono anche sulle interfacce di un bridge, si potrebbe pensare di applicare delle regole di accesso e di traffic shaping indipendenti per ogni singolo SSID. Per esempio, si potrebbe privilegiare gli utenti che fanno accesso mediante WPA Enterprise rispetto a quelli che usano il Captive Portal visto che con quest'ultimo il traffico non è criptato.

Mappare le Wireless LAN sulle VLAN con tag

Se sugli switch di una LAN sono definite delle Virtual LAN, nel senso che le loro porte sono raggruppate logicamente in maniera da apparire come appartenenti a switch (virtuali) distinti, la comunicazione tra gli switch viene affidata alle cosiddette porte di trunk o trunking. Tali porte sono caratterizzate dall'appartenere contemporaneamente a più di una VLAN e i pacchetti che vi transitano dall'essere identificabili da un tag (o VID) che ne identifica la VLAN di origine/destinazione. Uno dei protocolli di trunking più utilizzati è quello definito dallo standard IEEE 802.1q che dispone di un tag a 12 bit con valori validi da 1 a 4094. Viene peraltro definito il concetto di VLAN Nativa, cioè della VLAN i cui pacchetti transitano sul trunk come trame Ethernet normali non taggate. Alla VLAN Nativa si assegnano spesso compiti di management. La diffusione di questo standard ha permesso ad apparati di rete di marca e modello diversi di interoperare tra loro anche in presenza di Virtual LAN. In particolare, diventa sempre più diffusa l'esigenza di mappare le VLAN in cui è suddivisa la LAN su SSID wireless distinti. Ciò consente di avere omogeneità tra l'assegnazione delle subnet IP tra le VLAN che compongono la LAN e gli SSID che costituiscono la WLAN. Grazie al supporto di Zeroshell alle VLAN 802.1q, alla gestione del Multiple SSID per singolo Access Point e alla possibilità di mettere in bridge le interfacce che rappresentano le VLAN con quelle che rappresentano gli SSID, ciò è possibile in maniera economica, senza dover utilizzare un Access Point (fisico) per ognuna delle Virtual LAN che si vuole raggiungere anche via rete wireless.

A titolo di esempio, supponiamo che un'organizzazione abbia la LAN suddivisa in 2 VLAN:
  • Una VLAN su cui far accedere gli host di servizio e i desktop del personale appartente stabilmente all'organizzazione. Questa VLAN, su cui non è definita alcuna restrizione sulle risorse di rete interne da parte del Firewall, ha il VID (VLAN ID) 1220 e deve essere accessibile in wireless tramite un SSID annunciato come "Trusted Network". L'accesso a tale WLAN deve essere permesso soltanto a chi dispone di una Smart Card o eToken con certificato personale X.509, cioè tramite WPA-EAP con RADIUS abilitato a rispondere a EAP-TLS;
  • Una VLAN su cui invece far confluire i portatili di eventuali ospiti, che necessitino di avere accesso completo a Internet, ma possano accedere in maniera più limitata e controllata alle risorse di rete interne. Tale VLAN, il cui VID fissiamo a 2350, va estesa in wireless con un SSID annunciato come "Guest Network" non cifrato. Benché il traffico viaggi in chiaro su questa WLAN, l'autenticazione degli accessi viene demandata al Captive Portal a cui si accede tramite username e password temporanee fornite agli ospiti. La scelta di utilizzare il Captive Portal per questa VLAN è motivata dalla semplicità di accesso che non costringe gli ospiti a configurarsi il loro WiFi supplicant per l'accesso a WPA Enterprise. Quest'ultima operazione non è sempre immediata e supportata facilmente da tutti i sistemi operativi, mentre il Captive Portal fornisce accesso indipendentemente dal tipo di sistema purché disponga di un web browser.

Come illustrato sotto, vengono creati i due SSID virtuali tramite il wifi-manager: "Trusted Network" corrisponde all'interfaccia ethernet ETH02 ed ha il WPA Enterprise attivo; "Guest Network" corrisponde invece ad ETH03. Benché l'hardware che stiamo usando dispone di 2 schede di rete WiFi (wifi0 e wifi1) si è deciso di creare entrambi gli SSID su wifi0. Ciò consente di risparmiare un canale radio che è una risorsa preziosa se si usa 802.11b/g, visto che gli unici canali senza sovrapposizione di frequenze (overlapping) sono solo tre (1,6 e 11).

root@multi-AP root> wifi-manager

[wifi0]  Chipset  AR5413 802.11abg NIC (rev 01)
-- If -- Mode -- SSID --------------------------- Hide -- Security -
>> ETH02  AP     Trusted Network                   no     WPA-EAP  
   ETH03  AP     Guest Network                     no     Plaintext                   

[wifi1]  Chipset  AR5413 802.11abg NIC (rev 01)
-- If -- Mode -- SSID --------------------------- Hide -- Security -

COMMANDS
  <N> New SSID               <M> Modify SSID
  <D> Delete SSID            <I> Show Information
  <C> Std/Channel/Tx-Power
  <L> List Stations          <S> Channel Scanning
  <R> Restarting Devices     <Q> Quit

>>


Ora, supposto che l'interfaccia ethernet ETH00 sia connessa ad uno switch su di una porta trunking tramite cui vengono trasportate le due VLAN con tag 1220 e 2350 oltre alla VLAN nativa, usando il bottone [Create VLAN] aggiungiamo le suddette Virtual LAN. Fatto ciò, creiamo due bridge con il pulsante [Make BRIDGE]: BRIDGE00 deve connettere in layer 2 ETH00.1220 (VLAN 1220) con ETH02 (SSID "Trusted Network"), mentre BRIDGE01 deve connettere ETH00.2350 (VLAN 2350) con ETH03 (SSID "Guest Network"). Il tutto è illustrato nella figura in basso:

Mappatura SSID VLAN tramite Bridge
Mappatura degli SSID sulle VLAN tramite Bridge. Fai click sull'immagine per ingrandire.


Si noti che ai due bridge non è strettamente necessario assegnare un indirizzo IP, mentre all'interfaccia ETH00, corrispondente alla VLAN Nativa, è assegnato l'indirizzo IP 192.168.0.75 a cui ci si connette per eseguire il management di Zeroshell.
A questo punto, per completare il lavoro, è sufficiente attivare il Captive Portal dalla sezione [Captive Portal]->[Gateway] sull'interfaccia ETH03 (SSID "Guest Network") in Bridge Mode.

Estendere geograficamente il Wireless tramite VPN

Zeroshell utilizza OpenVPN con dispositivi Tap (Ethernet virtuali) come soluzione VPN Site-to-Site. Ciò offre il vantaggio, rispetto a protocolli come IPsec, di poter connettere in layer 2 le sedi di un'organizzazione geograficamente distanti. Infatti, essendo le interfacce Tap (Zeroshell le chiama VPNnn) del tutto simili alle interfacce ethernet (ETHnn), le VPN possono essere messe in bridge con quest'ultime e anche con gli SSID wireless. In questa maniera, non essendoci processi di routing tra le LAN e le WLAN sia locali che remote connesse tramite VPN, si può usare la stessa sottorete IP ovunque. Di conseguenza, non solo si può utilizzare un unico dhcp server che distribuisca ad ogni client sempre lo stesso indirizzo IP indipendentemente dalla sede e dal tipo di connessione (Wired o Wireless), ma protocolli come il NetBIOS per la condivisione di risorse Windows quali stampanti e cartelle, funzionano senza ricorrere all'uso di un server WINS per il discovering delle risorse di rete, poiché il traffico in broadcast si propaga in maniera uniforme su LAN e WLAN (locali e remote).
Sempre grazie alla somiglianza delle VPN realizzate con OpenVPN a delle vere e proprie connessioni Ethernet, è possibile generalizzare l'esempio precedente trasportando nelle sedi remote anche le VLAN 802.1q ed estenderle in wireless mettendo in bridge le interfacce che rappresentano le VLAN trasportate dalla VPN (nell'esempio precedente sono VPN00.1220 e VPN00.2350) con gli SSID "Trusted Network" e "Guest Network".



    Copyright (C) 2005-2013 by Fulvio Ricciardi