Le esigenze di connessione tra le sedi remote di un’azienda e l’aumento costante del lavoro in mobilità sono cresciute di pari passo con la qualità e la velocità dei collegamenti a banda larga. La conseguenza logica dei questo scenario è l’utilizzo sempre più capillare dei collegamenti VPN. Questo acronimo significa: Virtual Private Network, rete privata virtuale. Generalizzando: l’utilizzo di infrastrutture “pubbliche” fuori dal proprio controllo (e gestione) per implementare un collegamento sicuro tra le diverse sedi di una azienda o tra un “road warrior” e la propria sede.

La trattazione tecnica dell’argomento è vasta e complessa, le voci di Wikipedia inglese ed italiana offrono estese spiegazioni e parecchi link di approfondimento. Cercherò qui di dare un quadro generale sulle VPN, con i concetti fondamentali e un accenno ai più comuni metodi di implementazione.

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, che un tempo erano l’unica opzione. Tutto ciò porta diversi benefici: i principali sono:

• Economicità: si abbatte il costo delle infrastrutture. La scelta dell’implementazione adeguata in fase di progetto permette di scegliere la soluzione più adeguata al miglior costo sostenibile.
• Semplicità: la tecnologia è molto matura e non richiede skill esoterici.
• Sicurezza: si basa su standard perlopiù aperti e universalmente riconosciuti come sicuri. Con pochi accorgimenti si riescono ad ottenere buoni compromessi tra semplicità di accesso e ragionevole sicurezza.

Il concetto è abbastanza semplice, e adotta il paradigma “hub and spoke“: una sede centrale dalla quale si dipanano i collegamenti verso le sedi remote. (E’ evidente come il modello “mesh” non sia sostenibile nel caso particolare delle VPN). Utilizzando regole opportune si può decidere che ciascuna sede remota acceda esclusivamente al nodo centrale, oppure di abilitare anche il traffico tra le periferie. Nel caso particolare del collegamento tra due sole sedi, il modello è semplificato.

Le soluzioni che si possono adottare sono molteplici e vanno dal semplice server equipaggiato con software open source, a costose appliance ridondate in HA: la scelta dipende dai costi, dall’integrazione con le infrastrutture esistenti, dalla banda necessaria, dal carico di lavoro e dalla criticità del collegamento, tanto per citare alcuni fattori che condizionano la scelta del sistema a cui affidarsi.

In alcuni casi la realizzazione di una VPN site-to-site può essere delegata interamente al fornitore di connettività. E’ una scelta fatta prevalentemente da aziende piccole e medie, spesso senza un reparto IT. In Italia ho incontrato prevalentemente soluzioni di Telecom, che usa le capacità VPN dei router Cisco (credo, correggetemi nei commenti), e di Fastweb, che implementa reti MPLS sulla propria infrastruttura in fibra.

Ci sono molti motivi per utilizzare una VPN, uno dei più comuni è l’accesso remoto ad applicazioni non adatte ad essere pubblicate nativamente. Ad esempio: condivisione di file e applicativi verticali, magari su piattaforme proprietarie. I candidati ideali per l’accesso VPN sono le risorse prive di strumenti nativi per garantire la sicurezza al di là del perimetro aziendale. A seconda del livello di protezione richiesto, sarà cura del sistemista perimetrale decidere, quando possibile, se le risorse vadano posizionate in DMZ oppure se l’accesso debba avvenire direttamente in LAN.

L’implementazione non è esente da problemi: spesso il traffico VPN è sensibile ai router che ne trattano i pacchetti con troppa disinvoltura, oppure va incontro a difficoltà dovute all’impostazione dell’MTU. LA diagnostica non è per nulla agevole: i messaggi syslog sono difficili da interpretare e spesso mostrano solo l’effetto ma non la causa. Per fortuna i casi complicati sono una frazione del totale: molto spesso l’installazione non presenta particolari problemi.

Nel caso di una connessione site-to-site oppure hub and spoke, non è necessario toccare gli host della rete locale, è sufficiente assicurarsi che le sedi distinte abbiano piani di indirizzamento che non si sovrappongano, per evitare problemi di routing e complicate manovre di subnetting. (Fatevi un grosso favore: reti diverse, sempre). La VPN è realizzata tramite software oppure appliance che dialogano con la loro controparte remota, rappresentando l’endpoint della VPN, cioè il luogo in cui i pacchetti in ingresso vengono decrittati ed instradati in chiaro verso l’host di destinazione, ed i pacchetti in uscita vengono criptati, incapsulati ed inviati al gateway remoto.

Nelle implementazioni più semplici, l’endpoint di una VPN è lo stesso firewall che controlla il traffico da e per l’esterno; se invece le due entità non coincidono si renderà necessaria la definizione di una rotta statica sul default gateway, in modo da instradare correttamente il traffico.

Nel caso di utenti mobili o uffici piccolissimi (uno o due host), si utilizza una componente client che connette il nodo direttamente alla rete remota. Generalmente si tratta di software proprietari forniti dai produttori di appliance, che creano una scheda di rete virtuale sulla quale far viaggiare il traffico VPN. In questi casi entrano in gioco meccanismi di ARP proxying e non più di routing. Nella maggior parte dei casi si potrebbero utilizzare gli strumenti nativi che i diversi sistemi operativi mettono a disposizione, ma l’operazione si rivela talmente complicata (almeno nel caso di Windows) che l’uso di questi driver virtuali è universalmente diffuso. In realtà per l’accesso a risorse limitate da parte di pochi client, si potrebbe prendere in considerazione un tunnel SSH, di implementazione ancora più semplice.

Io utilizzo OpenVPN da parecchio tempo e mi trovo molto bene. Non richiede risorse particolari e mi permette di accedere a tutta la mia rete pubblicando una sola porta TCP e senza disporre di un IP pubblico statico.

In linea di principio le diverse appliance sono interoperabili, ma spesso con qualche difficoltà. Scegliendo unità simili molto spesso ci si deve limitare a compilare una o due finestre con gli stessi dati in posizioni complementari.

Per utenti che devono poter lavorare da computer pubblici, chioschi e computer condivisi, le soluzioni basate su SSL-VPN offrono la comodità di poter accedere alla rete remota tramite un browser e un po’ di componenti java, e presentano il vantaggio di funzionare in ambienti fortemente controllati: è sufficiente che passi il traffico SSL su https (TCP/443). Lo svantaggio è la minore integrazione con il sistema e la necessità di dover comunque installare un componente “invasivo” qualora si volesse accedere in modo completo alla rete.

In definitiva le VPN offrono una quantità di vantaggi che le rendono sicuramente interessanti; in cambio è necessaria un po’ di cura nel progetto e un po’ di attenzione alla gestione della sicurezza: i meccanismi di one time password, i token, il controllo attento degli accessi e della gestione degli account (RADIUS), sono alcuni dei metodi da adottare per garantirsi sonni (abbastanza) tranquilli.

Il caso tipico è quello di una rete che usa un router per uscire su internet ed uno per una connessione VPN verso una sede remota. Ne avevo parlato anche qui. Per semplificare le cose in quel post assumo che sia il default gateway a inoltrare il traffico verso l’altro router, in realtà tutto il meccanismo viene gestito tramite messaggi ICMP.

Come l’acronimo lascia intendere (Internet Control Message Protocol), questo protocollo non viene utilizzato per trasmettere dati, anzi non viene proprio impiegato dalle applicazioni (tranne ping e traceroute, ma sono comunque diagnostiche), bensì per trasmettere errori e segnali di controllo per il traffico TCP.

Tornando al caso in questione, sul router che rappresenta il default gateway c’è una static route che reindirizza il traffico destinato alla rete della sede remota verso il router che gestisce la VPN. In realtà il router invia un messaggio ICMP Redirect che induce gli host ad aggiornare la loro tabella di routing per indirizzare il traffico al gateway corretto.

Come prescrive la RFC 1122(*), i messaggi ICMP Redirect sono di pertinenza dei gateway e non devono mai essere inviati dagli host. Inoltre, tutti gli host sono tenuti a onorare tali messaggi utilizzando a tale scopo una “route cache” dinamica. Il primo pacchetto viene inoltrato direttamente dal default gateway al router “secondario” e nel contempo viene inviato all’host origine un ICMP Redirect, che aggiorna la route cache e fa sì che da quel momento in poi il traffico interessato transiti direttamente per il secondo router.

Tutto molto bello, pratico e funzionante. Tranne che per gli IBM AS/400. Malgrado la RFC sia categorica (“A host receiving a Redirect message MUST update its routing information accordingly.”), lo stack TCP/IP degli AS/400 non obbedisce ai messaggi ICMP Redirect e gli ignora bellamente. Nel caso in oggetto quindi, oltre alla rotta statica sul default gateway, che fa funzionare gli host “obbedienti” senza doverli neppure toccare, è necessario inserire una entry direttamente nella tabella di routing dell”AS, altrimenti i pacchetti di ritorno agli host della sede remota non giungerebbero a destinazione.

(*) …che è interessantissima e spiega un fottìo di cose su come funzionano le comunicazioni tra gli host di una rete.