Zeroshell in ufficio con Active Directory e Cloud Aruba · La realizzazione del progetto prevede...
41
1 Zeroshell in ufficio con Active Directory e Cloud Aruba By Paolo Iapilone [email protected] Febbraio 2015
Transcript of Zeroshell in ufficio con Active Directory e Cloud Aruba · La realizzazione del progetto prevede...
1
Zeroshell in ufficio con Active Directory e
Cloud Aruba
By Paolo Iapilone
Febbraio 2015
2
Sommario Scopo del documento ............................................................................................................................... 3
Le richieste ................................................................................................................................................ 3
Descrizione della realizzazione ................................................................................................................. 4
Realizzazione: Schema di rete adottato .................................................................................................... 5
Realizzazione: Installazione ZS .................................................................................................................. 6
Realizzazione: Configurazione switch Managed (Netgear GS108T) ......................................................... 6
Tabella 1 – Dati per configurazione Switch Managed .............................................................................. 6
Realizzazione: Indirizzamenti, VLANs, SSID ............................................................................................... 7
Tabella 2 - Indirizzamento e VLANs .......................................................................................................... 7
Realizzazione: Configurazione Zeroshell ................................................................................................... 8
Realizzazione: l’Access Point HP Procurve MSM422 .............................................................................. 14
Realizzazione: l’ambiente Windows Server ............................................................................................ 17
Zeroshell su Cloud Aruba ........................................................................................................................ 26
Ringraziamenti ........................................................................................................................................ 41
3
Scopo del documento Il presente documento illustra la realizzazione di una rete dati in un ufficio di piccole-medie dimensioni,
usando Zeroshell (ZS) su hardware Pc Engines. Verrà fatto uso del protocollo 802.1Q, quindi di VLANs e
switch managed. Per la connessione WiFi si userà un prodotto della HP, un Access Point della serie
MSM422. Data la tipologia delle richieste progettuali, si rende indispensabile Windows 2012R2 Standard
Edition per i servizi di Hyper-v, Active Directory (AD), RADIUS, Certification Authority (CA), DNS, Network
Policy Server (NPS), file server (FS).
Infine si propone una soluzione alternativa a quella completamente on-site, mettendo in Cloud i server
di AD e utilizzando in loco un software free per realizzare un NAS che prende il posto del file server, allo
scopo di risparmiare sui costi hardware, delle licenze e sulla manutenzione. ZS su entrambi i siti fungerà
da connettore VPN Site to Site.
Questa soluzione è stata comunque scartata per motivi che saranno chiariti in seguito.
Quanto trattato nel documento è preso dall’ambiente di laboratorio, il contesto messo in produzione
differisce per alcuni dettagli. Non verrà ad esempio fatta menzione dei sistemi e delle modalità di
backup dei dati, del patching, sugli UPS, seppure presenti. Non è intenzione di chi scrive fornire una
soluzione chiavi in mano, quanto di stimolare chi legge ad approfondire i vari argomenti e comunque di
dare una ulteriore prova, qualora ce ne fosse bisogno, che ZS è un sistema molto flessibile e che può
essere usato in contesti produttivi.
Le richieste Vengo contattato da un amico che, insieme a due soci, ha una ditta che lavora profilati plastici.
L’ufficio conta i tre soci fondatori, due segretarie e tre impiegati; dispone di due connessioni Internet,
una in fibra a 100Mb/10Mb ed una ADSL standard a 5 Mb/512kb, occorrono tre stampanti di rete.
Le due segretarie e i tre impiegati hanno dei pc desktop, i tre soci dei portatili, tutte le macchine sono
dello stesso brand. Il sistema operativo è Windows 8.1 Professional, antivirus e antispyware installati.
Attigua all’ufficio c’è la zona di produzione con le macchine CNC, vi lavorano circa 10 operai.
Mi viene chiesto se è possibile avere:
- la rete internet in fault tolerant
- una rete cablata per l’ufficio in modo da avere le stampanti e altre risorse condivise
- una rete WiFi di buone caratteristiche dedicata alla zona ufficio alla quale si possono collegare
solo i pc dell’ufficio
- una rete WiFi da dedicare ai dispositivi mobili, compresi quelli di eventuali ospiti, che veda solo
ed esclusivamente Internet, quindi “blindata”
- cartelle dati in rete, personali e condivise, per la zona ufficio;
- Single Sign On (SSO) per accesso rete e dati condivisi.
4
Descrizione della realizzazione La realizzazione del progetto prevede l’uso di ZS su hardware APU1D e di Windows Server, quindi Active
Directory.
ZS avrà le seguenti funzioni:
- Fault tolerant verso internet;
- Gestione delle diverse VLAN previste nella soluzione;
- Invio email a fronte di problematiche di rete e non solo;
- Firewall e blindatura della rete dedicata ai dispositivi mobili e ospite;
- Servizi di rete (DHCP,DNS,ecc);
- VPN Site to Site verso il Cloud (solo a scopo test).
Per la sezione WiFi si utilizza, come anticipato, un Access Point di categoria Enterprise, il produttore è HP
e il modello è MSM422. L’apparato sarà configurato in multi SSID per generare appunto due SSID,
ognuno su una VLAN dedicata, al fine di dedicarne uno per i soli mobile e ospiti.
Per la rete fisica è previsto un switch Netgear della serie Prosafe a 24 porte 10/100/1000, il quale
assicura la connettività verso i vari pc fissi e le postazioni, mentre la creazione delle varie VLANs è
affidata ad un switch managed Netgear GS108T e a ZS, che in questo caso utilizza il protocollo 802.1Q
per la comunicazione. I laptop sono configurati a livello BIOS in modo che se usano la connessione
cablata la radio WiFi si spegne, per evitare che assumano un doppio IP di rete. Non tragga in inganno lo
schema di rete a seguire, i laptop possono connettersi indifferentemente alla LAN o al WiFi.
Il server viene costruito partendo dai singoli componenti, acquistati ridondati qualora si presenti un
fault. Fondamentalmente è un Quad Core Intel I5 con 16 GB di RAM. Come anticipato, viene installato
Windows Server 2012R2 Standard, che consente la virtualizzazione di due ulteriori macchine; queste si
dividono i ruoli necessari per la soluzione adottata, quindi Domain Controller (DC), DNS, CA, NPS, mentre
il server fisico avrà il ruolo di hypervisor Hyper-v e di FS.
L’utilizzo di Windows Server si rende necessario per svariati motivi. Ad esempio per il SSO, così come per
la gestione degli accessi WiFi tramite la modalità scelta, cioè WPA Enterprise e quindi accesso RADIUS.
Non nascondo che personalmente avrei voluto realizzare la cosa con ZS e il suo server RADIUS, semplice
da implementare e gestire, ma per quanto ne sò questo non consente di poter definire policy di accesso
agli Access Point (AP) e quindi alla rete.
Deve esserci un “gestore”, qualcuno che si occupi delle politiche di accesso.
Windows Server 2012R2 lo fa in maniera nativa con il ruolo di NPS, quindi verranno implementati i ruoli
di NPS e Certification Authority (CA) indispensabili per questa funzione.
Nel caso in oggetto, con l’installazione del ruolo NPS si avrà a disposizione un server RADIUS che decide
quale AP virtuale accetterà la connessione del client supplicant. Se il dispositivo WiFi è un pc di dominio
AD potrà utilizzare tutte le WiFi, anche se con quella dedicata al Mobile non vedrà le rete interna. Se
non è di dominio, verrà chiesta l’autenticazione utente e potrà usufruire soltanto della connessione WiFi
dedicata ad Internet. RADIUS accetta o meno il client sull’ AP, ZS col suo DHCP gli assegna i corretti
parametri di rete.
5
Realizzazione: Schema di rete adottato
6
Realizzazione: Installazione ZS Si faccia riferimento al seguente documento che illustra l’installazione di ZS su hardware APU:
https://dl.dropboxusercontent.com/u/34684612/inst%20su%20apu_v2.0.pdf
Realizzazione: Configurazione switch Managed (Netgear GS108T) Nel seguente documento ho già trattato come si configura il switch in questione nell’ambito di una
diversa realizzazione:
https://dl.dropboxusercontent.com/u/34684612/ZS%20and%20802.1Q.pdf
I dati necessari alla configurazione del switch in questo contesto sono l’assegnazione delle VLAN e delle
porte come da tabella seguente. La colonna T/U specifica se la relativa porta è Tagged oppure Untagged.
Tabella 1 – Dati per configurazione Switch Managed
Porta T/U PVID VLAN Dispositivo
1 U 1 1 Switch 24 porte Workers
2 U 1 1 server
3 U 1 1 server
4 U 1 1 free
5 U 68 68 Wan Fastweb
6 U 268 268 Wan TIM
7 T don't care 1-10-20 Access Point
8 T don't care 1-10-20-68-268 ZS
Al server vanno due link, uno per il S.O. e uno per il switch virtuale di Hyper-v, come da best practice
Microsoft. Una porta rimane libera.
Consiglio di preconfigurare il switch collegando la porta 1 ad una network esistente e dove vi sia un
DHCP; il switch si prende l’indirizzo, lo configurate e come ultima operazione gli viene assegnato l’IP
definitivo, così da essere subito operativo appena viene inserito nella rete che deve gestire. L’indirizzo
da assegnare è nella tabella della sezione successiva.
7
Realizzazione: Indirizzamenti, VLANs, SSID
Tabella 2 - Indirizzamento e VLANs
VLAN Subnet (/24) Static IP DHCP Range
Lease Duration
1 192.168.5.0
192.168.5.75 - ZS 192.168.5.100 – Server Fisico (Server2k12-4) 192.168.5.101 - Switch managed 192.168.5.102 - Access Point MSM422 192.168.5.105 - DC1 (virtuale, Server2k12-5) 192.168.5.106 - DC2 (virtuale, Server2k12-6) 192.168.5.107 - MIONAS01 (solo per test)
150 - 200 8 - 12h
10 192.168.10.0 192.168.10.102 - SSID - Fantasy_Workers 150 - 200 8 - 12h
20 192.168.20.0 192.168.20.102 - SSID - Fantasy_Mobile&Guests 150 - 200 1h
68 192.168.1.0 192.168.1.250 - ZS 192.168.1.254 - Router Fastweb
nessuno n/a
268 192.168.2.0 192.168.2.250 - ZS 192.168.2.254 - Router TIM
nessuno n/a
La tabella indica che:
- Sono utilizzati due Access Point virtuali i cui SSID sono: Fantasy_Workers per la connessione dei
pc di dominio, Fantasy_Mobile&Guests per tutti gli altri dispositivi WiFi; ogni AP virtuale ha il
suo IP nella relativa sottorete (VLAN 10 e 20); il dominio Active Directory creato è
FANTASY.COM;
- L’Access Point fisico è configurato per avere l’IP sulla subnet 192.168.5.0 (192.168.5.102), su
questa viaggia tutto il traffico di management dell’ AP e i dati di autenticazione RADIUS;
- VLAN 1: è la VLAN master cablata dove sono attestati i dispositivi di infrastruttura e i pc, non
sono indicate le stampanti e altri dispositivi;
- VLAN 10: è la VLAN dedicata al WiFi dei pc di dominio; solo macchine registrate in dominio
possono usare questa rete senza fili; vede le stesse cose che vede la rete infrastrutturale VLAN1;
- VLAN 20: è la VLAN dedicata a tutti i dispositivi mobili e ospite; questa VLAN vede solo ed
unicamente Internet, inoltre a livello DHCP ha un lease più basso, un’ora, per evitare la
saturazione degli indirizzi. I vari dispositivi mobili degli operai e degli ospiti useranno
necessariamente e soltanto questa rete. Non è previsto che un pc ospite possa collegarsi alla
rete cablata. Sono previste utenze specifiche in AD per i guests alle quali viene cambiata spesso
la password, gli operai hanno i loro account personali registrati in Active Directory, gli accessi
sono registrati nella log del server che ha il ruolo di NPS.
- Le VLAN 68 e 268 sono quelle dei gateway verso Internet; la 268 è la rete TIM, la 68 è la rete
Fastweb; ZS provvede al fault tolerant con Fastweb, la più veloce, come Active.
8
Realizzazione: Configurazione Zeroshell Sempre nel documento linkato in precedenza, cioè:
https://dl.dropboxusercontent.com/u/34684612/ZS%20and%20802.1Q.pdf
si possono trovare tutte le indicazioni necessarie per configurare ZS in maniera corretta quando si
utilizza il protocollo 802.1Q, cioè con le VLAN. Ci sono però alcuni settaggi specifici per questa
realizzazione che vale la pena di mostrare in dettaglio.
In primo luogo si verifichi che l’orario di ZS sia impostato correttamente (System->Setup->Time).
Considerata la presenza di una rete ospite, è necessario configurare gli accessi a ZS in maniera corretta.
Si consente l’accesso alla pagina Web e SSH di ZS solo ai pc infrastrutturali, togliendo l’auto
autorizzazione delle LAN:
In particolare per l’ SSH si consente accesso solo dalla rete cablata:
Stessa cosa per l’accesso al DNS, solo infrastruttura e WiFi privilegiato può inoltrare query:
9
A livello DNS inoltre si impostano i forwarders che corrispondono ai DNS dei due provider di servizi:
Configurare il DHCP, creando e configurando le tre subnet dove il servizio risponderà alle richieste client:
La parametrizzazione si esegue considerando che:
- La rete 20 avrà solo DNS esterni (Google e OpenDNS in questo caso), inoltre il suo lease time
sarà di un’ora;
- Le altre reti avranno come DNS i due DC Windows e un lease time di 8 – 12 ore:
10
11
Si configuri il failover; essendo due le reti che vanno su internet, le NAT interfacce devono essere due,
cioè entrambe le VLANs internet:
Il failover è semplice da configurare; il Failover Monitor è lasciato a default, mentre come Failover IP
Addresses ho inserito i DNS dei due provider; impostare i corretti pesi delle interfacce:
12
Fulvio Ricciardi sul suo ZS ha previsto un applicativo che lancia email a fronte di eventi; credo che nulla
sia più utile come semplice strumento di monitoring a fronte di cadute della linea internet e non solo.
Magari stiamo compiendo operazioni che impegnano poco la rete internet e la Master ha un fault, una
email ci avvisa della cosa forse anche prima che ce ne accorgiamo:
Ho notato che gli indirizzi di posta elettronica Tiscali danno meno problemi di Google quando cambia l’IP
di provenienza. Forse la cosa riguarda solo la mia situazione, ma ho preferito usare Tiscali Mail. Non si
dimentichi di configurare i Recipients, cioè gli indirizzi ai quali volete inviare le notifiche. Dalla figura
risulta chiaro che non ho abilitato tutti gli avvisi ma solo quelli realmente necessari.
Rimane da configurare il firewall partendo da poche regole:
Chain Input:
- VLAN 20, quella relativa ai mobile e ospiti, rete blindata: in input su ZS non deve entrare nulla;
tramite DHCP il DNS viene preso all’esterno, quindi si può bloccare tutto il traffico in input;
- VLAN 68 e 268: sono le due WAN, in Input deve entrare solo il traffico eventualmente creato
verso l'esterno dal router, quindi le connessioni Related e Established;
13
Chain Forward:
- da qualunque origine verso le due VLANs 68 e 268 (internet) passa tutto, nuovo traffico e i
pacchetti di risposta;
- tutto il traffico generato dalla VLAN 20 CHE NON VA verso internet, quindi eventuale traffico
verso le altre VLAN della rete, viene droppato:
Ho controllato queste regole con diversi scan tramite NMAP e sembrano funzionare correttamente. Se
chi legge trovasse qualche errore o avesse idee diverse sulle regole, è invitato a scrivermi; l’indirizzo
email è riportato in prima pagina del presente documento.
Ora, sebbene con le regole mostrate la VLAN 20 sia in teoria completamente bloccata a livello INPUT, dai
test eseguiti risulta che i client autenticati, sia WPA Enterprise che WPA Personal (questa modalità è
stata temporaneamente usata a solo scopo di controprova), riescono a prendere normalmente
l’indirizzo IP.
Il protocollo DHCP prevede scambio di dati tramite broadcast e UDP, porte 67 e 68, che in teoria
dovrebbero essere chiuse dal firewall.
Se sembra strano il fatto che nonostante il blocco totale in input i client della VLAN 20 ricevano
ugualmente l’IP Address senza nessuna regola specifica sul firewall, invito a leggere questo thread sul
forum ZS:
http://www.zeroshell.net/forum/viewtopic.php?t=5610
14
Realizzazione: l’Access Point HP Procurve MSM422 Questo è un prodotto di classe Enterprise, una macchina capace di fare tante cose; se non avete mai
configurato un AP di questa fattura, allora potrebbe risultare complicato lavorarci. Per dire, il manuale di
amministrazione conta 130 pagine circa. Ne consiglio caldamente il download e un buon
approfondimento:
http://kmcs-service.austin.hp.com/km-ext/kmcsdirect/emr_na-c03127685-1.pdf
E’ stata scelta una macchina di questa classe al fine di disporre di una connessione WiFi degna di questo
nome, che non soffrisse con 10 client connessi e che garantisse sia affidabilità che stabilità. Copre
tranquillamente l’ufficio e la zona di produzione di questo progetto. Dispone di doppia sezione radio e
può funzionare contemporaneamente sulle bande 2.4 e 5 GHz. Nel nostro caso si userà solo la banda a
2.4 GHz.
Gli step da percorrere per la configurazione sono quelli di qualunque altro AP capace di MultiSSID:
- set dell’IP Address, della rete e dell’ora;
- inserimento in VLAN;
- set delle due sezioni radio;
- creazione degli Access Point virtuali e associazione alle VLAN stabilite;
- configurazione dell’autenticazione RADIUS.
Non entro nel dettaglio della configurazione. Non me ne voglia chi legge, ma come già detto in
precedenza, questo documento non vuole essere una guida a come si realizza un progetto di networking
step-by-step.
Qualcosa di interessante va comunque mostrato, ad esempio quanto in figura successiva. Nella sezione
opportuna è stata impostata la VLAN 1 come default VLAN; l’AP prevede due ulteriori settaggi (entrambi
abilitati):
- viene forzato il passaggio dei dati di management alla VLAN di default; in questo modo anche il
traffico di autenticazione RADIUS viaggerà su quella VLAN pur se proveniente, ad esempio, dall’
AP virtuale sulla VLAN 10 o 20. Sul firewall non sarà necessario impostare regole per il colloquio
RADIUS trovandosi gli apparati sulla stessa rete VLAN1;
- sulla porta si può far viaggiare traffico anche untaggato, comodo in caso di manutenzione:
15
Nella sezione VSC (Virtual Service Communities) vengono definiti gli APs. Efficacissimo il colpo d’occhio,
che consente di conoscere importanti informazioni:
In dettaglio il VSC relativo ad uno degli SSID. Sono evidenziati il blocco traffico tra i device connessi in
WiFi (questa è la rete dei mobili, tra loro non si vedono) e la parametrizzazione del Called-Station-ID,
impostato, come spesso si usa in ambito pro, nella forma mac Address:ssid.
16
Una panoramica della configurazione delle sezioni radio.
E’ possibile selezionare antenne esterne, tre per la radio 1 e una per la radio 2.
E’ possibile stabilire quanti client al massimo possono collegarsi su quella determinata radio, il massimo
sono 256.
Nell’uso pratico la macchina ha dimostrato un’ottima stabilità e una grande capacità di carico.
17
Realizzazione: l’ambiente Windows Server In questa sezione verranno trattate solo le personalizzazioni eseguite nell’ambiente. Si dà per scontato
che chi legge conosca Windows Server e sappia installare e configurare un’ambiente Active Directory.
Va detto che per la realizzazione del server fisico è stato scelto di usare due HD SSD da 256 GB (Samsung
Pro) in RAID 1 per il sistema operativo e i due DC virtuali in Hyper-v, mentre la sezione di storage dati
vede due HD rotativi da 3 TB della serie rossa Western Digital, quelli specifici per i NAS, sempre in
mirror. Chiaramente è presente un UPS. I volumi sono tutti criptati tramite Bitlocker.
La macchina dispone di una scheda di rete dual port Intel E1000, al fine di arrivare al switch managed di
gestione con una porta dedicata al management e allo scambio dati, l’altra dedicata al virtual switch di
Hyper-v.
Ho seguito la seguente scaletta di operazioni:
- Installazione server fisico, patching e cambio nome (Server2k12-4)
- Installazione e configurazione ruolo Hyper-v, installazione feature di Bitlocker, criptazione dischi
- Creazione delle macchine virtuali, patching e cambio nome (Server2k12-5 e Server2k12-6)
- Promozione a Domain Controller di Server2k12-5 e Server2k12-6, creazione nuova foresta di
dominio Fantasy.com durante la promozione del primo DC
- Installazione e configurazione del ruolo CA sul Server2k12-5 e NPS sul Server2k12-6
- Configurazione DNS e altro
- Modifica di alcune GPO, registrazione in dominio del Server2k12-4, verifica Event Viewer
- Creazione utenti e gruppi in AD
- Creazione cartelle dati utente e dati condivisi, sharing dei dati (sul server fisico).
Sulle GPO va detto che una in particolare andrebbe sempre modificata. E’ quella relativa a chi ha i diritti
di registrazione delle macchine in dominio. Non tutti sanno che di default gli Authenticated Users,
praticamente tutti gli utenti di dominio, possono registrare nuove macchine. Non mi sembra opportuno,
quindi in genere modifico i diritti e li riservo ai Domain Admins:
18
Quando tutte le macchine server sono in dominio, prima di procedere alla creazione degli utenti e
gruppi è sempre bene verificare gli event viewer alla ricerca di errori e risolverli subito. Non è bello
trovarsi con dei DC che non replicano o problemi di varia natura. Per correttezza e professionalità si
deve sempre rilasciare un ambiente privo di errori.
In laboratorio ho inserito in AD pochi utenti rispetto alla realtà. In figura si può notare l’utente
WiFiguest1. Questa è una delle utenze da fornire a eventuali ospiti per farli accedere a Internet.
L’amministratore si occupa di cambiare le password relative alle utenze guest alla fine del loro utilizzo e
comunque una tantum. WiFiguest1 fa parte del gruppo No-Computer-Access, al quale è negato il diritto
di LOG ON LOCALLY sui computer di dominio attraverso una specifica policy. Questo al fine di evitare
che un estraneo a conoscenza della password dei guest possa fare logon su un computer lasciato
incustodito, usufruendo dei servizi di rete dedicati ai workers:
Verifica del corretto funzionamento: si tenta l’accesso ad un pc della rete con l’utente WiFiguest1:
19
Come ci si aspetta, l’accesso è negato:
Mentre invece l’utente Carlo Carli, amministratore locale del pc, entra senza nessun problema:
Gli accessi alle reti WiFi sono sono autorizzati nel seguente modo:
- WiFi sulla rete dei Workers: si ha accesso a tutte le risorse locali e Internet. Questo può avvenire
solo se richiesto da un pc registrato in dominio, qualunque altra macchina non entra. Questa
scelta è stata fatta in quanto la logica vuole che se un pc di dominio richiede un accesso WiFi, vi
sia loggato (o si loggerà) un utente di dominio e quindi autorizzato; come è stato appena
illustrato, una policy specifica non permette agli utenti guest di loggarsi sui pc, quindi scegliere
di autorizzare l’accesso basandosi sul computer richiedente è un modo abbastanza sicuro;
- WiFi sulla rete per i Mobili: si deve disporre di una utenza di dominio e si accederà solo ed
esclusivamente ad internet, nessun servizio di rete è previsto. RADIUS è senza meno tra i
protocolli di autenticazione più sicuri e robusti, non ci si aspettano accessi non autorizzati.
Dell’ autorizzazione si occupa il server RADIUS dove sono definite le regole per gli accessi. Prima di tutto
vanno registrati i RADIUS Clients (i due APs virtuali); notare l’IP identico. Come spiegato in precedenza in
merito al dispositivo, questo può usare un singolo IP sulla rete master:
20
Fornisco il link a un paio di video su Youtube dove si spiega l’installazione e la configurazione di un
server RADIUS su base Windows, potrebbero risultare utili:
https://www.youtube.com/watch?v=MYKI49eL0VY
https://www.youtube.com/watch?v=qeTMlFLZlLM
Si configuri quindi il server RADIUS scegliendo come opzione quella indicata (RADIUS server for 802.1x
Wireless or Wired Connections) e cliccando su Configure 802.1X:
Nel wizard che parte, si scelga Secure Wireless Connections e si crei la prima network policy Fantasy
Workers:
21
Si verifichi che siano mostrati gli AP definiti in precedenza:
Aggiungere l’authentication method EAP-MSCHAP v2, poi cliccare più volte next e infine finish.
Nelle proprietà della network policy appena creata si aggiunga il metodo di autenticazione EAP (PEAP):
22
Si ripetano le stesse operazioni per creare la network policy Fantasy Mobile&Guests.
Abbiamo ora le nostre regole di accesso WiFi definite, dobbiamo aggiungere nelle proprietà di ognuna le
condizioni che ci occorrono:
Fantasy Workers:
Le condizioni per l’accesso alla rete sono che la richiesta sia di tipo wireless, che provenga da uno dei
Domain Computers di Fantasy e che la Called Station ID sia Fantasy_Workers$. Nel capitolo relativo
all’Access Point ho specificato che il formato da mandare al server RADIUS per il parametro di
riconoscimento dell’ Access Point, appunto Called Station ID, valeva mac:ssid. Il $ signiifca che viene
fatta una operazione sulla stringa lato server e eliminato il mac, quindi si usa solo l’SSID.
Fantasy Mobile&Guests:
Le condizioni per l’accesso alla rete sono che la richiesta sia di tipo wireless, che provenga da uno dei
Domain Users di Fantasy e che il Called Station ID sia Fantasy_Mobile&Guests$.
Nessun altro tipo di accesso è permesso al di fuori di quello controllato da queste due regole.
23
Una ultima cosa su NPS: non funziona bene senza Certification Authority e deve essere registrato in
AD. Se la casella indicata non è in grigio, va registrato (si clicca semplicemente su registra in AD):
Per finire, di seguito le catture di due dispositivi mobili, un Winphone ed un Android, collegati alla rete
dedicata.
24
Passiamo al file server; per le condivisioni sfruttiamo la Access-based enumeration, che consente di far
vedere agli utenti soltanto le risorse condivise su cui hanno almeno il permesso di read:
Questo semplifica notevolmente anche l’aspetto della gestione delle share.
E’ stata condivisa, sul file server, la cartella DATI contenente le cartelle utente e quella comune in
modalità everyone-full control:
25
Si è quindi agito a livello di permessi NTFS sulle singole cartelle in modo da bloccare l’ereditarietà dei
permessi, poi ad ogni cartella sono stati assegnati i permessi NTFS opportuni.
L’utente CarloC dal suo pc entra nella share DATI e vede solo le cartelle su cui ha i diritti almeno in
lettura, le altre risultano invisibili:
26
Zeroshell su Cloud Aruba Come scritto nell’introduzione, ho tentato di proporre una realizzazione che si basava su Cloud.
In pratica i due DC sarebbero andati in remoto insieme ad una istanza di Zeroshell che avrebbe fatto da
connettore VPN site to site per far comunicare Cloud e ufficio.
Dato che Aruba permette di installare sul suo Cloud anche macchine virtuali personalizzate, la scelta è
andata verso questo provider di servizi.
Il basso traffico di rete, il fatto di risparmiare parecchi soldi per la licenza di Windows Server, per
l’hardware server ridondato, l’affidabilità garantita da Aruba per i servizi (SLA al 99.8% se non sbaglio),
potevano spingere verso questa direzione.
I soci però hanno deciso per la soluzione in casa, non se la sono sentita di dipendere così tanto dalla rete
Internet. Tempo fa hanno subito un guasto sulle linee che li ha lasciati senza telefono e senza ADSL per
diversi giorni, quindi la soluzione non li ha convinti.
Dato che un ambiente di prova è stato costruito per far vedere ai committenti come funzionava, lo
propongo a puro scopo divulgativo.
Si deve avere un account su Aruba Cloud; verranno “regalati” 10 euro per provare il servizio. Consiglio di
prendere confidenza con l’applicazione e navigarci bene e a fondo prima di creare qualsiasi cosa. In
questo caso sono state installate due macchine virtuali: Zeroshell e un Windows Server 2012R2, su
piattaforma Hyper-v low cost.
E’ stato creato un virtual switch per farle comunicare in rete di backend, mentre Zeroshell disponeva di
un IP pubblico; la figura mostra quanto realizzato e testato:
27
Aruba Cloud dà la possibilità, tramite un servizio ftp, di eseguire l’upload di dischi virtuali VHD oppure
VHDX in maniera da poter generare delle macchine virtuali personalizzate. ZS è stato installato e
configurato come macchina virtuale sul server di laboratorio, poi è stato caricato su Aruba. Gli step di
creazione della macchina su un Hyper-v locale possono essere cosi riassunti:
- Creare un disco di tipo VHD da 4-8 GB con il Disk Manager di Windows;
- creare una macchina virtuale avente come hard disk il VHD creato in precedenza; le schede di
rete devono essere tre, la eth0 sarà la scheda destinata ad intenet, la eth1 alla management, la
eth2 non verrà usata. Quando su Aruba si crea una macchina virtuale, gli vengono assegnate di
default tre schede di rete e la eth0 è usata dai loro sistemi per assegnare l’IP pubblico.
Assegnare una cpu e 1 GB di RAM.
- Avviare la vm ZS; entrare in configurazione e abilitare SSH; per SSH e WEB è fondamentale che
non vi siano restrizioni di alcun tipo in relazione all’IP che tenta di stabilire una connessione:
- Fatta questa prima configurazione, si può spegnere la macchina ed eseguire ftp del suo disco
VHD su Aruba.
- Eseguito l’ftp, si può creare la macchina virtuale Zeroshell sul Cloud specificando che l’hard disk
è sull’ftp; per le prove ho usato la piattaforma hyper-v low cost. Notare che essendo una
macchina personalizzata, non verrà assegnato in automatico nessun IP, dovremo configurare a
mano sia la rete pubblica che la backend.
- Acquistare un IP pubblico nel Cloud e prendere nota di IP, mask e gateway;
- assegnare tale IP alla macchina virtuale tramite “GESTISCI” del pannello di gestione di Aruba
(figura successiva):
28
- Entrare nella console di ZS tramite la console di ripristino Aruba:
- impostare IP pubblico e gateway sulla scheda eth0 di ZS tramite IP Manager della console ZS
A questo punto ZS deve essere raggiungibile sia con http che con SSH tramite il suo IP pubblico, come da
figure successive:
29
30
Vediamo ora di creare la VPN site to site tramite Openvpn che metterà in comunicazione le macchine sul
Cloud con quelle dell’ufficio.
Si rivela utilissimo, in tal senso, un documento presente sul sito di ZS, scritto da Cristian Colombini. Il
documento è reperibile al seguente link:
http://digiLANder.libero.it/smasherdevourer/schede/linux/Zeroshell%20VPN.pdf
Su questo documento c’è tutto quello che serve per realizzare la VPN; è un po’ datato e quindi le
schermate non sono proprio uguali, ma con un po’ di attenzione si riesce ugualmente a seguirlo.
Colombini crea la VPN usando i certificati per l’autenticazione. Nelle release più recenti di ZS, c’è la
possibilità di usare una shared key. Personalmente ho creato prima la VPN in questo modo, cioè con la
shared key, quando poi funzionava tutto sono passato ai certificati:
Una precisazione: lato VPN ruolo SERVER, quindi sulla macchina in Aruba, mettere come Remote Host
l’IP 0.0.0.0, come da post sul forum di Zeroshell a questo link:
http://www.zeroshell.net/forum/viewtopic.php?t=586
31
La figura mostra che la VPN si è avviata (al primo colpo) senza nessun problema:
Per far transitare correttamente i dati bisogna dire ai due router dove stanno le reti, quindi vanno
generate le rotte statiche. Nel mio caso, lato ZS su Aruba, ho messo la rotta per la network dove stanno
le macchine dell’ufficio (gli endpoint della VPN sono 192.168.100.1 su Aruba e 100.2 in ufficio):
Ho poi messo la route corretta sullo ZS presente in ufficio per raggiungere la rete lato Aruba:
32
Tramite le utilities di ZS ho verificato dall’ufficio che l’IP di management di ZS sulla rete remota di Aruba
fosse raggiungibile correttamente:
Ora si può cambiare l’autenticazione della VPN in X.509 usando i certificati, se ritenuto opportuno. La
shared key potrebbe essere sufficiente, ma X.509 è sicuramente preferibile.
Ora su Aruba Cloud dobbiamo creare il virtual switch di backend per far comunicare ZS con il server
Windows che installeremo a breve.
Dal pannello di gestione di Aruba creare il virtual switch:
33
Creare ora il server Windows su Aruba Cloud.
La creazione assocerà anche un ulteriore IP pubblico alla macchina, che ci sarà utile per accedere subito
ad essa.
Quando la macchina è installata, collegare la sua scheda eth1 al virtual switch di backend dal pannello di
gestione Aruba. Entrare in desktop remoto via IP pubblico e configurare la eth1 di backend in modo che
comunichi con ZS. I parametri usati sono:
- IP: 192.168.0.76
- Mask: 255.255.255.0
- Gateway: 192.168.0.75 (ZS)
- DNS: 192.168.0.75 (ZS)
In questo modo garantiamo, tra le altre cose, che una volta che avremo eliminato l’IP pubblico dal server
Windows, questo userà la connessione Aruba per andare su internet (il gateway è ZS), senza passare per
la VPN. Dato che l’IP pubblico ha un costo, nel momento in cui si può raggiungere il server sulla rete di
backend l’IP pubblico non serve più. Dovesse cadere ZS o la VPN, c’è sempre la console di emergenza su
Aruba Cloud per raggiungere il server:
34
Verificare che il server Windows veda innanzitutto ZS, ad esempio con PING, infine verificare che
raggiunga l’ufficio remoto.
Dall’ufficio remoto eseguire gli stessi controlli e stabilire una connessione di desktop remoto verso il
server Windows. Se avete problemi, prima di tutto disabilitate il firewall del Windows Server.
Ora che si ha la sicurezza della raggiungibilità incrociata si può eliminare l’IP pubblico e installare i ruoli
sul server. Questi sono quelli già elencati per la realizzazione on site, cioè:
- Active Directory (dominio creato per l’occasione: Aruba-Fantasy.local)
- DNS
- CA
- NPS
che per questo test sono tutti sulla stessa macchina (sconsigliatissimo da Microsoft).
Al termine vanno configurati i servizi, create le policy NPS, creati gli utenti, così come esposto nei
capitoli precedenti.
C’è da fare una ulteriore modifica su ZS in ufficio.
Mentre nella realizzazione on site il DHCP è configurato in modo da fornire ai client i due DNS di
dominio, avere un Domain Controller in remoto significa che tutte le query DNS, sia locali che per
Internet, transiterebbero sulla VPN qualora il DHCP imponesse l’uso del server di AD come DNS Internet.
Si configura il DHCP in modo che sia il gateway che il DNS fornito ai client sia ZS; impostando la sezione
DNS Forwarders di ZS in ufficio con la modalità della figura seguente, si evita che per le query di
navigazione internet si usi il Domain Controller, al quale verranno forwardate le sole query relative al
dominio.
DNS Forwarders:
35
DHCP Settings:
In questo laboratorio le regole del firewall non sono state implementate per rendere la realizzazione piu
semplice.
Lato Access Point e WiFi si replica quanto già esposto nei capitoli precedenti.
Le due immagini successive mostrano:
- La prima come uno dei pc dell’ufficio si è tranquillamente registrato in dominio
- La seconda mostra l’utente Elio connesso al pc.
Si evince che la registrazione del pc in Active Directory, l’accesso utente e alla connessione WiFi sono
stati autorizzati/autenticati dal Domain Controller/RADIUS in Cloud su Aruba:
36
37
Per quanto riguarda lo storage, ovviamente in questo contesto è improponibile l’idea di mettere i dati
utente e comuni su Cloud, perlomeno con le velocità dell’attuale connessione.
Quindi i dati vengono memorizzati e condivisi su un NAS locale che autentica gli utenti sul DC in Cloud,
classica situazione da Hybrid Cloud.
L’utilizzo del DC remoto ha consentito di risparmiare l’acquisto di una licenza Microsoft, quindi piuttosto
che usare un server Windows per il NAS locale, si è cercato un software libero che però si interfacciasse
con Active Directory e fosse affidabile.
E’ stato scelto NAS4FREE tra una rosa di candidati che comprendeva tre software NAS open source.
NAS4FREE, a mio modestissimo parere, è un buon software NAS basato su Freebsd. Ha una larga
comunità alle spalle, come Zeroshell, inoltre fornisce parecchi servizi senza bisogno di pacchetti
aggiuntivi.
Uno dei motivi della scelta di questo software è che si riesce senza problemi a renderlo virtuale su
Hyper-v, che è poi la tecnologia con cui realizzo i laboratori.
Gli altri due software che ho testato, cioè FREENAS e OPENFILER, hanno dato problemi di schede di rete
non trovate, anche usando le schede Hyper-v di tipo legacy, quindi sono stati scartati. Inoltre risultano
più esosi in termini di risorse hardware necessarie ad un buon funzionamento.
Già durante il boot di NAS4FREE si può notare come il pacchetto degli Integration Services di Hyper-v sia
presente:
Per l’installazione e la configurazione di NAS4FREE rimando alle wiki del progetto:
http://wiki.nas4free.org/doku.php
La schermata successiva mostra i servizi che fanno parte del pacchetto base:
38
In questo caso si utilizza il servizio di CIFS/SMB insieme ad Active Directory.
Cliccando sul tab Access vi è la possibilità di configurare AD e registrare la macchina in dominio; a quel
punto si usa il DC per i permessi e le autenticazioni.
39
Rimando anche in questo caso alle wiki per i dettagli di configurazione.
Si mostra nelle figure di seguito come gli utenti vedono e accedono/non accedono alle share.
Chiaramente sono stati assegnati ereditarietà e permessi NTFS alle cartelle in base a chi può usufruire di
una data cartella oppure no.
Si sfoglia la rete alla ricerca di MIONAS01, il file server NAS, e si trova la share:
40
All’interno della share si trovano le cartelle utente e quella comune:
L’utente Carlo accede alla sua cartella:
Se tenta di accedere a quella di Aldo ottiene un errore, non può accedere:
Una delle differenze tra un software NAS basato su Linux e un file server Microsoft è che si perde la
Acces Based Enumeration, quindi all’interno della share tutti gli utenti vedono tutto anche se non
possono accedere.
Magari nell’ambito di un piccolo ufficio questo ha poca rilevanza, certo che in una situazione dove si
contano decine di utenti va studiata una situazione diversa.
Conclusioni: con una rete da 60 Mb/10Mb come quella usata è stato possibile realizzare una soluzione
Active Directory remota, in Cloud, con un file server in locale e quindi in un contesto di Hybrid Cloud.
41
L’ambiente è stato testato con una coppia di pc client, quindi con poco traffico, ma globalmente non
sono stati riscontrati problemi degni di nota durante i diversi giorni del test. E’ il futuro, non appena in
Italia i provider si decideranno a fornire anche ai comuni mortali una connettività degna di questo nome.
Ringraziamenti
Ringrazio infinitamente Fulvio Ricciardi per aver messo a disposizione del mondo il suo Zeroshell, un
software che non smette mai di stupire.
Ringrazio inoltre Cristian Colombini per il suo lavoro di documentazione sulla VPN site to site.
Infine un sentito ringraziamento all’amico e collega Massimo Rocchi, specialista di reti, che anche questa
volta ha “sopportato” la lettura di questo documento e mi ha dato dei preziosi consigli.
A presto.
