36
Realizzazione di una rete condominiale con Zeroshell e l’uso del protocollo 802.1Q By Paolo Iapilone [email protected] Dicembre 2015
Realizzazione di una rete condominiale
con Zeroshell e l’uso del protocollo
802.1Q
By Paolo Iapilone
Dicembre 2015
Sommario
Scopo del documento ............................................................................................................................... 3
Descrizione ambiente e obiettivi .............................................................................................................. 3
Alcune considerazioni e la soluzione utilizzata ......................................................................................... 5
Hardware scelto per la soluzione .............................................................................................................. 7
Realizzazione della soluzione .................................................................................................................... 8
Schema di rete condominiale ................................................................................................................... 8
Switch Netgear GS108T-200GES – Primi passi ........................................................................................ 11
La configurazione di SW1 ........................................................................................................................ 12
La configurazione di SW1 - LAG - Collegare due switch Netgear in LACP ............................................... 13
La configurazione di SW1 - Associazione Porte/VLAN/TAG/UNTAG/PVID ............................................. 13
La configurazione di SW2 ........................................................................................................................ 16
Installazione Zeroshell ............................................................................................................................ 17
Configurazione Zeroshell ........................................................................................................................ 21
Test di funzionamento ............................................................................................................................ 24
ZS come Access Point .............................................................................................................................. 27
Obiettivi raggiunti ? ................................................................................................................................ 32
Il server Windows 2012 - SERVER1 ......................................................................................................... 33
Zeroshell come macchina virtuale .......................................................................................................... 35
Ringraziamenti ........................................................................................................................................ 36
Scopo del documento Il presente documento illustra il progetto di rete dati realizzato in un condominio, usando, tra l’altro,
Zeroshell (ZS) come router configurato con il protocollo IEEE 802.1Q, in maniera da utilizzare un singolo
collegamento fisico (e quindi un unico cavo ethernet) per più LAN. Su ZS è anche presente una scheda
WiFi configurata come Access Point per garantire accesso wireless alla rete nei pressi del router stesso.
Questo tipo di configurazione consente una semplificazione non indifferente dell’hardware, non
richiedendo l’utilizzo di più schede di rete fisiche. Pensiamo solo al costo di una scheda ethernet dual
port se non addirittura quad port. Oltre al risparmio energetico in generale, tale soluzione permette
l’utilizzo di Zeroshell su hardware che altrimenti non sarebbe più utilizzabile, vedi ad esempio vecchi pc
portatili, oppure l’utilizzo di hardware tipo Alix anche per più LAN a prescindere dalle NIC on board.
Descrizione ambiente e obiettivi In un condominio di tre appartamenti (interno 1,2 e 3), che potrebbe essere la sede di un ufficio, si vuole
utilizzare ZS per la comunicazione dati tra gli interni.
Due di questi interni, 2 e 3, dispongono ognuno di propria connessione Internet tramite rete Fastweb.
Interno 1 non ha connessione Internet, utilizza però una delle altre reti per solo traffico VOIP.
E’ presente un server Windows 2012R2 in dominio AD (SERVER1) che assicura risorse storage sia di
condominio che a livello utente. Sul server è abilitato il ruolo Hyper-v che consente di far girare, tra le
altre, una macchina virtuale ZS utilizzata come backup di quella fisica.
Il backup dei dati è previsto su un NAS (NAS1) ma non sarà oggetto di trattazione su questo documento,
il NAS viene menzionato solo come apparato che necessita di connessione ethernet.
Un cavo ethernet per ogni interno scende nello scantinato e arriva in una scatola di derivazione che può
essere intesa come un piccolo “centro stella”.
Il cavo ethernet dell’interno 2, per il quale traffico sono sufficienti 100 Mb, viene diviso in modo da
ottenere due cavi ethernet (ognuno formato da sole due coppie) senza stendere un’altra linea, cosi da
portare nel centro stella anche la connessione Internet relativa, visto che il modem Fastweb è
nell’abitazione.
Alla stessa scatola di derivazione arrivano tre cavi ethernet che provengono da una stanza abbastanza
sicura, sotterranea e non facilmente accessibile, dove trovano posto SERVER1 e ZS; arriva infine anche la
linea telefonica dell’interno 3 e il cavo ethernet verso il NAS1. Ricapitolando, nella scatola sono presenti:
- Interno 1 – LAN1, collegato a LAN2 oppure LAN3, uso VOIP
- Interno 2 – LAN2 e Internet WAN2
- Interno 3 – LAN3 e Internet WAN3 (la presenza della linea telefonica+Internet dell’interno 3 nel
“centro stella” suggerisce il posizionamento del modem/router Fastweb direttamente nella
scatola di derivazione)
- Tre cavi ethernet verso SERVER1+ZS
- Un cavo ethernet verso NAS1
L’obiettivo finale è quello di permettere alle reti di condominio di parlarsi tra loro e accedere al
SERVER1; l’interno 1 deve poter contare su un accesso Internet per utilizzare il solo VOIP.
Dal centro stella alla sala server sarebbe opportuno che rimanga libero un cavo spare (di ricambio).
In sala server occorre un accesso WiFI, magari con ZS stesso.
E’ gradita inoltre la possibilità, non automatica, di poter usare una singola rete WAN per tutti gli utenti in
caso una delle due presentasse un fault. Non è voluta la presenza di un automatismo in quanto si
desidera la certezza che ogni utente di ogni interno utilizzi per la navigazione Internet il proprio
collegamento Fastweb (per questioni essenzialmente legali) e usi l’altro solo in caso d’emergenza.
Quanto descritto si può riassumere nel disegno a seguire (schema di rete, riproposto anche in seguito):
Alcune considerazioni e la soluzione utilizzata In primo luogo si considera che LAN1 e LAN2 non possono essere messe in comunicazione diretta dato
che ognuna deve avere un suo gateway, occorre necessariamente una soluzione routata.
Dove possibile si vuole limitare il numero di cavi usati e possibilmente averne qualcuno di backup.
Dopo queste e numerose altre considerazioni, la soluzione che si è scelto di adottare prevede l’utilizzo di
switch di tipo managed e del protocollo 802.1Q, il che consente una notevole semplificazione dei
cablaggi, anche se a fronte di una gestione forse un tantino più complessa. Si potrebbe inoltre obiettare
sul costo, ma ad oggi due switch gestiti con porte a 1 Gb vengono a costare poco più di 100 euro, cifra
abbastanza abbordabile.
Inoltre, tramite l’utilizzo del protocollo IEEE 802.1Q, si usa una sola NIC sul router ZS e su SERVER1
riducendo i cablaggi al minimo.
Quanti switch occorrono? Il calcolo è presto fatto, considerando però un fatto importante: il server
Windows necessita di due linee fisiche separate. Questo perché se da un lato Server 2012 gestisce in
maniera nativa 802.1Q, dall’altro le schede di rete generate e associate alle VLANs non sono utilizzabili
da Hyper-v. Il server necessita di due trunk: uno dedicato al virtual switch di Hyper-v, uno per il server
vero e proprio:
http://blogs.technet.com/b/keithmayer/archive/2012/11/20/vlan-tricks-with-nic-teaming-in-windows-
server-2012.aspx
Le porte necessarie sul switch di centro stella sono:
- LAN1
- LAN2
- WAN2
- LAN3
- WAN3
- ZS
- SERVER1, due porte
- NAS1
In totale 9 porte. Non è fattibile un singolo switch. Non rimane che collegare insieme due switch, in
questo caso il secondo switch va nella stanza del SERVER1 e ZS.
Sul switch di centro stella (SW1) in questo caso le porte necessarie diventano:
LAN1+WAN1+LAN2+WAN2+LAN3+NAS1=6
Rimangono libere due porte, con queste si realizza un TRUNK LACP verso l’altro switch, dato che il
software degli apparati lo consente, sfruttando meglio sia la ridondanza che la banda disponibile.
L’ultimo cavo non viene utilizzato, diventa di backup dal centro stella verso la stanza dei server.
Il switch (SW2) che andrà nella stanza server necessita delle seguenti porte:
- SERVER1 (due porte)
- ZS
- TRUNK (due porte)
per un totale di 5 porte. Le tre rimanenti sono di backup o per eventuali altri apparati futuri da porre in
sala server.
Hardware scelto per la soluzione La scelta dei switch managed è caduta sui Netgear GS108T-200GES, costano poco e offrono la flessibilità
di configurazione richiesta.
ZS va su un hardware recuperato, un PC mini-atx usato a suo tempo come lettore multimediale. La
motherboard montata è la Asus AT3N7AX. Ha una potenza di fuoco più che abbondante, è affiancata ad
1 GB di RAM. Può fare boot da USB, cosa che come vedremo semplifica enormemente le risorse da
utilizzare: non c’è necessità di hard disk di alcun tipo, lo stesso controller SATA può essere disabilitato
insieme all’audio e a tutto ciò che non serve. La scheda Realtek di serie è pienamente compatibile con ZS
e IEEE 802.1Q. Per l’alimentazione è stato usato un pico-psu, riciclando cosi anche un alimentatore
esterno per PC portatile che altrimenti sarebbe andato al macero e ottenendo una buona efficienza
energetica, ma soprattutto slegandosi dall’alimentatore custom del case. Modificando opportunamente
il box, si sono ottenute due porte USB al suo interno dove alloggiano una pen USB da 8 Gb per il sistema
operativo e una pen WiFi con chipset Atheros compatibile con ZS, modificata per collegare una antenna
esterna.
Foto del supporto USB a doppia presa spostato dal pannello frontale all’interno del box, ospitante sia
la pen di sistema operativo che la pen WiFi Atheros – 150 Mbps modificata con antenna esterna
Realizzazione della soluzione Dato che lo scopo di questo documento è mostrare l’utilizzo del protocollo 802.1Q, viene mostrato
come configurare le VLAN su ZS. Per fare questo occorre conoscere lo schema della rete, definire le
VLANs da usare, gli IP address per ZS e proporre i collegamenti sulle porte dei switch.
Questi ultimi vanno configurati prima di essere collegati. Di default alla prima accensione hanno in
comunicazione tutte le porte, collegarli in rete senza configurazione preventiva creerebbe una serie di
loop e conflitti tali da bloccare tutte le reti coinvolte.
Si configurano i due switch in modo che tutte le LANs che arrivano al centro stella (traffico di tipo
UNTAGGED) vengano taggate e spedite con un link LACP (due cavi ethernet) verso il switch di sala
server, dove sono attestati ZS e SERVER1. Sulle due macchine, usando il protocollo 802.1Q, con un solo
link fisico arrivano tutte le LANs di partenza.
Le definizioni TAGGED, UNTAGGED e LACP sono spiegate a breve più avanti.
A seguire troviamo quanto progettato per costruire la rete, cioè:
- Lo schema di rete condominiale
- La tabella delle VLAN definite (Tabella1)
- L’assegnazione delle porte sugli switch SW1 e SW2 (Tabella2); I contenuti delle tabelle saranno
più chiari a breve, appena si introdurrà la descrizione degli switch Netgear.
Schema di rete condominiale (prossima pagina), che mostra tutti gli apparati coinvolti:
La soluzione illustrata propone due router in cascata per entrambe le reti LAN1 e 2 verso Internet (uno
dei router, per l’interno 3, è ZS) e quindi un doppio NAT. La scelta è voluta per due motivi:
1) Fastweb può ciclicamente proporre l’upgrade del firmware degli apparati. Non è dato di sapere
se tale upgrade comporta un reset di configurazione, per cui non vale la pena personalizzare
troppi parametri nei loro modem/router sapendo che in ogni momento possono andare persi. In
questo caso l’unica variazione fatta rispetto al default è l’IP address del modem dell’interno 2
per creare una ulteriore classe di indirizzamento e quindi una ulteriore VLAN, cosa ripristinabile
in pochi secondi qualora il modem fosse interessato da un reset da parte del provider o di
emergenza lato utente in caso di malfunzionamento;
2) Motivo ancora più importante, i modem-router forniti dal provider hanno entrambi una sezione
WiFi piuttosto carente, alcuni test eseguiti mostrano che un appartamento di circa 90 metri
quadri non è coperto bene; tanto vale affiancarli ad hardware più performante che, tra l’altro,
era già presente prima del passaggio a Fastweb ed è stato riutilizzato. In termini di copertura ma
soprattutto di stabilità, il WiFi dell’AP Netgear WN203 e dell’Asus DSL-N55U sono sicuramente
superiori rispetto ai modem forniti dal provider, non dimenticando che l’Asus consente di avere
in contemporanea alla banda 2.4GHz anche quella a 5 GHz.
Definizione VLANs: Tabella1
Sito Tipo e Subnet Range DHCP
VLAN Assegnata
VLAN Name IP Porta
Zeroshell
Interno 2 WAN2 192.168.2.0/24 VLAN 268 WAN2 Interno 2 192.168.2.10
Interno 2 LAN2 192.168.12.0/24 100-150 VLAN 168 LAN2 Interno 2 192.168.12.10
Interno 3 WAN3 192.168.1.0/24 VLAN 68 WAN3 Interno 3 192.168.1.10
Interno 3 LAN3 192.168.13.0/24 100-150 VLAN 1 LAN3 Interno 3 192.168.13.10
Definizione Porte sugli switch: Tabella2
Switch Porta Descrizione/VLAN
Name Porta o LAG
TAG (T) /UNTAG (U) VLAN ID PVID
SW1 1 LAN3 Interno 3 U 1 1
SW1 2 WAN3 Interno 3 U 68 68
SW1 3 WAN2 Interno 2 U 268 268
SW1 4 LAN2 Interno 2 U 168 168
SW1 5 LAN1 Interno 1 U 1 1
SW1 6 NAS1 U 1 1
SW1 7 LACP Cavo 1 1
SW1 8 LACP Cavo 2 1
SW1 LAG1 - LAG LACP T 1
SW2 1 SERVER1 T 1,68,168,268 1
SW2 2 SERVER1 - Hyper-v T 1,68,168,268 1
SW2 3 Zeroshell T 1,68,168,268 1
SW2 4,5,6 Libere 1
SW2 7 LACP Cavo 1 1
SW2 8 LACP Cavo 2 1
SW2 LAG1 - LAG LACP T 1,68,168,268 1
Switch Netgear GS108T-200GES – Primi passi Sul sito del produttore si trova tutto il necessario: software, firmware, manuali. La password di default
degli switch è password
Si consiglia di collegare la porta 1 di ogni switch su una rete già disponibile e dove sia presente un DHCP.
Ogni apparato in queste condizioni acquisisce il suo IP e si rende raggiungibile senza problemi.
Scaricate dal sito Netgear l’ultima versione del software Smart Control Center (SCC) e del firmware degli
switch su un PC Windows nella stessa rete dove sono gli switch da configurare. Avviate l’applicazione.
L’applicazione esegue il discovery della rete e trova gli apparati.
Aggiornare il firmware. L’operazione richiede circa 10 minuti.
La configurazione di SW1 Per dividere/raggruppare le porte di uno switch managed occorre creare delle VLANs alle quali associare
le porte. Ci sono tre classi di vlan di default già configurate in questi Netgear, delle tre ne viene usata
solo una (VLAN1), le altre necessarie a questo progetto vengono create ex novo.
La VLAN1 corrisponde alla VLAN di management degli switch. Si consiglia la lettura del manuale
dell’apparato al fine di capire quanto è importante lasciare una porta degli switch sulla VLAN1 per
garantire l’amministrazione degli stessi. Nel caso specifico, su entrambi gli switch la porta 1 è lasciata in
VLAN1.
Occorre creare su entrambi gli switch le VLANs indicate in Tabella1 – VLAN Name.
Si agisce entrando nella pagina web del switch, tab Switching->VLAN->Basic->VLAN Configuration
Impostare i dati nelle relative caselle VLAN ASSEGNATA e VLAN Name ricavati dalla tabella, poi in basso
a destra cliccare su ADD:
Fatto questo, vediamo di spiegare come si realizza un LAG LACP (detto anche TRUNK), dato che gli
switch dovranno comunicare tra loro in qualche modo.
La configurazione di SW1 - LAG - Collegare due switch Netgear in LACP Il documento a seguire, scritto dal produttore dell’hardware, descrive la realizzazione di un LAG in LACP
tra due suoi switch. La consultazione è indispensabile per proseguire nella configurazione.
http://www.downloads.netgear.com/files/GDC/GSM7352SV2/how_to_configure_lag.pdf
La configurazione di SW1 - Associazione Porte/VLAN/TAG/UNTAG/PVID
E’ necessario comprendere come i parametri di configurazione VLAN/TAG/UNTAG/PVID degli switch
interagiscono tra loro per proseguire. Il manuale non è proprio chiarissimo in merito a VLAN e PVID,
vedremo di chiarire le cose.
Nota Bene: quanto segue NON SOSTITUISCE LA LETTURA E COMPRENSIONE DEL MANUALE
AMMINISTRATORE DEGLI APPARATI NETGEAR SCRITTO E REDATTO DAL PRODUTTORE.
TAG-TAGGED
Ad una porta qualunque del switch si può assegnare lo stato di TAGGED (T) oppure UNTAGGED (U).
Se la porta è taggata, il PVID non viene preso in considerazione, come se non esistesse.
Se la porta è taggata, può appartenere a piu VLANs e trasportarne i dati taggati.
Questo si ottiene associando la porta taggata alle VLANs che deve trasportare, configurando la sezione
dell’apparato relativa a Switching->VLAN->ADVANCED->VLAN Membership.
Nella figura a seguire siamo sul switch SW1; il trunk LAG1 trasporta tutte le reti verso l’altro switch,
quindi DEVE essere taggato per tutte le VLAN da trasportare, altrimenti non è possibile “fasciare” le
quattro VLANs.
E’ evidente come il trunk LAG1, risultante dall’unione delle porte 7 e 8 del SW1, sia membro taggato di
tutte le quattro VLANs che sono state configurate in precedenza:
UNTAG-UNTAGGED
Se una porta è configurata come UNTAGGED, può appartenere AD UNA SOLA VLAN.
Sulle porte UNTAGGED sono collegati i cavi di ogni LAN, su queste passa solo traffico non taggato.
Ogni LAN va associata ad un VLAN ID per poter essere trasportata dal trunk LAG1.
La cosa è logica; una data porta non può sapere da dove proviene un dato traffico se è UNTAGGED, deve
essere associata ad una VLAN in qualche altro modo.
Nella figura precedente è mostrato chiaramente che ogni porta UNTAGGED (U) appartiene ad una
singola VLAN. Una VLAN può avere più porte, ogni porta una sola VLAN:
- VLAN1 associa le porte 1,5 e 6
- VLAN68 associa la porta 2
- VLAN168 associa la porta 4
- VLAN268 associa la porta 3
Nessuna porta UNTAGGED è associata a più di una VLAN, mentre LAG1, che è TAGGED, è associato a
tutte le VLAN e quindi può trasportare tutto il traffico delle porte UNTAGGED.
L’associazione PORTA UNTAGGED/VLAN ID/PVID garantisce il corretto instradamento del traffico.
Il PVID è specifico della porta UNTAGGED, il suo valore è identico al VLAN ID e va impostato in:
Switching->VLAN->Advanced->Port PVID Configuration
La figura a seguire mostra le impostazioni PVID per le varie porte del SW1, impostazioni prese e inserite
nel switch dalla Tabella 2 trattata in precedenza:
Per la descrizione dei vari parametri e della configurazione sono usate figure che riguardano la reale
configurazione di SW1, chi legge dovrebbe essere in grado di inserire ogni parametro al posto giusto.
La configurazione per far funzionare lo SW1 nel contesto descritto è terminata, lascio al lettore la
configurazione di altri parametri secondari quali il setting dell’orario e la decisione di lasciare l’ip in dhcp
piuttosto che impostarlo fisso. Nel manuale amministratore queste configurazioni sono descritte in
maniera semplice ed esaustiva.
La configurazione di SW2 è, se vogliamo, più semplice. Si configuri in primis il link LAG LACP come
descritto in precedenza.
Ora, su SW2 tutte le porte usate ricevono e trasmettono traffico TAGGED, per cui si disinteressa del
PVID; vanno solo configurate le VLANs come fatto per SW1 e associata la membership delle VLAN:
-----------------------------------------------------------------------------------------------------------------------------------------
Installazione Zeroshell ZS viene installato su un pen drive USB (PEN2), inserito sulla presa ricavata all’interno del box.
Occorre una chiavetta di supporto (PEN1) sulla quale scompattare l’immagine e fare il boot,
successivamente la PEN1 può essere riutilizzata per altri scopi.
La procedura descritta utilizza due PEN drive in modo che alla fine dell’installazione quella usata dal
sistema ZS utilizzi tutto lo spazio a disposizione, in questo caso 8 GB. L’immagine scritta da physdiskwrite
su PEN1 è ampia 2 GB, si potrebbe creare un profilo direttamente su questa. Se però in futuro servisse
altro spazio, si dovrà allargare la partizione. Operando come descritto, la partizione creata è già al
massimo della capacità del supporto.
Gli step operativi su macchina Windows (7-8-8.1-10) sono i seguenti:
1) Scaricare zeroshell ultima versione in formato img.gz dal sito ed estarlo, ad esempio con Winrar,
in modo da ottenere un file con estensione .IMG
2) Scaricare l'eseguibile physdiskwrite 0.5.3 (38 KB) o versione più recente da
http://m0n0.ch/wall/physdiskwrite.php ; collegare le PEN1 e 2 sulle porte USB
3) Leggere attentamente le procedure di pulizia del disco target sul sito
4) Mettere i file scaricati nella stessa directory; negli esempi a seguire sono stati posti sotto C:\
5) Lanciare un CMD amministrativo e poi diskpart al fine di pulire sia la chiavetta PEN1 prima che la PEN2 dopo (select disk (X) -> clean). Attenzione a selezionare le chiavette e non un altro disco. Pulire prima una e poi l’altra. Al termine si esce da diskpart con EXIT. Togliere PEN2 e inserirla in una porta USB del PC ZS. Non chiudere la shell amministrativa.
6) Usare ora physdiskwrite per scrivere l’immagine di ZS sulla PEN1; posizionarsi nella directory
dove sono i files eseguibile e immagine, digitare poi il comando:
physdiskwrite –u Zeroshell-(version)-USB.img
Viene mostrata una lista dei dischi sui quali poter scrivere l’immagine, attenzione a selezionare quello
giusto (in questo caso il PhysicalDrive6); compare inoltre un avviso che state scrivendo su un disco più
grande di 2 GB, digitate y poi invio, partirà la scrittura. A seconda della velocità della PEN1 occorre più o
meno tempo per il completamento dell’operazione.
Si può scollegare PEN1 e inserirla in una porta della macchina destinata ad ospitare ZS.
Accendere la macchina e verificare che parta il boot di ZS. In caso contrario, premere al POST il tasto che
nel vostro BIOS consente di scegliere il dispositivo di partenza, selezionare la PEN drive corretta e a
questo punto dovrebbe partire la shell di ZS. Attendere che sia completato il caricamento, alla fine
compare la maschera del COMMAND MENU.
L’installazione avviene tramite INSTALLATION MANAGER, opzione <A>
Si faccia riferimento alla sequenza delle schermate successive per l’installazione. Al termine togliere la
PEN1, riavviare il sistema e eseguire la configurazione iniziale di ZS da web page.
- Scelta del drive di destinazione:
- Digitare yes per sovrascrivere il disco:
- L’installazione prosegue. Viene chiesto se definire un profilo diverso da quello di default oppure
no. In questo caso è stato creato un profilo PIPPO.NET che corrisponde al dominio Active
Directory esistente (ovviamente PIPPO.NET è un fake domain). Lasciare l’IP di default; in questa
configurazione, descritta a breve, non serve cambiarlo:
Configurazione Zeroshell Si prosegue con la configurazione di ZS, utilizzando qualsiasi computer dotato di browser Internet e
scheda di rete ethernet Auto-MDI/MDIXI. Impostare sul protocollo TCP/IP della scheda del PC un
qualsiasi indirizzo sulla 192.168.0.X (esempio: 192.168.0.10, con subnet mask di 255.255.255.0) e
collegarlo con un cavo alla porta ethernet del box ZS.
Sulla barra indirizzi del browser digitare http://192.168.0.75 , deve comparire la maschera di accesso a
ZS.
Selezionare la ETH00 per creare le VLANs (Setup-Network-ETH00-Create VLAN):
Creare una dopo l’altra le quattro VLANs riportate in Tabella 1:
Assegnare l’IP ad ogni VLAN creata secondo la Tabella 1, selezionare VLAN: (x) e poi Add IP:
Il risultato finale:
Configurare il DHCP di ZS per la rete VLAN1 dell’interno 3 (LAN3) con il range indicato in Tabella 1.
E’ necessario inoltre configurare opportunamente anche la sezione DNS di ZS. Interno 3 ha dei client
Windows in dominio che acquisiscono l’IP via DHCP tramite ZS. Il DHCP restituisce ai client l’IP di ZS
come DNS primario. Questo è sufficiente per la navigazione Internet, ma i client non sanno dove andare
a prendere i domain controllers, cosi a volte non si autenticano, oppure i nuovi client non vanno in
dominio.
Inizialmente è stata creata una zona secondaria (slave) che replicava quella del DNS Active Directory, ma
questa soluzione ha creato alcuni problemi, uno per tutti che la zona su ZS non si aggiornava
correttamente per motivi sconosciuti.
Si è deciso di girare le query DNS relative dominio verso i Domain Controller Active Directory e quelle
relative ad Internet verso i DNS Fastweb, in questo modo sono spariti tutti i problemi di risoluzione AD
(in figura i DNS Fastweb per Internet e gli IP locali dei DC del dominio):
Scollegare adesso il PC di configurazione. Collegare ZS alla porta 3 di SW2 come da Tabella 2. ZS ora deve
essere raggiungibile dalle rispettive reti tramite gli IP Address impostati sulle VLANs.
Test di funzionamento Per verificare la connessione Internet si abilita il NAT sulle interfacce delle VLANs 68 e 268, le due WAN.
Si testa poi l’uscita su Internet con una o l’altra rete Fastweb impostando il default gateway di ZS prima
con il gateway della VLAN68 (192.168.1.254, ip di default del modem Fastweb) e poi con quello della
VLAN268 (192.168.2.254). Notare che se questa operazione riesce, essendo ZS il router verso Internet
dell’interno 3, quest’ultimo ha la possibilità di uscire con entrambe le reti cambiando solo il gateway di
ZS.
Impostazione NAT:
Impostazione Gateway:
ZS si collega ad Internet e aggiorna la Message board:
Cambio gateway:
ZS si collega ad Internet e aggiorna la Message board anche in questo caso, quindi può uscire su Internet
con entrambi i Gateway cambiando manualmente quello di default.
Si esegue adesso il test di raggiungibilità tra le LAN2 e 3, non dimenticando però che ZS ha la sua routing
table per tutte le reti connesse, mentre il router Asus di Interno 2 conosce solo il suo gateway e la rete
LAN2 192.168.12.0/24 (VLAN168). Per la piena comunicazione tra LANs DEVE essere inserita una rotta
statica nel router Asus per consentirgli di arrivare sulla LAN3 (VLAN1) 192.168.13.0/24 attraverso ZS che
sulla VLAN168 ha il suo IP settato a 192.168.12.10 (in figura la pagina di configurazione del router Asus,
sezione LAN, tab ROTTE, Aggiungi/Elimina):
Aggiunta la rotta sull’Asus, si procede al test di raggiungibilità tra le LAN2 e 3.
Sulle LANs sono presenti due PC con Win XP che si pingano l’uno con l’altro:
I ping hanno successo, le reti si vedono attraverso Zeroshell.
Il firewall di ZS è lasciato in default, verso Internet ci sono i due router a proteggere le reti e all’interno
non c’è ragione di impedire qualsivoglia comunicazione.
ZS come Access Point Lo ZS oggetto di questa trattazione, come mostra una delle immagini iniziali, è corredato di una pen usb
WiFi con chipset Atheros e quindi compatibile Mad-Wifi: TP-LINK TL-WN722N. Tale stick è corredato di
presa per antenna esterna, la presa è stata tolta e spostata sul pannello posteriore del box ZS.
Con tale hardware si realizza un AP ruotato.
Collegarsi alla SHELL di ZS (ad esempio con putty), dal COMMAND MANAGER digitare l’opzione <W>
Per prima cosa va settato in IT (Italia) il REGULATORY DOMAIN che di default è CN (China), OPZIONE <C>
ZS crea il device wlan0. Rispondere alle domande impostando Standard, Channel, TX Power con i valori
desiderati fino a conclusione della procedura.
Si crea adesso l’SSID dell’access point e se ne imposta la sicurezza: opzione <N>
Impostare il wifi device, mode (AP), SSID, Hide SSID (NO), WDS (NO), Encryption (3, WPA-PSK), inserire
la pre-shared key (una chiave a vostra scelta), Viene così creato l’SSID che troviamo su ZS come scheda
di rete WLAN00:
WLAN00(wlan0) (Mode:ap Sec:wpa-psk SSID:Zeroshell Status:up)
REGULATORY DOMAIN: IT (ITALY)
[wlan0] Unknown Model
-- If --- Mode -- SSID -------------------------- Hide -- WDS -- Security -
>> WLAN00 AP Zeroshell no no WPA-PSK
Ci si collega a ZS via WEB page, si imposta un ip sulla scheda WLAN00, si crea un pool DHCP per la subnet
WiFi e la scheda è operativa in modalità routed.
Ci si collega ora con un dispositivo WiFi a ZS e si esegue un ping dimostrativo di avvenuta connessione:
________________________________________________________________
Il dispositivo si collega all’AP di ZS con successo. Vale qui lo stesso discorso fatto in precedenza per il
router dell’interno 2. Sull’Asus va inserita la rotta anche per questa rete WiFi se si intende raggiungerla.
In che modalità si collega effettivamente un client sull’ AP di ZS?
Sul forum di ZS, nella sezione inglese, c’è un thread molto interessante che riguarda i default della parte
WiFi. I file di configurazione lasciano al dispositivo client la possibilità di collegarsi in WPA o WAP2, TKIP
oppure AES.
Ad oggi non ha molto senso usare troppa compatibilità, è possibile forzare da ZS connessioni WPA2 AES.
Il link al thread:
http://www.zeroshell.org/forum/viewtopic.php?t=921
Qualora non fosse chiaro come operare nella configurazione descritta in questo documento, di seguito i
comandi usati e i valori cambiati per ottenere una connessione con criteri di sicurezza recenti:
cp /root/kerbynet.cgi/template/hostapd-config/wpa-psk.conf /Database
vi /Database/wpa-psk.conf
Va individuata nel file la sezione WPA/IEEE 802.11i configuration e cambiati i valori in grassetto indicati
nelle righe seguenti:
##### WPA/IEEE 802.11i configuration #########################################
wpa=3 modificare in wpa=2 e cioè solo wpa2
wpa_pairwise=TKIP CCMP modificare in wpa_pairwise=CCMP e cioè solo AES
Attraverso lo scripting editor di ZS si forza il caricamento del file modificato pre-boot:
Seguendo le indicazioni, in effetti il client si connette con le modalità più recenti:
Obiettivi raggiunti ? Gli obiettivi richiesti in partenza sono:
- Permettere alle reti di condominio di parlarsi tra loro e accedere al SERVER1
- Un cavo libero dal centro stella alla sala server
- Zs con Access Point
- Gestione del fault di una delle due reti Internet in maniera manuale
- Rendere possibile al VOIP di Interno 1 l’utilizzo di entrambe le reti di condominio
I primi tre obiettivi sono stati raggiunti.
Nel capitolo Test di funzionamento si afferma che l’obiettivo relativo alla gestione del fault di linea è
parzialmente raggiunto. In effetti si è verificato che al momento solo Interno 3, col cambio gateway, può
comunque raggiungere Internet.
Una soluzione elegante per permettere anche ad interno 2 di uscire ugualmente su Internet in caso di
fault del proprio collegamento potrebbe essere quella di far gestire il DHCP della LAN2 a ZS piuttosto che
al router Asus. In pratica si può cambiare a livello DHCP il gateway della LAN2 che diventerebbe ZS
invece che l’Asus. Un semplice riavvio dei dispositivi connessi al router Asus risolverebbe il problema. Un
test in questo senso è stato eseguito con esito positivo, ma alla fine i condomini hanno convenuto che
ognuno vuole gestire le proprie risorse, quindi la soluzione finale si raggiunge in maniera hardware.
Fatti i controlli necessari per capire che c’è un guasto della linea, si scollega il cavo che porta la WAN2 al
switch di centro stella SW1 e lo si collega al modem Fastweb dell’interno 3 dopo aver eliminato
nell’interno 2 il collegamento tra il modem Technicolor e il router Asus. Il router Asus ha la porta WAN in
DHCP e si adatta immediatamente al nuovo gateway. Sicuramente poco elegante, ma funzionale.
Per quanto riguarda l’ultima richiesta, il VOIP della LAN1 in questo momento è configurato sul switch di
centro stella per utilizzare LAN3 e quindi WAN3.
LAN1 è collegata alla porta 5 di SW1 come UNTAGGED con PVID1 e associata a VLAN1.
In caso di caduta della WAN3 o altra necessità, si disassocia la porta 5 di SW1 dalla VLAN1, si associa poi
a VLAN168 con PVID168, sempre come UNTAGGED, ed ecco che il VOIP esce su Internet con LAN2 e
quindi WAN2.
Si può affermare che tutti gli obiettivi sono raggiunti con successo.
Il server Windows 2012 - SERVER1 Un rapido accenno alla configurazione di SERVER1.
Come già detto, il server è collegato ad SW2 tramite le porte 1 e 2 in modalità TAGGED su due NIC
diverse. Tramite Server Manager si abilita il NIC Teaming CON SINGOLA NIC. Si ha cosi il modo di
generare sulla prima NIC le schede associate alle VLANs:
L’altra NIC viene invece configurata sul virtual switch di Hyper-v non condivisa. In questo modo è
possibile definire la VLAN di appartenenza di ogni macchina virtuale direttamente nelle proprietà della
macchina virtuale stessa:
Zeroshell come macchina virtuale SERVER1 ospita una macchina virtuale che in pratica è la gemella di quella ZS descritta nel documento. A
fronte di upgrade, manutenzione, guasti sulla macchina fisica ZS, è sufficiente attivare quella virtuale e
l’utenza non si accorge di nulla, il servizio è mantenuto.
In questa realizzazione ZS non offre servizi che necessitano di certificati, perciò la macchina virtuale ha
bisogno solamente che siano replicate le configurazioni a livello rete (IP e subnet), DHCP e DNS. Per le
peculiarità di Hyper-v, ZS virtuale avrà quattro schede di rete, ognuna con il suo VLAN ID, piuttosto che
una singola NIC:
Ringraziamenti
Un sentito ringraziamento a tutti coloro che hanno avuto la pazienza di seguire il documento fino alla
fine e GRAZIE a Fulvio Ricciardi per aver messo a disposizione della comunità uno strumento veramente
potente e gratuito.
Paolo Iapilone
