Introduzione

Una Virtual Private Network è una rete LAN virtuale over Internet, ovvero è un modo attraverso il quale dei pc connessi a Internet possono scambiare informazioni con una LAN remota preservando la sicurezza e la confidenzialità dei dati scambiati.

In una VPN è possibile implementare la crittografia a livello IP (livello 3 del modello ISO/OSI), pertanto i singoli pacchetti IP verranno crittografati.

L'implementazione di VPN in Linux è realizzata nel pacchetto FreeSWAN. Per assicurare la sicurezza delle comunicazioni viene utilizzata la crittografia.

Il pacchetto FreeSWAN (moduli del kernel IPSEC) supporta per la protezione delle sessioni IP sia la crittografia a chiave simmetrica che quella a chiave asimmetrica.

Nel primo caso (crittografia a chiave privata) ciascun endpoint nel processo di comunicazione ha una propria chiave che deve essere elencata in un comune file di configurazione condiviso fra tutti gli host che comunicano uno con l'altro.

Nel secondo caso ciascun host possiede sia una chiave privata che una pubblica.

La chiave privata è contenuta in un file, ipsec.secret, leggibile soltanto da root.

La chiave pubblica invece deve essere copiata nel file di configurazione comune a tutti gli host della rete, ipsec.conf, in modo che tutti possano effettuare i processi di cifratura/decifratura dei pacchetti IP.

Uno scenario di esempio :

Azienda1 in Europa : 
        LAN 172.16.1.0/16
        Gateway per Internet con IP pubblico 200.123.145.1 
Azienda2 in Asia : 
        LAN 172.16.77.0/16 
        Gateway per Internet con IP pubblico 151.56.34.98 

Possibile politica di protezione delle comunicazioni fra le reti:

Protezione del traffico fra Azienda1 e Azienda2

Questo vuol dire che tutto il traffico fra il Gateway di Azienda1 ed il Gateway di Azienda2 sarà crittografato, ma non lo sarà il traffico all'interno delle singole LAN nè fra ciascun host delle LAN ed il rispettivo Gateway.

In una VPN i Gateway generalmente agiscono come agenti di crittografia di tutto il traffico che passa per essi: tale modalità prende il nome di tunnel.

Gli host invece hanno bisogno di crittografare tutto il traffico ad essi indirizzato (o da essi proveniente) e tale modalità prende il nome di transport.

Qualora un Gateway debba critografare anche tutto il traffico ad esso indirizzato (o che genera) sarà necessario configurarlo anche per supportare la modalità transport.

Nell'esempio di cui sopra i 2 Gateway saranno impostati in modalità tunnel e pertanto sarà necessario avere un file di configurazione della VPN con 2 chiavi , una per il Gateway di Azienda1 e l'altro per il Gateway di Azienda2.

In una configurazione come quella dell'esempio sopra riportato è possibile configurare una VPN a 3 livelli di complessità :

1. Protezione del solo traffico fra Azienda1 e Azienda2 :
   • i 2 Gateway hanno impostata la VPN in modalità tunnel e crittografano tutto il traffico proveniente dalle LAN retrostanti
   • numero delle chiavi da creare 2
2. Protezione di tutto il traffico fra Azienda1 e Azienda2:
   • i 2 Gateway hanno impostata la VPN in modalità tunnel e crittografano tutto il traffico proveniente dalle LAN retrostanti
   • tutti gli hosts delle 2 LAN hanno una chiave eccetto i 2 Gateway (il traffico è protetto anche all'interno delle LAN)
   • numero delle chiavi da creare 2+65536*2
3. Protezione totale :
   • i 2 Gateway hanno impostata la VPN in modalità tunnel e crittografano tutto il traffico proveniente dalle LAN retrostanti
   • tutti gli hosts delle 2 LAN hanno una chiave compresi i 2 Gateway (il traffico è protetto anche all'interno delle LAN)
   • numero delle chiavi da creare 2+65536*2+2

Come si vede il salto in termini di computazioni ed amministrazione della soluzione è fra il punto 1 ed il punto 2, in quanto fra il punto 2 ed il punto 3 quello che cambia è che viene crittografato anche il traffico indirizzato direttamente (o generato direttamente) dai 2 Gateways (che opereranno anche in modalità transport).

Pertanto ancora una volta è necessario ponderare accuratamente le politiche di protezione dei dati e considerare che l'aumento della sicurezza derivante dall'implementazione di una VPN su tutti gli hosts di una LAN è subordinato al throughput della rete e ne condiziona pesantemente le prestazioni.

Descrizione dell'architettura

Implementeremo qui uno schema simile a quello esposto nell'esempio sopra riportato, ovvero :

Azienda1 in Europa : 
        LAN 192.168.1.0/24
        Gateway (hostname debian1) per Internet con IP pubblico 200.123.145.1 
Azienda2 in Asia : 
        LAN 192.168.77.0/24 
        Gateway (hostname debian2) per Internet con IP pubblico 151.56.34.98 

Le politiche di protezione delle comunicazioni fra le reti sono:

Protezione del traffico fra Azienda1 e Azienda2

I 2 Gateway dovranno pertanto essere impostati in modalità tunnel e dovranno utilizzare una crittografia a chiave pubblica per la protezione delle sessioni IP.

Implementazione della soluzione

• Su entrambi i Gateways bisogna installare il pacchetto freeswan

  apt-get install freeswan

• ora spostarsi su uno dei 2 gateway e creiamo le chiavi dei 2 gateways con i comandi:

  ipsec newhostkey --hostname debian1 --output ipsec.secrets.debian1 --bits 4096
  ipsec newhostkey --hostname debian2 --output ipsec.secrets.debian2 --bits 4096

• effettuare poi un cat delle chiavi pubbliche create nel file /etc/ipsec.conf come segue:

  cat /etc/ipsec.secrets.debian1 >> /etc/ipsec.conf
  cat /etc/ipsec.secrets.debian2 >> /etc/ipsec.conf

• modificare poi il file /etc/ipsec.conf come segue:

  conn %default
          leftrsasigkey=uqjmYDkifhvi....
          rightrsasigkey=uvnbIVBV=lfv.....

  dove i valori di leftrsasigkey e rightrsasigkey sono quelli relativi ai campi pubkey contenuti nei file ipsec.secrets.debian1 e ipsec.secrets.debian2. Ricordatevi di eliminare tutto il resto di questi file e di lasciare in ipsec.conf soltanto le chiavi pubbliche come spiegato.

• e aggiungere in coda al file /etc/ipsec.conf le direttive seguenti :

  conn azienda1-azienda2
          type=tunnel
          left=200.123.145.1
          leftsubnet=192.168.1.0/24
          right=151.56.34.98
          rightsubnet=192.168.77.0/24
          auto=start

• muovere il file /etc/ipsec.secrets.debian1 in /etc/ipsec.secrets con il comando:

  mv /etc/ipsec.secrets.debian1 /etc/ipsec.secrets

• ora copiare i file ipsec.conf e ipsec.secrets.debian2 su debian2. Spostiamoci su debian2 e immettere i comandi :

  sftp user@151.56.34.98:/etc/ipsec.conf /etc/ipsec.conf
  sftp user@151.56.34.98:/etc/ipsec.secrets.debian2 /etc/ipsec.secrets

• Ora riavviare il servizio ipsec su entrambi i server con il comando :

  /etc/init.d/ipsec restart

• e controllare che tutto sia filato liscio esaminando il file /var/log/syslog con il comando

  tail -f /var/log/syslog

si dovrebbe vedere un output simile al seguente

IPSEC started....

Informazioni sul corretto avvio di IPSEC nella nostra configurazione sono presenti anche nei file

dmesg
daemon.log
messages

Inoltre si potrà sempre esaminare il file /var/log/auth.log che permetterà di tracciare l'uso di IPSEC in ogni pacchetto di rete.

CategoryDaRevisionare CategoryInternet