Relazione di fine stage

(1)

(2)

Relazione di fine stage

installazione di una rete VPN

Jacopo Marzola

luned`ı 2 luglio 2012

(3)

Sommario

Lo scopo di questo documento `e presentare in sintesi il lavoro svolto durante il mio stage presso l’azienda Netech S.r.l.

Il primo capitolo riguarder`a l’azienda e di cosa si occupa, analizzando dominio applicativo, tecnologie utilizzate e processi di sviluppo adottati.

Il secondo capitolo introdurr`a il progetto di stage concentrandosi sulla strategia aziendale e sul come sia nato il progetto. Inoltre tratter`a obiettivi e vincoli strettamente legati al completamento del progetto.

Il terzo capitolo affronter`a maggiormente in dettaglio lo svolgimento del progetto, concentrandosi sui passi che hanno portato al suo completamento.

Il quarto capitolo esporrà una personale valutazione completa sulle attese e sull’effettivo svolgimento del tirocinio presso l’azienda. Inoltre verrà analizzato il personale livello di preparazione pre stage confrontandolo con le conoscenze acquisite e le difficoltà affrontate.

i

(4)

Indice

Sommario i

1 L’Azienda 1

1.1 Dominio Applicativo . . . 1

1.2 Target aziendale . . . 2

1.3 Processi di sviluppo . . . 2

1.3.1 Il modello sequenziale . . . 3

2 Strategia aziendale 5 2.1 Motivazioni e nascita del progetto . . . 5

2.1.1 Cos’`e una VPN . . . 5

2.1.2 Perch`e una VPN . . . 6

2.2 Gli obiettivi . . . 7

2.3 Vincoli tecnologici e di interoperabilit`a . . . 7

3 Lo stage 8 3.1 Introduzione allo sviluppo . . . 8

3.1.1 Strumenti e tecnologie . . . 8

3.1.2 OpenVPN . . . 15

3.2 Progettazione . . . 18

3.2.1 Vecchio sistema Dolomitissime . . . 18

3.2.2 Richieste del cliente e requisiti emersi . . . 21

3.2.3 Soluzione Netech Networks . . . 23

3.2.4 Corrispondenza requisiti-soluzioni progettuali . . . 24

3.3 Sviluppo . . . 26

3.3.1 Installazione memorie flash con pfSense e configurazione . . . 26

3.3.2 Installazione firewall e gateway wireless . . . 30

3.3.3 Installazione e configurazione del cluster server centrale, del firewall centrale e dello storage presso Netech . . . 33

3.3.4 Installazione e configurazione OpenVPN . . . 34

3.3.5 Anomalie e difetti riscontrati . . . 37

3.4 Verifica e validazione: strategia aziendale . . . 39

ii

(5)

INDICE iii

4 Valutazione retrospettiva 41

4.1 Autovalutazione sul rispetto delle attese . . . 41

4.2 Conoscenze acquisite . . . 42

4.3 Conoscenze richieste . . . 43

4.3.1 Livello di preparazione didattica pre stage . . . 43

Glossario 43

Bibliografia 47

(6)

Elenco delle figure

1.1 Logo Netech S.r.l. . . 1

1.2 Modello di ciclo di vita a cascata . . . 4

2.1 Esempio tipico di una VPN . . . 6

3.1 Logo Teamviewer . . . 9

3.2 Soekris net5501 fronte . . . 10

3.3 Soekris net5501 retro . . . 10

3.4 Soekris net5501 - Motherboard . . . 11

3.5 Compact flash . . . 11

3.6 logo pfSense (FreeBSD) . . . 12

3.7 Dell 1950 III . . . 12

3.8 Configurazioni Hypervisor . . . 13

3.9 Logo Citrix XenServer . . . 13

3.10 PowerVault md3000i fronte . . . 14

3.11 PowerVault md3000i retro . . . 14

3.12 Logo OpenVPN . . . 15

3.13 Logo PrivateTunnel Tecnology . . . 16

3.14 Topologia Access Server . . . 17

3.15 Vecchio sistema Dolomitissime . . . 19

3.16 Dolomitissime soluzione Netech . . . 22

3.17 Architettura server side . . . 25

3.18 USB 2.0 Reader/Writer Memory Adapter . . . 26

3.19 Setup Wizard Starding Screen . . . 27

3.20 Setup Wizard general info . . . 27

3.21 NTP and Time Zone Setup Screen . . . 28

3.22 WAN type . . . 28

3.23 Built-in Ingress Filtering Options . . . 29

3.24 IP LAN . . . 29

3.25 Completamento Wizard . . . 29

3.26 Backup GUI . . . 30

3.27 Configurazione vecchio firewall . . . 31

iv

(7)

ELENCO DELLE FIGURE v

3.28 Firewall WAN rules . . . 32

3.29 Schermata creazione/modifica regola firewall . . . 32

3.30 Tragitto uscita installazioni . . . 33

3.31 Schermata creazione CA . . . 34

3.32 Schermata creazione Account . . . 35

3.33 Wizard OpenVPN setup . . . 36

3.34 Selezione della CA . . . 36

3.35 Configurazione OpenVPN Server . . . 37

3.36 Configurazione OpenVPN Server 2 . . . 37

(8)

Capitolo 1 L’Azienda

L’azienda presso la quale ho completato lo stage è la Netech S.r.l., una software agency italiana fondata nel 2000 specializzata nello sviluppo di applicazioni software per il mondo web (siti aziendali) e lo sviluppo di strategie on-line. L’azienda comprende tre sedi (Padova, Milano, Belluno) ed è composta da più di 30 impiegati, fornisce servizi come portali, applicazioni web, SMS e servizi al mondo mobile, POS virtuali, domini e PEC a circa 700 clienti.

Figura 1.1: Logo Netech S.r.l.

1.1 Dominio Applicativo

Il neonato ufficio tecnico Netech Network Padova, dove ho svolto il tirocinio, si occupa principalmente di intranet aziendali, gestione multicanale del dato, domini, hosting, housing ed in generale di soluzioni a più basso livello come personalizzazione di server dedicati, help desk, assistenza. Il CTO[G] è Andrea Urbani, che da circa 12 anni si occupa di sistemistica in ambito prevalentemente opensource, di GNU/Linux e della sua diffusione. Andrea in passato ha lavorato per alcune multinazionali e ISP[G] Italiani, inoltre ha gestito 2 aziende di informatica sempre legate al mondo dell’ open source e della sicurezza informatica. Ora presta la sua opera come CTO presso Netech Srl ed è il Presidente del Free Software User Group di Padova, oltre a partecipare attivamente all’

organizzazione di alcune manifestazioni legate al mondo dell’ informatica in Italia e in Europa.

1

(9)

CAPITOLO 1. L’AZIENDA 2 Il progetto Dolomitissime, affrontato in questo stage, rappresenta una dei primi in- carichi del nuovo ufficio tecnico, ed `e consistito nella progettazione e installazione di una rete VPN per l’azienda cliente Dolomitissime; agenzia immobiliare con 5 sedi dislocate nella provincia di Belluno (Agordo, Alleghe, Falcade, Ponte delle Alpi, Sedico). Oltre all’ambito prevalentemente sistemistico, Netech Network offre anche assistenza tecnica a privati, piccoli uffici e negozi.

Le tecnologie verso cui si orienta l’ufficio tecnico sono generalmente proposte da An- drea, suggerite dall’esperienza e dalla diffusione delle stesse con successo. L’attenzione

è focalizzata sulla qualità di pari passo con l’economicità, sempre concentrando le prime scelte verso il mondo open source. Nell’ambito sistemistico, firewall di buon successo come la famiglia Soekris con dispositivi di storage rimovibili molto economici e affidabili, affiancati alla sicurezza della distribuzione pfSense di BSD[G] sono la configurazione prediletta. Le macchine server prescelte appartengono alla famiglia Dell 1950 III con virtualizzazione Citrix XenServer, mentre i dispositivi di storage[G] e switch[G] verso cui si orienta la scelta dell’ufficio tecnico sono della famiglia Dell Storage md3000i e Dell 5424 iSCSI optimized. Nel complesso, questo pacchetto rappresenta una tipica configurazione adottata da Netech Network per l’implementazione di intranet aziendali attuali.

1.2 Target aziendale

Globalizzazione, decentramento, lavoro da casa, partnership tra aziende sono alcuni dei fattori che hanno determinato un forte incremento della richiesta di connettività. Le soluzioni tradizionali, come l’affitto di linee dedicate e il collegamento diretto via modem alle reti aziendali, erano molto costose; sono nate quindi le reti private virtuali o VPN, con lo scopo di realizzare connessioni private attraverso una rete pubblica, che inizialmente era la rete di un gestore e oggi è Internet. Questo ha portato un enorme risparmio in canoni e attrezzature per tutte le aziende dotate di un sistema informativo e intenzionate a diminuire drasticamente i costi di gestione dei propri dati. Qualsiasi piccola, media impresa necessiti di un sistema per la gestione e il trattamento sicuro dei dati o che desideri migrare da un sistema obsoleto, costoso, poco sicuro perchè fisicamente dedicato e quindi per nulla scalabile non può che orientarsi verso una VPN. Essa può essere considerata come la migliore soluzione per piccole medie aziende di qualsiasi settore.

1.3 Processi di sviluppo

Dal momento che le tipologie di progetti di cui si fa carico l’ufficio tecnico risultano molto distinte, ovviamente non viene adottato un processo di sviluppo uguale per tutti. Ogni progetto viene affrontato in modo diverso, senza affidarsi ad un modus operandi standard, a seconda delle esigenze del cliente, delle tecnologie necessarie, della disponibilit`a di

(10)

CAPITOLO 1. L’AZIENDA 3 personale, e del termine di scadenza prefissato. Ci`ononostante, trattando principalmente esigenze tecnico-informatiche di basso livello, `e possibile accomunare la maggior parte dei progetti (incluso il mio) ad un approccio che, per molti aspetti, presenta alcune analogie con il il modello di ciclo di vita sequenziale.

Nel modello applicato all’ingegneria del software, è previsto un ingente supporto in termini di documentazione (modello document-driven), ma nell’ambito più a basso livello di un piccolo ufficio tecnico, trattando progetti di complessità analitica e di progettazione ben inferiore rispetto a problematiche tipiche dell’ingegneria del software, un supporto burocratico del genere avrebbe rappresentato un collo di bottiglia tutt’altro che indiffe- rente. Il susseguirsi delle fasi che hanno portato al completamento del progetto di stage rispecchia il modello sopracitato. La principale differenza riguarda la mole di documentazione allegata, nel caso specifico il passaggio o meno da una fase alla successiva, ha quasi esclusivamente riguardato l’esito del testing finale del prodotto di tale processo.

Esito positivo era condizione necessaria e sufficiente per passare alla fase successiva.

1.3.1 Il modello sequenziale

Nello specifico caso del progetto Dolomitissime, dal momento che le richieste del committente sono state esaminate e stabilite assieme all’ufficio tecnico in sedi di accordo in modo definitivo, il team di sviluppo ha potuto dedicare un periodo di tempo relativamente ridotto alla progettazione e alla programmazione del lavoro da svolgere per consegnare il prodotto entro le scadenze concordate. Il modo di operare risultante `e stato fin dall’i- nizio analogo a quello che viene adottato nel modello sequenziale o a cascata seppur con una mole di documentazione inferiore. Regola principale e che sta alla base della natura stessa del ciclo di vita a cascata `e la seguente:

Ogni fase viene affrontata solo previa completamento della fase precedente

Il completamento di una fase, nel modello sequenziale puro, prevede prima il completamento della documentazione e poi quella del software relativi a quella specifica fase. In un progetto simile, il completamento del lavoro previsto, insieme all’eventuale successo del collaudo, hanno rappresentato i requisiti necessari e sufficienti per passare alla fase successiva.

Nel modello di ciclo di vita a cascata sono previste 5 fasi (figura 1.2):

1. L’Analisi dei requisiti corrisponde alla fase iniziale in cui vengono raccolte le informazione e le richieste emerse dall’incontro con il committente riguardo alle specifiche caratteristiche che il prodotto finale deve possedere. In questa fase, vengono definiti tutti i requisiti (obbligatori, desiderabili e opzionali) che il prodotto finale deve possedere, associati ad una determinata priorità. Questa fase è stata completata prima dell’inizio del mio periodo di stage ed è consistita nell’analisi delle richieste esplicite del cliente, seguita dalla presentazione da parte del fornitore della soluzione scelta.

(11)

CAPITOLO 1. L’AZIENDA 4

Figura 1.2: Modello di ciclo di vita a cascata

2. La progettazione ha riguardato la definizione del prodotto finale assieme alle tecnologie scelte in sede di analisi. Oltre alla progettazione del sistema, essa ha compreso la pianificazione delle varie fasi di implementazione a granularit`a settimanale.

Questa fase ha rappresentato l’inizio del mio stage presso Netech Network

3. La fase di implementazione `e rimasta rigidamente suddivisa nei processi di sviluppo pianificati durante la progettazione. Ogni fase prevedeva la realizzazione, installazione e la verifica di una particolare componente del sistema. L’esito positivo di tale verifica era la condizione necessaria e sufficiente per passare alla fase di sviluppo successivo.

4. La verifica e la validazione oltre ad essere state incorporate nella fase implemen- tativa come prova per il passaggio alle fasi successive, hanno riguardato inoltre la fase finale dell’intera realizzazione del sistema prima della consegna.

5. La manutenzione e il continuo monitoraggio del funzionamento dell’intero sistema `e parte integrante e fondamentale del contratto accordato tra Dolomitissime e Netech. Il server centrale del sistema risiede nella sede padovana di Netech.

L’analogia con il ciclo di vita sequenziale riguarda principalmente la rigidit`a nella successione delle varie fasi infatti non sono previste modifiche all’ordine prestabilito e non `e possibile modificare tale ordine. Sono invece previste piccole modifiche o raffinazioni al sistema di tipo incrementale.

Il progetto Dolomitissime ha compreso inoltre una breve sessione di teaching presso le sedi del cliente sul funzionamento del sistema e sulle novit`a rispetto al sistema precedente.

(12)

Capitolo 2

Strategia aziendale

In questo capitolo verrà descritto com’è nato il progetto di stage, gli obiettivi che l’azienda si è prefissata e cosa essa si aspetta dopo il suo completamento. Il mio stage presso Netech S.r.l. consisteva nella realizzazione di una rete VPN per l’agenzia immobiliare Dolomitissime in sostituzione del vecchio sistema informatico già in uso dal cliente.

2.1 Motivazioni e nascita del progetto

Il progetto Dolomitissime nasce dall’esigenza del cliente di sostituire il vecchio sistema informatico con uno pi`u sicuro, semplice e performante. A tale proposito l’ufficio tecnico ha proposto al cliente l’installazione di una rete VPN centralizzata, garantendone il corretto funzionamento e la constante manutenzione. Il progetto `e stato proposto dal CTO Andrea Urbani insieme al suo team dell’ufficio tecnico presso Netech Padova ed ha rappresentato il primo incarico nell’ambito delle intranet aziendali.

Prima dell’inizio del mio stage Netech Networks di Padova aveva gi`a definito l’accordo con l’azienda cliente Dolomitissime e fornito un preventivo comprensivo delle tecnologie che sarebbero state utilizzate nell’implementazione del sistema. Inoltre era stata gi`a definita la data di scadenza per il completamento del progetto.

2.1.1 Cos’` e una VPN

Una VPN o Virtual Private Network è una rete di telecomunicazioni privata, instaurata tra entità (terminali) che sfruttano un sistema di trasmissione pubblico e condiviso, come per esempio la rete globale Internet. Lo scopo delle reti VPN è di offrire alle aziende, a un costo inferiore, le stesse possibilità delle linee private dedicate e in affitto, sfruttando reti condivise pubbliche. Il termine virtuale si riferisce proprio al fatto che esse non si avvalgono di reti fisiche private dedicate, ma poggiano sulla rete globale di Internet. Tramite una VPN, utilizzando una connessione Internet, è ad esempio possibi-

5

(13)

CAPITOLO 2. STRATEGIA AZIENDALE 6 le collegarsi, da qualsiasi terminale, alla rete privata del proprio ufficio come mostra la figura 2.1.

Figura 2.1: Esempio tipico di una VPN

Tipicamente una VPN comprende due parti: una interna alla rete, protetta da firewall, e una meno affidabile e sicura che `e quella esterna alla rete privata, che poggia sulla rete globale Internet. La sicurezza della parte esterna `e ottenuta utilizzando col- legamenti che necessitano di autenticazione in modo da garantire l’accesso ai soli utenti autorizzati; per garantire la sicurezza che i dati inviati in Internet non siano intercetta- ti o utilizzati da altri non autorizzati, vengono utilizzati sistemi di crittografia tramite appositi protocolli che provvedono a cifrare il traffico transitante sulla rete virtuale.

2.1.2 Perch` e una VPN

Una VPN permette di collegare in modo sicuro i due estremi della connessione tramite una rete non dedicata, tipicamente utilizzando internet, abbattendo i costi delle linee CDN (vere e proprie linee fisiche dedicate), che un tempo erano l’unica opzione. Tutto ci`o porta diversi benefici:

(14)

CAPITOLO 2. STRATEGIA AZIENDALE 7

• Economicit`a: si abbatte il costo delle infrastrutture. La scelta dell’implementazione adeguata in fase di progetto permette di scegliere la soluzione pi`u adeguata al miglior costo sostenibile

• Semplicit`a: la tecnologia `e molto matura e facilmente applicabile

• Sicurezza: si basa su standard perlopi`u aperti e universalmente riconosciuti come sicuri. Con pochi accorgimenti si riescono ad ottenere buoni compromessi tra semplicit`a di accesso e ragionevole sicurezza.

• Connettività: il fatto di essere virtuale permette di estendere la connettività geografica senza alcun problema e a costi irrisori rispetto ad una rete dedicata Per queste semplici ragioni, la scelta adottata per soddisfare le richieste del cliente sono ricadute su questa tecnologia ormai utilizzata nella maggior parte delle realtà aziendali odierne.

2.2 Gli obiettivi

Con il progetto Dolomitissime, l’obiettivo dell’azienda Netech S.rl. `e stato quello di fornire entro i termini concordati, un sistema informatico del tutto nuovo, semplificato, sicuro ed efficiente, con un’architettura che ne semplificasse le funzionalit`a e la costante manutenzione. I requisiti concordati dovevano essere rispettati e l’azienda Netech diventava di fatto la gestrice e manutentrice della nuova rete aziendale Dolomitissime (come previsto da contratto). Il server centrale Dolomitissime risiede ora nella sede padovana di Netech dove viene costantemente sottoposto a controllo e manutenzione.

2.3 Vincoli tecnologici e di interoperabilit` a

La scelta di ben precise tecnologie ampiamente utilizzate con successo nell’ambito delle reti e della sicurezza e qualitativamente garantite, ha permesso di definire con precisione la direzione da seguire sia in fase di progettazione che in fase di implementazione. Tale scelta `e stata decisione dell’ufficio tecnico che ha poi proposto al cliente la configurazione in termini principalmente di costi. Quindi l’unico vincolo nella scelta delle tecnologie

`e stato rappresentato dal budget di spesa massima richiesto dal cliente. Tutto ci`o ha semplificato notevolmente anche la pianificazione delle fasi, l’assegnazione dei compiti per ogni fase, e la loro rigida successione temporale.

(15)

Capitolo 3 Lo stage

In questo capitolo analizzerò il percorso di sviluppo seguito durante lo stage e le tecnologie utilizzate. La progettazione del sistema è stata definita prima dell’inizio del periodo di stage da me sostenuto presso Netech Networks, ed è semplicemente consistita nella definizione di pattern[G] implementativi già ampiamente rodati nel settore e garantiti come funzionanti e sicuri. Il collegamento delle varie componenti costituenti del sistema rappresentate da questi pattern è stata l’unica fase che ha prodotto significative anomalie e imprevisti degni di essere menzionati.

Questo capitolo oltre alla trattazione delle tecnologie e della progettazione tratter`a anche ampiamente la fase di sviluppo e i ruoli da me ricoperti durante l’implementazione del sistema.

3.1 Introduzione allo sviluppo

In questa sezione introdurr`o strumenti e tecnologie utilizzati per l’implementazione del sistema.

3.1.1 Strumenti e tecnologie

Come accennato in precedenza, la scelta delle tecnologie impiegate nell’implementazione dell’intero sistema è stata interamente influenzata dalla presenza di soluzioni tecnologiche combinate tra loro già ampiamente utilizzate che possono essere considerate come dei veri e propri pattern strutturali nell’ambito dell’ingegneria del software. L’ordine di trattazione delle varie tecnologie sarà dal più periferico al più centralizzato ovvero dai vari client coinvolti fino ad arrivare alla struttura centralizzata del server posto presso Netech Padova. Infine verrà trattato lo strumento utilizzato per garantire la sicurezza nello specifico ambito della VPN; ovvero OpenVPN.

8

(16)

CAPITOLO 3. LO STAGE 9 Terminali

Ogni terminale del sistema presente in ogni sede di Dolomitissime `e stato dotato dell’

antivirus AVG Business Edition 2012. Il pacchetto client comprende:

• AVG Scansione E-mail per la protezione della casella di posa

• AVG Anti-Virus, Resident Shield e Smart Anti-Rootkit per la protezione da virus, worm e trojan pi`u recenti

• AVG Online Shield per la sicurezza nello scambio di file tramite client per la messaggistica immediata (ICQ, MSN, Yahoo)

• AVG Anti-Spyware per l’indentificazione e la rimozione di software di tracciamento come spyware e adware

• AVG Threat Labs per l’accesso a informazioni dettagliate relative alla protezione dei siti Web

• AVG Firewall per la gestione del firewall del client

Per accedere da remoto ai terminali `e stato utilizzato il software Team Viewer, che permette l’accesso desktop diretto e il controllo di qualsiasi terminale Linux, Windows, Mac OS remoto.

Figura 3.1: Logo Teamviewer

Firewall

Ogni sede di Dolomitissime `e stata dotata di un dispositivo Soekris net5501 che oltre a fungere da firewall, comprende le funzionalit`a di un router VPN e di un Internet Gateway-VoIP PBX.

Le due configurazioni standard prevedono minime differenze:

• net5501-60: 433 Mhz CPU, 256 Mbyte DDR-SDRAM, 4 Ethernet Ports

• net5501-70: 500 Mhz CPU, 512 Mbyte DDR-SDRAM, 4 Ethernet Ports

(17)

CAPITOLO 3. LO STAGE 10

Figura 3.2: Soekris net5501 fronte

Figura 3.3: Soekris net5501 retro

Ogni dispositivo prevede 4 Mbit di memoria flash[G] BIOS/BOOT, un alloggio per CompactFLASH Type I/II su cui `e stato installata una memoria flash con il sistema operativo PfSense di FreeBSD.

Il sistema PfSense è una distribuzione di FreeBSD gratuita, open source e personaliz- zabile, progettata appositamente per essere usata come firewall e come router. Oltre alla classiche funzionalità di filtering di un firewall, pfSense permette di mantenere informazioni sulle connessioni network correnti, dal momento che esso è di default uno stateful firewall, ovvero un sistema di filtro in cui solo pacchetti riconosciuti facenti parti una delle connessioni attive valide vengono lasciati transitare, tutti gli altri vengono respinti.

Importante inoltre menzionare le funzionalit`a NAT[G] e soprattutto le tre opzioni offerte per le connessioni VPN (IPsec, OpenVPN e PPTP)

(18)

Figura 3.4: Soekris net5501 - Motherboard

Figura 3.5: Compact flash Server

Come accennato, le macchine server utilizzate appartengono alla famiglia Dell 1950 III (Figura 3.6). Esse sono progettate esplicitamente per offrire le migliori prestazioni nel- l’ambito della virtualizzazione. Le due macchine server utilizzate sono ridondanti in un fail-over cluster, ovvero un sistema di pi`u macchine collegate tra loro (nodi del cluster), dove in caso di caduta di un nodo, il suo carico di lavoro viene automaticamente distri- buito tra i nodi rimanenti. In questo caso la caduta di uno dei due server provoca lo spostamento del carico di lavoro interamente sull’altro, diminuendo considerevolmente il

(19)

Figura 3.6: logo pfSense (FreeBSD)

rischio di interruzione del servizio.

Figura 3.7: Dell 1950 III

La componente chiave per un sistema basato sulla virtualizzazione è la virtual machine manager detta anche hypervisor, ovvero quello strato software che permette la creazione di una molteplicità di ambienti di esecuzione (macchine virtuali) identici e indipendenti in un’ unica macchina (server), ciascuna con il proprio sistema operativo. Viene chia- mata cos`ı perchè concettualmente opera ad un livello più elevato dei supervisory pro- gram, che sono invece programmi facenti parte di un sistema operativo che controllano il work scheduling, le operazioni di I/O e l’error act (gestione delle eccezioni). La VMM presenta quindi una piattaforma operativa virtuale (computer virtualization) al sistema operativo ospite e ne gestisce l’esecuzione. Deve nascondere quindi le caratteristiche fisiche, mostrando al sistema operativo un’astrazione che deve gestire in modo trasparente, ovvero senza pesare con la propria attività sul funzionamento e sulle prestazioni dei sistemi operativi ospiti. Inoltre svolge attività di controllo al di sopra di ogni sistema, permettendone lo sfruttamento anche come monitor e debugger[G] delle attività dei si-

(20)

CAPITOLO 3. LO STAGE 13 stemi operativi e delle applicazioni in modo da scoprire eventuali malfunzionamenti ed intervenire celermente. Vengono distinti due tipi di hypervisor :

• Type 1 (o native, bare metal) : in questa configurazione, l’hypervisor funziona direttamente sopra l’hardware dell’host per controllarlo e per gestire i sistemi operativi ospiti che a loro volta funzionano un livello soprastante. XenServer di Citrix System rappresenta un esempio diffuso di questa tipologia di configurazione.

• Type 2 (o hosted): in questa configurazione l’hypervisor funziona all’interno di un sistema operativo e rappresenta un secondo strato distinto su cui a sua volta possono poggiare uno o pi`u sistemi operativi, che di fatto rappresentano il terzo strato distinto al di sopra dell’hardware. Virtual Box di Oracle rappresenta un classico esempio di questa tipologia di configurazione.

La figura 3.8 mostra la differenza tra le due configurazioni.

Figura 3.8: Configurazioni Hypervisor

L’hypervisor prescelto `e stato XenServer di Citrix System, compagnia che in segui- to all’acquisizione di XenSource, avvenuta nell’ottobre 2007, dirige il progetto inerente all’hypervisor open source Xen. La versione free pu`o essere scaricata gratuitamente dal sito ufficiale ma richiede un’ attivazione che deve essere rinnovata ogni anno.

Figura 3.9: Logo Citrix XenServer

(21)

CAPITOLO 3. LO STAGE 14 Storage

Tipicamente la scelta del dispositivo di storage per le macchine server ricade sulla famiglia PowerVault di Dell, più precisamente sul modello MD3000i (figura 3.8). Questo modello è un SAS-based disk array con due controller iSCSI[G]incorporati. Ogni controller include due porte iSCSI da 1Gb/s ciascuno, cos`ı come una porta Ethernet di management e una porta SAS[G] di espansione (figura 3.9). In aggiunta il dispositivo può essere espanso con due PowerVault MD1000 Disk Expansion Enclosures, per un totale di 45 dischi.

Figura 3.10: PowerVault md3000i fronte

Figura 3.11: PowerVault md3000i retro

La tecnologia RAID (redundant array of indipendent disks) adottata è stata RAID-5 con l’aggiunta di un disco di hot spare (di ricambio). Questa configurazione prevede la divisione dei dati in blocchi con i dati di parità suddivisi tra tutti i dischi appartenenti al RAID. Ogni volta che un blocco di dati deve essere scritto nel sistema di dischi, un blocco di parità viene generato all’interno della stripe (una serie di blocchi consecutivi). Il blocco di parità viene letto solo quando la lettura di un settore dà un errore CRC[G]. In questo caso, il settore nella stessa posizione relativa nei blocchi di dati rimanenti della stripe, insieme al blocco di parità, vengono usati per ricostruire il blocco mancante. In questo modo l’errore di CRC viene nascosto al computer chiamante. Nella stessa maniera, se un

(22)

CAPITOLO 3. LO STAGE 15 disco dovesse danneggiarsi all’interno del sistema, i blocchi di parit`a dei dischi rimanenti sono combinati matematicamente con i blocchi dati rimasti per ricostruire i dati del disco guasto. Questi dati ricostruiti vengono quindi caricati nel disco di ricambio (hot spare).

Per la gestione `e disponibile un Modular Disk Storage Manager (MDSM) Dell che pu`o essere installato su una qualsiasi macchina server collegata allo storage tramite la porta Ethernet di management. Attraverso questo software di gestione possono essere creati dischi virtuali (storage logical units o LUNs) e resi accessibili agli specifici host.

3.1.2 OpenVPN

Il termine VPN `e un termine generico e non un marchio. In particolare, non esiste alcun ente che regoli la denominazione di un prodotto come VPN; quindi ogni produttore pu`o utilizzare la denominazione a suo piacimento. Esistono svariati modi per ottenere una buona sicurezza per una rete privata virtuale; nel progetto oggetto di questo documento

`e stato utilizzato un programma open molto versatile chiamato OpenVPN.

Figura 3.12: Logo OpenVPN

OpenVPN è un programma VPN scritto da James Yonan e rilasciato con licenza GPL. Viene usato per creare tunnel crittografati punto-punto fra i computer. Permette agli host di autenticarsi l’uno con l’altro per mezzo di chiavi private condivise, certificati digitali o credenziali utente/password. Usa in modo massiccio le librerie di cifratura OpenSSL e usa il protocollo SSLv3/TLSv1. È disponibile su GNU/Linux, xBSD, Mac OSX, Solaris e Windows 2000/XP/Vista/7. Offre un ricco insieme di caratteristiche per il controllo e la sicurezza. Non è una VPN con interfaccia web, e non è compatibile con IPsec (protocollo base delle classiche VPN) o altri programmi VPN. L’intero programma è un singolo eseguibile binario usato per le connessioni sia dal lato server che dal lato client, da un file di configurazione opzionale, e da uno o più file contenenti le chiavi, in funzione del metodo di autenticazione usato. In questo contesto VPN e VPT (Virtual Private Tunnel) sono sinonimi. Tutte le connessioni della VPN sono di fatto dei tunnelglos privati (PrivateTunnel) virtuali criptati, protetti e privatizzati (IP privacy). I VPT connettono l’host coinvolto ai server OpenVPN tramite tunnel criptati, proteggendo la connessione da intercettazioni e spoofing (faslificazione dell’identità). L’accesso a trojan conosciuti e a siti web dannosi è bloccato usando i DNS[G] di Google. Ai siti Internet, i dati dell’utente appaiono provenire dai server OpenVPN, che fungono quindi da proxy server, nascondendo l’ip dell’utente.

(23)

Figura 3.13: Logo PrivateTunnel Tecnology OpenSSL

OpenSSL `e un’implementazione open source dei protocolli SSL (Secure Socket Layer) e TSL (Transport Layer Security). Questi ultimi (TSL e il suo predecessore SSL) sono dei protocolli crittografici che permettono una comunicazione sicura end-to-end su reti TCP/IP (Internet), fornendo autenticazione, integrit`a dei dati e cifratura, operando al di sopra del livello trasporto. Le librerie OpenSSL sono scritte in C ed eseguono le funzioni crittografiche principali. Sono disponibili per la maggior parte dei sistemi operativi unix- like (GNU/Linux e Mac OS X inclusi) e anche per Microsoft Windows.

Protocolli di autenticazione

OpenVPN permette diversi protocolli di autenticazione:

• chiave segreta condivisa: la soluzione pi`u semplice e rapida da implementare

• tramite certificati digitali: la soluzione pi`u robusta e completa che previene attacchi del tipo man in the middle[G] ma che richiede la definizione di una PKI (public key infrastructure)

• credenziali utente/password: `e una caratteristica nuova introdotta con la versione 2.0 e si pu`o usare con o senza il certificato del client (il server deve comunque avere il proprio certificato)

Rete

OpenVPN concentra tutto il traffico dati e di controllo su una singola porta IP. Può usare una porta UDP (preferita e predefinita) oppure TCP. Può funzionare attraverso la maggior parte dei server proxy (HTTP incluso) e non ha problemi ad integrarsi con NAT. Il server può inviare alcune opzioni di configurazione di rete ai client.

Sicurezza

OpenVPN offre diverse caratteristiche di sicurezza interne: pu`o rilasciare i privilegi di root (non disponibile su Microsoft Windows).Inoltre `e disponibile anche la funzione di autenticazione di singolo pacchetto HMAC per aggiungere un ulteriore livello di sicurezza

(24)

CAPITOLO 3. LO STAGE 17 alla fase in cui viene instaurata la connessione; in questo caso ogni pacchetto che non presentasse la firma HMAC prestabilita verrebbe semplicemente scartato senza essere elaborato.

Access Server

Con OpenVPN tutto il traffico VPN passa quindi attraverso un Access Server, esso rappresenta l’attore principale dell’intera rete privata. `E l’Access Server che crea i tunnel criptati e protetti che permettono di fatto la virtualizzazione di una rete dedicata. La figura 3.14 fornisce la topologia del sistema. Un assetto tipico di un OpenVPN Access

Figura 3.14: Topologia Access Server

Server consiste di un server e svariati client. In figura un cliente qualsiasi esterno, munito di certificato, pu`o collegarsi all’Access Server e di fatto diventare parte integrante della VPN stessa.

(25)

3.2 Progettazione

La fase di progettazione è cominciata prima dell’inizio del mio stage ed è consistita inizialmente in una analisi della rete aziendale già presente e successivamente nella definizione dell’architettura del sistema, prestando particolare attenzione nella introduzione delle soluzioni ai problemi riscontrati nella struttura del sistema già presente. Pertan- to inizialmente verrà esposta una panoramica generale del vecchio sistema informatico Dolomitissime, evidenziandone gli aspetti controversi, successivamente verrà presentata la soluzione Netech, tramite differenti livelli di decomposizione architetturale. Entram- be le soluzioni quindi riguardano la stessa topologia che comprende le cinque sedi di Dolomitissime: Agordo, Alleghe, Falcade, Ponte nelle Alpi e Sedico.

Le figure che schematizzano l’architettura dei sistemi in esame non seguono nessuno standard o linguaggio specifico, sono delle raffigurazioni indicative che vogliono semplificare e rendere pi`u agevole la loro descrizione.

3.2.1 Vecchio sistema Dolomitissime

Il sistema originale prevedeva la presenza di un cluster server di due nodi installato nella filiale di Falcade comprendente un server di posta Lotus e un server desktop accessibile da remoto. Il gestionale dell’azienda risiedeva in un server remoto esterno, cos`ı come il sito web. Ogni sede era priva di wireless, ogni terminale era di fatto un nodo indipendente, con il proprio antivirus e contenente i propri dati ridondati nella macchina desktop che fungeva quindi anche da file server. Il problema principale consisteva nella decisione di posizionare il cluster server centrale, privo di gestione dedicata, in una delle sedi Dolomitissime con, inoltre, problemi di stabilit`a elettrica e quindi con facile probabilit`a di interruzione della connessione con le sedi collegate. Inoltre le sedi erano tra loro sconnesse se non tramite collegamento al server desktop di Falcade. Il sistema gestionale risiedeva in un server remoto dedicato.

Diversamente dalla soluzione Netech, il vecchio sistema prevedeva una Secure VPN CITRIX. Questo significa che il vecchio sistema presentava una tipica architettura VPN IPsec. I requisiti necessari sono i seguenti:

• Tutto il traffico su una Secure VPN deve essere criptato e autenticato:

Molti dei protocolli utilizzati per creare Secure VPN permettono la creazione di reti autenticate, ma non criptate. Anche se una simile rete è più sicura di una rete senza autenticazione, non potrebbe essere considerata una VPN perchè non protegge la privacy.

• Le proprietà di sicurezza di una VPN devono essere concordate da tutte le parti della VPN: VPN sicure hanno uno o più tunnel e ogni tunnel ha due estremità. Gli amministratori delle due estremità di ogni tunnel devono essere in grado di accordarsi sulle proprietà di sicurezza del tunnel.

(26)

Figura 3.15: Vecchio sistema Dolomitissime

• Nessuno al di fuori della VPN può compromettere le proprietà di sicurezza della VPN: Deve essere impossibile per un intruso cambiare le proprietà di sicurezza di una o più parti della VPN, in modo da indebolire la criptazione o di compromettere le chiavi di criptazione usate.

Questa configurazione vede il coinvolgimento di alcuni protocolli fondamentali tra cui appunto IPsec e L2TP. Segue una breve descrizione e funzionamento dei due protocolli, strumenti standard di una tipica VPN come questa, ed argomento in sede di analisi.

La scelta di trattarli, nonostante non facciano parte della soluzione proposta da Netech,

(27)

CAPITOLO 3. LO STAGE 20 vuole mettere in evidenza le differenze nel funzionamento e nella filosofia che sta alla base 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): è uno standard per reti a pacchetto che si prefigge di ottenere connessioni sicure su reti IP. La sicurezza viene raggiunta attraverso funzionalità di autenticazione, cifratura e controllo di integrità dei pacchetti IP (datagrammi). Per quanto riguarda la cifratura esistono due protocolli che la implementano, quello usato nelle VPN è ESP (Encapsulation Security Payload) in modalità tunnel. In questa modalità l’intero pacchetto IP, intestazione compresa, viene incapsulato nel corpo di un nuovo pacchetto IP completamente diversa.

• L2TP (Layer Two Tunneling Protocol) : è 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 specifiche di ciascun fornitore, per l’autenticazione dell’utente. Il funzionamento avviene al livello 2 della pila ISO/OSI, ma di fatto è un protocollo che agisce al livello 5. Utilizza ufficialmente la porta UDP 1701. In realtà L2TP non fornisce alcuna sicurezza di per sè deve essere usato insieme ad altri protocolli di autenticazione e criptazione. In genere si usa IPsec che fornisce sia l’autenticazione che la criptazione. La combinazione di questi protocolli è nota come L2TP/IPsec. Gli estremi di una connessione L2TP sono chiamati LNS (L2TP Network Server) e LAC (L2TP Access Concentrator). LNS è il server che attende le connessioni, il LAC inizia la connessione. Una volta stabilita la connessione, il traffico potrà passare bidire- zionalmente al suo interno (tunneling). A questo punto vogliamo far passare dei protocolli più evoluti all’interno del tunnel che abbiamo creato. In genere per fare questo si usa il protocollo PPP. L2TP permette di instradare più VPN all’interno dello stesso tunnel.

Inizialmente IPsec crea una connessione sicura. Successivamente L2TP crea un tunnel, 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.

(28)

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 architettura 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 risiedeva in un secondo server remoto, accedervi direttamente tramite VPN richiedeva 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 diverse (un server di posta e uno desktop-file server), posizionati nella sede di Falcade dove qualsiasi problema di connettività e soprattutto di alimentazione poteva provocare facilmente la caduta dell’intero sistema. Questa discutibile scelta architetturale è stata una delle principali cause che ha portato all’abbandono da parte di Dolomitissime di questo sistema. Congiuntamente a ciò, la totale assenza di manutenzione di sistema, non prevista da contratto, (di fatto presa in carico anche dai dipendenti dell’azienda cliente), e le conseguenti richieste soprattutto a terzi, oltre alla palese scomodità, 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

(29)

Figura 3.16: Dolomitissime soluzione Netech

(30)

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 è installato il sistema operativo PfSense, grazie al quale è stato possibile importare tutte le regole di traffic shaping del sistema precedente. Inoltre ogni firewall è 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 è 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

(31)

CAPITOLO 3. LO STAGE 24 disco hot spare pronto a subentrare nel caso di guasto di uno dei dischi. Nella sezione dedicata alla fase di sviluppo verr`a brevemente trattata la gestione del sistema di storage tramite Modular Disk Storage Manager (MDSM) Dell.

3.2.4 Corrispondenza requisiti-soluzioni progettuali

Questa sezione intende esplicare la corrispondenza tra i requisiti emersi in sede di accordo con Dolomitissime e le peculiarit`a del sistema Netech. I requisiti espressi in precedenza rappresentano una sintesi semplificata delle caratteristiche obbligatorie che il sistema doveva possedere per soddisfare appieno i bisogni del cliente. Sono stati numerati proprio per permetterne un semplice tracciamento.

• Req. 1 e Req. 2: Affidando tutto il traffico VPN ai Firewall `e stato possibile incapsulare l’intera VPN, di fatto rendendola come una enorme black-box, quindi schermando ad ogni utente del sistema il suo funzionamento, anzi nascondendo del tutto la sua esistenza. Diversamente dal vecchio sistema, ogni utente tramite il suo client non deve preoccuparsi di instaurare nessuna connessione specifica e pu`o comunicare con il server centrale esattamente come se fosse collegato in rete.

• Req. 3 e Req. 4 Il sistema `e stato progettato per permettere connessioni VPN del tipo client-server-client, quindi ogni client delle LAN aziendali non deve instaurare nessuna connessione VPN e nessuna ulteriore connessione VPN per comunicare con altri client.

• Req. 5 Il server centrale di rete non risiede pi`u in una delle sedi di Dolomitissime, ora `e installato presso la sede Netech di Padova

• Req. 6 e Req. 8 Il cluster server centrale configurato in fail-over cos`ı come la configurazione dello storage (RAID5 e hot spare disk) sono due soluzioni che hanno come obiettivo primario l’efficenza e la continuit`a del servizio. Inoltre i firewall sempre attivi mantengono una costante connessione VPN, in caso di spegnimento essi la riattivano automaticamente al loro avvio.

• Req. 8 Il server esclusivamente raggiungibile tramite VPN, la configurazione Open- VPN della rete stessa, la protezione nelle singole wireless dislocate garantiscono un adeguato livello di sicurezza e protezione dei dati.

• Req. 9 Il server centrale installato presso Netech `e sotto costante monitoraggio e manutenzione da parte del team di Netech Networks, indipendente ed operante all’occorrenza senza coinvolgimento del cliente.

(32)

Figura 3.17: Architettura server side

(33)

3.3 Sviluppo

La fase di sviluppo prevedeva l’implementazione delle scelte e delle componenti considerate in fase di progettazione. Al completamento di ogni componente, era previsto un collaudo che ne accertasse il funzionamento. Lo sviluppo `e consistito in cinque fasi principali susseguitesi rigidamente.

• Installazione memorie flash con pfSense in ogni firewall e configurazione pfSense

• Installazione firewall e Gateway[G] Wireless in ogni sede

• Installazione e configurazione del cluster server centrale, del firewall centrale e dello storage presso Netech

• Installazione OpenVPN e configurazione

• Collaudo sistema

3.3.1 Installazione memorie flash con pfSense e configurazione

Tramite un USB 2.0 Reader/Writer Memory Adapter simile a quello di figura 3.17 `e stato possibile la semplice scrittura su compact flash del file immagine di PfSense 2.0, disponibile per il download dal sito ufficiale. Una volta inserita la compact flash nel- l’alloggio dedicato all’interno dei firewall Soekris, il sistema operativo era pronto per la configurazione tramite l’ interfaccia web di PfSense.

Figura 3.18: USB 2.0 Reader/Writer Memory Adapter

Configurazione PfSense

Accedendo per la prima volta all’interfaccia web di PfSense si visualizza la schermata di login. Di default username e pasword sono admin e pfsense. La prima volta che si

(34)

CAPITOLO 3. LO STAGE 27 accede in questo modo tramite WebGUI, si avvia automaticamente la schermata iniziale del Wizard[G] (Setup Wizard Starding Screen, figura 3.18 ).

Figura 3.19: Setup Wizard Starding Screen

La schermata successiva del Wizard (General Information Screen, figura 3.19) chiede il nome del router PfSense e il dominio in cui risiede. L’hostname può essere ovviamente qualsiasi. In questo caso: fw-il nome di una delle sedi. Il dominio può essere globale o locale se locale: qualcosa.local. L’hostname e il domain name sono successivamente combinati per creare il nome di dominio qualificato del router. Se si conoscono i DNS (primary e secondary) vanno inseriti esplicitamente altrimenti se si utilizza un tipo di connettività WAN dinamico come DHCP, questi vengono inseriti automaticamente dal ISP (internet service provider ).

Figura 3.20: Setup Wizard general info

(35)

CAPITOLO 3. LO STAGE 28 La schermata successiva (NTP and Time Zone Setup Screen, figura 3.20) permette di impostare il server NTP (Network Time Protocol ) e la time zone in cui risiede questo server. A meno che non ce ne sia uno specifico prescelto, `e meglio lasciare il time server hostname di default (0.pfsense.pool.ntp.org). Che recupera un server casuale da un pool di rinomati e affidabili NTP server.

Figura 3.21: NTP and Time Zone Setup Screen

Il passo successivo del Wizard prevede la configurazione dell’interfaccia WAN. La prima scelta riguarda il tipo di WAN. Di default DHCP, che di fatto rappresenta la scelta necessaria al caso (figura 3.21).

Figura 3.22: WAN type

Scegliendo il tipo dinamico, si passa direttamente all’ultima fase di configurazione WAN(Built-in Ingress Filtering Options, figura 3.22). Abilitando i due blocchi, si proi- bisce al traffico non valido di accedere alla propria rete. Abilitando Block RFC 1918 Private Networks, bloccher`a network registrate private come 192.168.x.x e 10.x.x.x di connettersi all’indirizzo WAN. Il secondo blocca le reti Bogon, che non dovrebbero mai apparire nelle tavole di routing di Internet e di conseguenza non dovrebbero mai apparire nell’indirizzo di origine dei pacchetti ricevuti.

Conclusa la configurazione dell’interfaccia WAN il Wizard fa accedere alla configurazione dell’interfaccia LAN. Inizialmente con la richiesta di inserimento del IP della LAN e della maschera di sottorete (figura 3.23). In questo caso una preventiva mappatura di indirizzi per ogni sede `e stato il requisito fondamentale per poter poi configurare adeguatamente ogni firewall lato LAN.

(36)

Figura 3.23: Built-in Ingress Filtering Options

Figura 3.24: IP LAN

Infine per completare la configurazione viene richiesta la modifica della password amministratore. Una volta cambiata il Wizard `e completato e nella schermata finale (figura 3.24) `e richiesto il ricaricamento di PfSense per l’aggiornamento.

Figura 3.25: Completamento Wizard

(37)

CAPITOLO 3. LO STAGE 30 Grazie al file di configurazione XML usato da PfSense anche il sistema di backup di qualsiasi configurazione `e molto semplice (figura 3.25). Inoltre `e possibile scaricare direttamente in locale il file di configurazione (config-hostname-timestamp.xml) e importare quindi le medesime configurazioni in altri router/firewall.

Figura 3.26: Backup GUI

Successivamente, il lavoro si `e concentrato sulla riproduzione delle medesime regole di traffic shaping presenti nel vecchio firewall Dolomitissime su ogni firewall soekris.

Tramite il gi`a citato software Remote Desktop `e stato possibile accedere e visionare la configurazione del vecchio firewall Dolomitissime da replicare (origini, destinazioni, protocolli).

Accedendo alla sezione firewall della WebGUI di PfSense `e possibile vedere tutte le regole di filtering di ogni interfaccia, aggiungerne e modificarle.

Figura 3.27 mostra come siano gi`a inserite le due regole di blocco configurate precedentemente durante l’esecuzione del Wizard. Le azioni possibili sono:

• pass: ovvero permettere il transito

• block: bloccare il transito

• reject: bloccare il transito e inviare un responso per negare il traffico TCP e UDP, informando l’host che ha iniziato il traffico che la connessione `e stata rifiutata.

• log: come pass ma con l’aggiunta di logging

La schermata per creare o modificare una regola firewall esistente `e rappresentata in figura 3.29. Prima di tutto si definisce l’azione tra una delle quattro possibili elencate in precedenza. Inoltre si specificano l’interfaccia coinvolta, il protocollo, infine il tipo e l’indirizzo della sorgente e della destinazione.

3.3.2 Installazione firewall e gateway wireless

La fase successiva prevedeva l’installazione dei gateway wireless e dei firewall Soekris presso ogni sede di Dolomitissime. L’uscita effettuata per configurare ogni sede `e durata

(38)

Figura 3.27: Configurazione vecchio firewall

(39)

Figura 3.28: Firewall WAN rules

Figura 3.29: Schermata creazione/modifica regola firewall

due giorni lavorativi. Ogni sede era sprovvista di gateway wireless, ogni client era cablato direttamente al relativo modem. Ogni visita comprendeva:

(40)

• sostituzione in ogni client dell’antivirus presente con AVG

• sostituzione del modem presente con il gateway wireless

• installazione del firewall soekris con le configurazioni previste

• breve testing (black box) per verificare l’effettiva connettivit`a del sistema da remoto

Figura 3.30: Tragitto uscita installazioni

3.3.3 Installazione e configurazione del cluster server centrale, del firewall centrale e dello storage presso Netech

La figura 3.17 proposta in precedenza nella sezione di progettazione rappresenta l’esatta configurazione server side attualmente presente presso Netech Padova. Questa fase di sviluppo ha compreso le seguenti attivit`a

• installazione hardware delle componenti nella sala server di Netech

• collegamento delle singole componenti

• installazione di citrix Xen Server nelle due macchine server e configurazione di rete

• istanziazione delle macchine virtuali necessarie

(41)

• intallazione dei sistemi operativi necessari in ogni macchina virtuale

• configurazione dello storage tramite iSCSI

3.3.4 Installazione e configurazione OpenVPN

Connettere due siti usando OpenVPN `e molto semplice; un lato `e configurato come client, l’altro come server. Di solito nella connessione site to site si utilizzano chiavi condivise.

Nel modo in cui OpenVPN funziona è quindi richiesto che una estremità del tunnel sia il server, l’altra il client ; non importa quale. In questo caso il main site è rappresentato appunto dal firewall di Netech, i client site sono tutti gli altri firewall delle varie sedi.

E necessario creare una regola sull’interfaccia WAN del firewall che permetta il traffico` (porta TCP 443) altrimenti non sarà possibile alcuna connessione VPN perchè il traffico sarà bloccato. Tramite interfaccia web di PfSense è possibile creare i certificati e impostare le configurazioni del server. In figura 3.31 viene mostrato l’accesso alla schermata Certificate Authority Manager che permette di creare una CA (certificate authority)

Figura 3.31: Schermata creazione CA

(42)

CAPITOLO 3. LO STAGE 35 Successivamente accedendo a System - User Management, va creato un nuovo account per ognuna delle sedi remote (figura 3.32). Nella sezione Certificate va spuntata l’opzione Click to create a user certificate. Ora la CA `e associata al suo certificato.

Figura 3.32: Schermata creazione Account OpenVPNserver

Il passo successivo `a la creazione del server OpenVPN, avviando lo Wizard (figura 3.33). Come tipo di server va selezionato Local User Access

Poi come CA si seleziona quella appena creata e come certificato quello associato (figura 3.34)

Successivamente lo Wizard permette di configurare il server. La prima schermata permette di inserire i dati generali (lifetime, location ecc). Quella successiva(figura 3.35) permette di selezionare su quale interfaccia sar´a pubblicato il server, il protocollo e la porta di comunicazione.

Figura 3.36 mostra come impostare i parametri di crittografia.

(43)

Figura 3.33: Wizard OpenVPN setup

Figura 3.34: Selezione della CA

Figura 3.37 mostra come impostare i parametri di tunneling specificando il range di indirizzi di rete VPN, e il range di quelli locali alla rete dove risiede il server.

Nella configurazione dei client VPN `e necessario che:

• i protocolli corrispondano con quelli impostati nel server

• server host address sia l’indirizzo pubblico del server

• la porta server sia quella del client dedicata alla connessione verso server

• l’algoritmo di cripting sia lo stesso del server

• il range di indirizzi del remote network siano quelli della LAN del server impostati precedentemente

(44)

Figura 3.35: Configurazione OpenVPN Server

Figura 3.36: Configurazione OpenVPN Server 2

3.3.5 Anomalie e difetti riscontrati

In fase di testing del sistema (alpha test) sono emerse alcune anomalie. Di seguito vengono elencate le tre pi`u significative.

(45)

• Dall’analisi del sistema la sede di Sedico, diversamente dalle altre sedi, presentava pi`u classi IP. Una classe di indirizzi per la rete, una per la telefonia voip, un’altra per le stampanti. Tutte le altre sedi invece presentavano correttamente l’unica classe IP associata. Questa anomalia ha costretto ad una revisione dell’intera mappatura degli indirizzi IP delle LAN della sede di Sedico. Successivamente `e stato necessario forzare in ogni firewall il traffico verso l’unica sottorete prevista.

(46)

• A causa di un bug irrisolto di Windows Server 2008, la stampa via terminal server non funzionava. Nessuno trai i workaround esistenti ha risolto il problema. Es- sendosi presentato in fase di sviluppo avanzata risultava impossibile attendere la patch Microsoft di conseguenza il problema `e stato aggirato tramite un apposito software dedicato (remote desktop printing). Il software consiste di una parte client ed una lato server. Il client durante la connessione comunica al server la lista delle stampanti. Al momento della stampa lo spooler usato `e quello del client, in questo modo il problema del sistema operativo non si presenta.

• Durante l’uscita presso il cliente era emerso che molti sistemi operativi di molti client non erano stati aggiornati per molto tempo. Alcuni client erano sistemi Windows XP SP1, uno (nella sede di Sedico) era un windows 2000 SP2, tutti sistemi non supportati dalla maggior parte dei software necessari alla migrazione.

L’aggiornamento ha praticamente raddoppiato i tempi stimati di uscita presso le varie sedi del cliente.

3.4 Verifica e validazione: strategia aziendale

Sebbene sia sempre stata presente una costante attivit`a di verifica durante l’implementazione di ogni componente del sistema, essa ha riguardato principalmente test di fine task di tipo black box. Questo significa che non appena terminata l’implementazione di una componente, una rapida verifica in termini di risultati attesi `e stata considerata sufficiente per passare al compito successivo. Quindi se i risultati dei collaudi corrispon- devano alle attese, la componente, di fatto, era considerata completata e funzionante.

Questo approccio, nonostante si sia rivelato pi`u che sufficiente circa nel 80% dei casi, ha provocato non pochi problemi protrattisi anche successivamente al completamento del mio stage. Ad ogni modo, la loro risoluzione `e sempre stata fuori dalle mie competenze dal momento che richiedeva una considerevole esperienza in materia.

La validazione finale `e consistita in un alpha test globale in cui semplici prove di instradamento di pacchetti hanno permesso di verificare che il traffico effettivo verso e dal sistema seguisse le regole di configurazione. Dettato anche dalle tempistiche molto ri- strette imposte dalla scadenza della consegna, si `e passati alla fase di beta test conclusiva.

Il sistema è stato messo a disposizione del cliente in parallelo rispetto al vecchio sistema in uso di modo che non vi fosse alcuna sospensione del servizio. Nella strategia Netech questo è stato considerato come il test più importante dal momento che ha permesso l’in- dividuazione di ogni anomalia e difetto passati inosservati dalle verifiche in corso d’opera e tramite alpha test. Questa soluzione seppur poco elegante è stata condotta dal momen- to che per contratto, essendo migrati ad un sistema centralizzato, Netech Networks deve svolgere in sede una costante attivitè di monitoraggio del sistema ed eventuale intervento qualora si presentino malfunzionamenti. L’approccio quindi è stato quello di coinvolgere più attivamente il cliente nella fase di validazione. Questa strategia ha quindi alleggerito

(47)

CAPITOLO 3. LO STAGE 40 il carico di lavoro, inerente al collaudo, da parte staff tecnico, con la previsione che esso richiedesse un’importante collaborazione da parte del cliente solo entro le prime setti- mane di vita del sistema. Questo periodo è iniziato alla fine del mio stage e di fatto è durato più delle attese, con conseguente insoddisfazione del cliente. In alcuni casi è stato necessario intervenire con workaround[G]che quindi aggirassero il problema in un primo momento, in modo da mantenere la consistenza nel funzionamento del sistema. Nono- stante questo approccio poco elegante è importante sottolineare che non sono mai state riscontrate anomalie derivanti da una cattiva analisi del problema o da una inadeguata progettazione. Questo significa che i malfunzionamenti più importanti sono attribuibili a inefficienze proprie di tecnologie coinvolte spesso garantite di qualità dai produttori. (es:

Windows Server 2008, requisito esplicitamente richiesto dal cliente). Infine è necessario sottolineare che notevole esperienza dello staff tecnico ha permesso quindi una progettazione pressochè solida, alleggerendo notevolmente ogni attività di verifica e facendo emergere difetti considerevoli solo a valle del sistema.

(48)

Capitolo 4

Valutazione retrospettiva

In questo capitolo vengono raccolte una serie di valutazioni e riflessioni personali su tutto il percorso di stage affrontato.

4.1 Autovalutazione sul rispetto delle attese

Lo stage mi `e stato proposto da un amico che in quel periodo lavorava presso il neonato ufficio tecnico di Netech sotto la supervisione del CTO Andrea Urbani. Ho deciso di accettare la proposta di stage non per soddisfare una particolare passione in merito ma per motivi principalmente di utili`a, dal momento che non ho mai posseduto conoscenze pratiche in un ambito informatico essenziale come quello delle reti.

L’ufficio tecnico essendo appena nato e composto da un ristretto numero di tecnici, intendeva, tramite la proposta di stage, ottenere un ulteriore supporto tecnico che fosse operativo e generoso in tempi relativamente brevi e che potesse quindi agevolare ulteriormente lo sviluppo del progetto Dolomitissime. In parallelo a questo, eventuale supporto e consulenza nei compiti che richiedevano una certa esperienza.

Il mio impegno personale `e stato giudicato buono nella valutazione finale di fine stage redatta dal CTO Andrea Urbani e consegnata al tutori interno; ritengo che questa valutazione rispecchi abbastanza il reale apporto in termini di impegno, nonostante sia stato spesso scoraggiato dalla mole di conoscenze teoriche e soprattutto pratiche necessarie per apportare un contributi sostanziale al progetto. A detta stessa del CTO e del mio tutor esterno, per poter progettare e implementare un progetto come quello Dolomitissime sono necessari anni di esperienza in ambito sistemistico (reti e sistemi operativi).

Alla luce di ci`o, ritengo di non aver prodotto abbastanza in termini di rendimento atteso per i seguenti motivi:

• l’argomento di questo stage riguarda aspetti di pi`u basso livello rispetto a quanto si prefigge di insegnare un corso di laurea in informatica orientato per lo pi`u a fornire solide basi in ambito di sviluppo software

41

(49)

CAPITOLO 4. VALUTAZIONE RETROSPETTIVA 42

• per poter raggiungere un livello di produttività autonoma consistente, avrei dovuto applicare una mole d’impegno ben maggiore. Per molti aspetti e tematiche, al di là dell’esperienza, la quantità di tempo prevista non era sufficiente a raggiungere un’operatività consistentemente adeguata.

• i compiti più cruciali di progettazione e di sviluppo richiedevano una vasta esperienza professionale, nel campo delle reti e dei sistemi operativi. In conseguenza a ciò ho spesso svolto ruoli abbastanza marginali o comunque di complessità minore durante l’avanzamento del progetto. In alcune fasi particolarmente complesse ho semplicemente assistito allo sviluppo.

• l’aiuto ricevuto `e stato a mio parere insufficiente dal momento che spesso le tempistiche dettate dai tempi di consegna non lo permettevano o lo permettevano ma in maniera inadeguata. Influente `e stata anche la non impeccabile organizzazione che il neonato ufficio tecnico ha manifestato soprattutto nelle prime fasi di sviluppo, forse troppo confidente nella propria esperienza e nel successo ottenuto in progetti simili sviluppati antecedentemente.

4.2 Conoscenze acquisite

Grazie a questo stage ho comunque acquisito molte conoscenze teoriche e pratiche in ambito di sistemi operativi ma soprattutto di reti. La maggior parte delle tecnologie di supporto erano di semplice comprensione e utilizzo. Pi`u complessi gli aspetti avanzati di configurazione. Di seguito un elenco delle principali conoscenze acquisite:

• Cos’`e una VPN, come funziona e come progettarla al meglio anche se ad un livello di astrazione ancora troppo elevato per poterne implementare una ex novo o per eventualmente risolvere anomalie di una certa importanza.

• Come funziona concretamente un firewall di sicurezza avanzata, i protocolli coinvolti, come configurarlo ad un livello base tramite il il sistema operativo PfSense, dotato di interfaccia web che semplifica notevolmente questa attivit`a.

• Come funziona concretamente la configurazione di una rete VPN tramite OpenVPN abbinato a PfSense, i protocolli coinvolti, e soprattuto quanto `e semplificata questa configurazione rispetto ad una classica VPN IPsec-L2TP.

• Come progettare e configurare al meglio un cluster server in fail over con dispositivo di storage esterno iSCSI sempre tramite modulo software di supporto. Come funziona l’assistenza tecnica di una macchina server aziendale (DELL).

• Cos’`e e come funziona in generale un hypervisor, che funzionalit`a offre, come in- stallarlo correttamente su di un server, che possibili configurazioni architetturali esistono in merito.

(50)

CAPITOLO 4. VALUTAZIONE RETROSPETTIVA 43

• In generale quali sono le migliori tecnologie da prendere in considerazione attualmente per un progetto simile.

4.3 Conoscenze richieste

La figura del sistemista richiede ampia e profonda conoscenza in ambito si sistemi operativi e di reti di calcolatori. Un progetto simile a mio parere richiede le seguenti capacit`a, conoscenze ed esperienze:

• Estesa conoscenza in ambito di sistemi operativi principalmente unix-like, congiuntamente ad una lunga esperienza pratica.

• Profonda conoscenza dei protocolli di rete pi`u importanti, conoscenza delle principali differenze tra protocolli che svolgono ruoli simili, vasta conoscenza delle tecnologie pi`u semplici ed efficaci che si avvalgono di tali protocolli.

• Vasta conoscenza ed esperienza riguardo alle tecnologie hardware che implementano macchine client, macchine server, dispositivi firewall, gateway, switch, dispositivi di storage, in modo da poter orientare la scelta verso il miglior compromesso tra costi, prestazioni, affidabilità, servizio di manutenibilità, semplicità di utilizzo, qualità del software di supporto.

• Buona conoscenza delle tecnologie e dei protocolli al servizio della sicurezza e di- mestichezza nell’avvalersene per garantire un adeguato livello di protezione dei dati.

4.3.1 Livello di preparazione didattica pre stage

Come già accennato, ritengo che il mio livello di conoscenze ma soprattutto di esperienza maturate quasi esclusivamente tramite il mio corso di studi, non siano sufficienti per poter collaborare in modo sostanziale e in tempi brevi ad un progetto di tale complessità, dal momento che ritengo sia necessario un lungo periodo di praticantato per acquisire esperienza sufficiente. È necessario sottolineare che il corso di studi triennale di Informa- tica fornisce conoscenze basilari nel vastissimo ambito informatico comprendente sistemi operativi, reti, programmazione, sicurezza, database, tecnologie web ed è principalmente orientato a fornire conoscenze sufficientemente adeguate per potersi inserire il più agil- mente possibile nel mondo dell’analisi, della progettazione e dello sviluppo di sistemi software e tramite il corso di ingegneria del software per imparare a disciplinare queste attività, calate nella realtà aziendale.