di questa architettura rispetto a quella OpenVPN, dal momento che la prima resta una delle scelte pi`u diffuse in materia.
• IPsec (Interet Protocol Security): `e uno standard per reti a pacchetto che si prefigge di ottenere connessioni sicure su reti IP. La sicurezza viene raggiunta attra-verso funzionalit`a di autenticazione, cifratura e controllo di integrit`a dei pacchetti IP (datagrammi). Per quanto riguarda la cifratura esistono due protocolli che la implementano, quello usato nelle VPN `e ESP (Encapsulation Security Payload) in modalit`a tunnel. In questa modalit`a l’intero pacchetto IP, intestazione compresa, viene incapsulato nel corpo di un nuovo pacchetto IP completamente diversa.
• L2TP (Layer Two Tunneling Protocol) : `e un protocollo di rete (Standard IETF) che supporta le VPN multiprotocollo e che consente agli utenti remoti di accedere alle reti aziendali in modo sicuro attraverso Internet. Il protocollo L2TP, a differenza del protocollo PPTP, non dipende dalle tecnologie di crittografia specifi-che di ciascun fornitore, per l’autenticazione dell’utente. Il funzionamento avviene al livello 2 della pila ISO/OSI, ma di fatto `e un protocollo che agisce al livello 5. Utilizza ufficialmente la porta UDP 1701. In realt`a L2TP non fornisce alcuna sicurezza di per s`e deve essere usato insieme ad altri protocolli di autenticazione e criptazione. In genere si usa IPsec che fornisce sia l’autenticazione che la criptazio-ne. La combinazione di questi protocolli `e nota come L2TP/IPsec. Gli estremi di una connessione L2TP sono chiamati LNS (L2TP Network Server) e LAC (L2TP Access Concentrator). LNS `e il server che attende le connessioni, il LAC inizia la connessione. Una volta stabilita la connessione, il traffico potr`a passare bidire-zionalmente al suo interno (tunneling). A questo punto vogliamo far passare dei protocolli pi`u evoluti all’interno del tunnel che abbiamo creato. In genere per fare questo si usa il protocollo PPP. L2TP permette di instradare pi`u VPN all’interno dello stesso tunnel.
Inizialmente IPsec crea una connessione sicura. Successivamente L2TP crea un tun-nel, sfruttando la connessione sicura IPsec. In questo contesto ogni client presente nelle sedi Dolomitissime, ovviamente anche esterno, inizialmente non fa parte automaticamente della rete VPN. Sia che esso si trovi in una LAN di una qualsiasi sede oppure sia remoto esterno, esso deve instaurare una connessione VPN con il server centrale, in questo caso posizionato nella sede di Falcade. Di fatto ogni singola connessione VPN tra un client qualsiasi e il server centrale risulta indipendente dalle altre ed `e quindi compito dell’u-tente instaurare la connessione dal momento che il LNS semplicemente resta in attesa di nuove connessioni in ingresso.
CAPITOLO 3. LO STAGE 21
3.2.2 Richieste del cliente e requisiti emersi
Il sistema appena descritto pur garantendo una buona sicurezza di rete, costringe la creazione di distinte connessioni VPN tra ogni singolo terminale, verso il server centrale presente nella sede di Falcade. La richiesta quindi deve partire dal client interessato ed eventualmente anche terminare. Il fatto di dover gestire direttamente il lato VPN `e stato uno dei primi aspetti scomodi segnalati in sede di accordo tra Netech e Dolomitissime. La totale automatizzazione e schermatura di queste procedure ha quindi rappresentato uno dei primi requisiti qualitativi esplicitamente espressi da Dolomitissime. Questa architet-tura inoltre, non permette connessioni VPN dirette verso altre sedi (o verso altri client della stessa sede). Sempre lato client infine, dal momento che il sistema gestionale risie-deva in un secondo server remoto, accedervi direttamente tramite VPN richierisie-deva una seconda connessione dedicata del tipo descritto in precedenza, complicando ulteriormente la gestione pratica da parte dell’utente.
L’architettura lato server, come accennato, prevedeva due server con funzioni diver-se (un diver-server di posta e uno desktop-file diver-server), posizionati nella diver-sede di Falcade dove qualsiasi problema di connettivit`a e soprattutto di alimentazione poteva provocare facil-mente la caduta dell’intero sistema. Questa discutibile scelta architetturale `e stata una delle principali cause che ha portato all’abbandono da parte di Dolomitissime di questo sistema. Congiuntamente a ci`o, la totale assenza di manutenzione di sistema, non previ-sta da contratto, (di fatto presa in carico anche dai dipendenti dell’azienda cliente), e le conseguenti richieste soprattutto a terzi, oltre alla palese scomodit`a, hanno comportato un considerevole aumento dei costi di gestione.
Questo scenario ha fatto emergere i principali requisiti funzionali e qualitativi che obbligatoriamente dovevano caratterizzare la nuova rete aziendale Dolomitissime:
1. gestione traffico VPN automatizzato e schermato agli occhi dell’utente (black box[G]) 2. semplicit`a di utilizzo (diretta conseguenza del requisito precedente)
3. ottimizzazione del traffico VPN (in termini di numero di connessioni) 4. connettivit`a VPN tra sedi differenti
5. centralizzazione desktop server e gestionale 6. efficienza del sistema (server side prima di tutto) 7. protezione dati del sistema
8. continuit`a del servizio
9. manutenzione e monitoraggio sistema costanti
CAPITOLO 3. LO STAGE 22
Figura 3.16: Dolomitissime soluzione Netech
CAPITOLO 3. LO STAGE 23
3.2.3 Soluzione Netech Networks
La figura 3.16 fornisce una prima decomposizione architetturale della soluzione proposta e successivamente implementata da Netech Networks. In figura si vede come in ogni sede il traffico in entrata e in uscita sia filtrato da firewall (Soekris) visti in precedenza. In ogni firewall `e installato il sistema operativo PfSense, grazie al quale `e stato possibile importare tutte le regole di traffic shaping del sistema precedente. Inoltre ogni firewall `e presente l’installazione del programma client OpenVPN che gestisce di fatto le connessioni VPN tra le sedi e con il server centrale. Il firewall demarca quindi la linea di confine tra parte pubblica e parte privata, proteggendo quest’ultima e permettendo le connessioni VPN. Il firewall situato nella sede di Netech Padova funge da access server per tutti gli altri firewall dislocati nelle sedi di Dolomitissime che a loro volta rappresentano i client della VPN. Quindi tutto il traffico VPN `e racchiuso esclusivamente tra i firewall. I terminali di ogni LAN non sono minimamente coinvolti e non eseguono alcuna connessione VPN, cosa che accadeva invece nel sistema precedente. Ogni firewall delle varie sedi mantiene una connessione VPN costante con il firewall (access server) presente nella sede di Netech Padova, perde la connessione solo in caso di spegnimento, e la riottiene automaticamente ad ogni avvio. Un pacchetto che non deve viaggiare all’interno della VPN, viene semplicemente instradato su Internet dal firewall. Al contrario un pacchetto, ad esempio, indirizzato al server (tramite il suo indirizzo di rete privata) viene invece instradato sulla VPN verso il firewall di Netech.
Il server centrale, ora in sede Netech di Padova e non pi`u in una delle sedi Dolomitissi-me, non ha alcun indirizzo pubblico e di fatto `e a tutti gli effetti inaccessibile dall’esterno della rete Dolomitissime.
Nell’ottica di un client di una qualsiasi sede Dolomitissime tutto quello che riguarda la rete VPN `e invisibile, non deve preoccuparsi di eseguire alcuna connessione VPN dedicata e nemmeno di cessarla.
Nella LAN interna di ogni sede un access point wireless gestisce la comunicazione tra client presenti, stampanti ecc, il tutto protetto tramite WPA.
Secondo livello di decomposizione architetturale: Server Side
La figura 3.17 espone un secondo livello di decomposizione architetturale e presenta la situazione attuale del sistema Dolomitissime server-side. Come gi`a accennato, tutte le connessioni VPN provenienti dalle varie sedi, iniziano la connessione con i loro firewall che fungono da client della rete VPN e convergono nel firewall di Netech Padova che assume il ruolo di access-server, firewall e VPN-concentrator. Quest’ultimo `e quindi collegato ad uno switch che collega tutte le altre componenti server side: il cluster server[G] con le due macchine in fail-over tra di loro e lo storage tramite i suoi due controller iSCSI. In figura viene mostrata anche una configurazione semplificata dei due controller iSCSI c1 e c2. Il primo rappresenta il punto d’accesso principale che gestisce il sistema RAID5 dei dischi, il secondo funge da monitoring controller e da back up controller, gestendo il
CAPITOLO 3. LO STAGE 24