Attenzione! Questa è una Pagina di prova. Le informazioni riportate potrebbero essere incomplete, errate e potenzialmente pericolose. Per contribuire alla realizzazione di questa pagina consultare la discussione di riferimento.

Guida verificata con Ubuntu: 24.04

Problemi in questa pagina? Segnalali in questa discussione

Introduzione

Lo scopo di questa pagina, è quello di creare un tunnel per la comunicazione site-to-site tra due hosts, basato sul nuovo standard di sicurezza ipsec/ikev2. "Internet key exchange version2 - IP security".

Uno degli scopi è di usare, quanto piu possibile strumento open source, senza fare uso di client di terze parti, o di strumenti proprietari. Useremo, in particolare, openSSL, ed il suo strumento "pki". Sceglierò di autenticare i due hosts che sono entrambi connessi ad internet, ma appartenenti a domini di rete distinti, attraverso l'uso di certificati SSL, e non della classica combinazione username/password. L'ente che fornirà la "garanzia" di autenticità di entrambi gli host, sarà quella che viene chiamata una "Certification Authority£. Questa certification authority verrà creata localmente, e sarà poi configurata su entrambi gli hosts. Logicamente, la prova che faremo sarà locale, ma esistono reali certification authority riconosciute con vari gradi di autorevolezza sui diversi domini di rete, e nessuno vieta all'utente di acquistare un vero certificato SSL per la connessione ma, per il momento quest'ultima ipotesi sarà marginale, in quanto vogliamo creare localmente anche la certification Authority (CA).

Una particolarità di questa procedura, è che creeremo i certificati del client anche in formato PKCS12, ovvero in un formato che sia idoneo allo smartphone.

Questo significa che anche uno smartphone sarà in grado di connettersi con connessione VPN protetta al server, usando il certificato.

La configurazione dunque è questa: ci sarà un server ed un client che stabiliranno tra di loro il tunnel ipsec/ikev2. In realtà la definizione di server/client è, in questo caso, impropria in quanto entrambi gli host potranno liberamente cominciare una comunicazione in qualunque momento, però per configurare la connessione è utile questa iniziale distinzione.

Dunque il client sarà di questo tipo:

CLIENT: Un host con installato il pacchetto openssl, e strongswan. Al momento il mio pacchetto è questo:

||/ Name           Version          Architecture Description
+++-==============-================-============-=================================
ii  strongswan     5.9.5-2ubuntu2.3 all          IPsec VPN solution metapackage
ii  openssl        3.0.2-0ubuntu1.16 amd64        Secure Sockets Layer toolkit - cryptographic utility

Questo client è nattato. In particolare il nat è questo: Indirizzo IP locale: 192.168.31.11 Indirizzo IP interfaccia WAN del router: 5.94.x.x

Logicamente, devo censurare l'indirizzo IPv4 dell'interfaccia WAN, perchè è quella reale, e quindi sarei realmente raggiungibile. In ogni caso, questo indirizzo si può facilmente trovare ad esempio aprendo la pagina del browser su un sito come. https://www.mio-ip.it/

SERVER: Questo deve avere installati i medesimi pacchetti del client, ma NON è nattato. In particolare è raggiungibile attraverso un comune indirizzo IPV4 pubblico: 54.3.x.x Anche qui, ho dovuto, in parte censurare l'IP, perche l'interfaccia è raggiungibile. Nel mio caso, faccio esperimenti con un server OVH.

A questo punto generiamo la Certification Authority ed i certificati del server. In particolare la CA sarà identificata dal certificato della CA in formato X509 e dalla chiave della CA. Importante che questi due files non vadano smarriti, in caso contrario, chiunque ne venga in possesso, potrà generare certificati di accesso validi.

Genereremo poi il certificato e la chiave SSL del server:

openssl genrsa -out chiavePrivataCA.pem 2048

openssl rsa -passin pass:"" -in chiavePrivataCA.pem -out chiaveCA.pem

rm chiavePrivataCA.pem

sudo chmod 0600 chiaveCA.pem

ipsec pki --self \
          --ca \
          --lifetime 3650 \
          --dn "C=IT, O=certificatoCA_desktop, CN=CA-desktop" \
          --in chiaveCA.pem \
          --type rsa \
          --outform der > certificatoCAX509.der

#Genero ora la chiave privata del server.
#Questa, è quella che andrà aggiunta sia
#si /etc/ipsec.d/private, che su ipsec.secrets
ipsec pki --gen \
          --type rsa \
          --size 4096 \
          --outform der > chiavePrivata_OVH-server.der

chmod 600 chiavePrivata_OVH-server.der

ipsec pki --pub \
          --in chiavePrivata_OVH-server.der \
          --type rsa | \
ipsec pki --issue \
          --lifetime 730 \
          --cacert certificatoCAX509.der \
          --cakey chiaveCA.pem \
          --dn "C=IT, O=certificato_OVH_server, CN=OVH-server" \
          --san "192.168.1.11" \
          --san "5.94.x.x" \
          --san "54.3.x.x" \
          --flag serverAuth \
          --flag ikeIntermediate \
          --outform der > certificato_OVH-server.der

Questa la lista dei files generati:

certificatoCAX509.der chiaveCA.pem

Esplicativi ! identificano la CA.

Avremo poi:

certificato_OVH-server.der chiavePrivata_OVH-server.der

Questi ultimi due, identificheranno il server. Da notare una cosa importante nello script di generazione dei certificati del server: l'attributo "distinguished name" identificato dall'opzione "--dn" ha una rilevanza molto importante, e ci servirà tra poco. E' questo:

C=IT, O=certificato_OVH_server, CN=OVH-server

Da notare anche gli attributi del "subject alternate name" "--san" qui, vanno indicati tutti gli alias e gli indirizzi degli host che fanno parte del tunnel.

Arrivato a questo punto, mi devo quindi spostare sul server. Come detto poco fa, nel mio caso, il server, è la mia sessione su OVH. Qui, tramite SCP, o tramite file sharing, o come preferite, creerete una directory temporanea di appoggio nella quale copierete questi files:

- certificatoCAX509.der - chiaveCA.pem - chiavePrivata_OVH-server.der - certificato_OVH-server.der

IMmaginando che sul server, come detto poco fa, sia già stato installato openssl, dovreste avere una directory di questo tipo: /etc/ipsec.d/<directory annidate>

Configurate la directory in questo modo: Copiate entrambe le chiavi: chiaveCA.pem e chiavePrivata_OVH-server.der all'interno di /etc/ipsec.d/private . Fate attenzione che, entrambe le chiavi, qui, devono essere di proprietà, e del gruppo root, e devono avere tassativamente i grant del chmod a 0600 .

Copiate poi il certificato della CA, ovvero: certificatoCAX509 sotto /etc/ipsec.d/cacerts Copiate il certificato personale del server, ovvero: certificato_OVH-server.der sotto /etc/ipsec.d/certs

A questo punto andrà impostato il file di configurazione di ipsec lato server. Eccolo:

# Add connections here.

config setup
        charondebug="all"
        uniqueids=no

conn OVH-GCP
        type=tunnel
        auto=add
        compress=no
        keyexchange=ikev2
        fragmentation=yes
        forceencaps=yes
#       authby=secret           
        authby=pubkey           
        ike=aes256-sha256-modp2048,aes128-sha256-modp2048,aes256-sha1-modp2048,aes128-sha1-modp2048,aes256-sha1-modp1024!
        esp=aes256-sha256-modp2048,aes128-sha256-modp2048,aes256-sha1-modp2048,aes128-sha1-modp2048,aes256-sha1-modp1024!
        aggressive=no
        keyingtries=%forever
        ikelifetime=28800s
        lifetime=3600s
        dpddelay=30s
        dpdtimeout=120s
        dpdaction=restart

        left=192.168.1.11
        leftsubnet=192.168.1.2/29
        leftsourceip=192.168.1.11
        leftid="C=IT, O=certificato_client, CN=LeonardoChiodi-client-S24"
        leftcert=certificato_client.der

        right=54.3.x.x
        rightsubnet=0.0.0.0/0
        rightid="C=IT, O=certificato_OVH_server, CN=OVH-server"
        rightcert=certificato_OVH-server.der

Qui i significati dei vari attributi li potete trovare facilmente su internet. La cosa importante da capire è che "left" indica il client. Qui il fatto che il client sia dietro NAT, ovvero che il suo indirizzo IP "non routable", sia 192.168.1.11 non interessa al configuration, è importante chiarire bene la distinzione tra leftid e leftcert. il "leftid" corrisponde al distinguished name, che abbiamo notificato prima. il left cert indica il nome esatto del certificato. Se il certificato si trova al path /etc/ipsec.d/certs allora non è necessario indicare il path assoluto, altrimenti si.

In maniera simile, sul client, genereremo i certificati del client:

#Genero la chiave privata
sudo ipsec pki --gen \
               --type rsa \
               --size 2048 \
               --outform der > chiave_client.der

sudo chmod 0600 chiave_client.der

#Genero ora la chiave ed il certificato, firmati
#dalla CA che ho creato nella sequenza server.
sudo ipsec pki --pub \
               --in chiave_client.der \
               --type rsa |\
ipsec pki      --issue \
               --lifetime 730 \
               --cacert certificatoCAX509.der \
               --cakey chiaveCA.pem \
               --dn "C=IT, O=certificato_client, CN=LeonardoChiodi-client-S24" \
               --san "54.3.x.x" \
               --san "192.168.1.11" \
               --san "5.94.x.x" \
               --outform der > certificato_client.der

#A questo punto, converto la chiave del client in PKCS12 
#per poterla usare sullo smartphone:

#Converto le chiavi
openssl rsa \
-inform DER \
-in chiave_client.der \
-out chiave_client.pem \
-outform PEM

openssl x509 \
-inform DER \
-in certificato_client.der \
-out certificato_client.pem \
-outform PEM

openssl x509 \
-inform DER \
-in certificatoCAX509.der \
-out certificatoCAX509.pem \
-outform PEM

openssl pkcs12 \
-passout pass:laMiaFichissimaPassword \
-name "Certificato client VPN Leonardo" \
-export \
-in certificato_client.pem \
-out certificatoS24_PKCS12_Leonardo.p12 \
-inkey chiave_client.pem

rm chiave_client.der 
rm certificato_client.pem 
rm certificatoCAX509.pem

Qui, verranno generati: - certificato_client.der - chiave_client.pem Ed in ultimo, anche un - certificatoS24_PKCS12_LeonardoC.p12

Quest'ultimo servirà, per consentire l'accesso alla medesima VPN anche allo smartphone, dopo aver installato sullo smartphone stesso la chiave della CA, il certificato della CA, ed infine il certificato PKCS12.

Sul client andranno fatte le medesime configurazioni illustrate per il server, semplicemente invertendo i ruoli left e right.

Un'ultima configurazione, è quella del file /etc/ipsec.secrets. Questo dovrà avere questa forma: : RSA chiave_client.pem

Importante rispettare la sintassi. I due punti all'inizio. Uno spazio. RSA scritto maiuscolo. Un nuovo spazio. Il nome esatto della chiave. Anche qui, se la chiave si trova sotto /etc/ipsec.private, non andrà indicato il path assoluto, altrimenti, si. Anche qui, il file /etc/ipsec.secrets dovrà essere di proprietà, e di gruppo root e con grant di tipo 0600.

Fatto questo, se non ho dimenticato nulla, si può aprire il tunnel separatamente su server, e su client.

Darei un bel restart:

sudo systenctl restart ipsec && sudo ipsec up OVH-GCP

Questo comando va ripetuto, separatamente su server e su client.

A questo punto, dovrebbe stabilirae la connessione se i certificati sono configurati correttamente dovrebbe creare il tunnel ed annotarlo con "ESTABILISHED" ed inserire la nuova rotta nella tabella di routing. D'ora in avanti, tutti i pacchetti destinati a questo IP verranno automaticamente cifrati prima di essere inviati, e decifrati a destinazione.

Come anticipato poco sopra, anche lo smartphone, per il momento Android, io uso Samsung, non saprei se vale lo stesso per Apple, può usare il suo client VPN standard per connettersi, prima però dovrete installare il certificatoCA dal menu sicurezza, ed anche il certificato P12.

Cosa importante: Nel caso in cui un certificato vengo compromesso/smarrito, questo andrà revocato. La procedura di revoca, prima di tutto, è questa:

ipsec pki --signcrl \
          --reason key-compromise \
          --cacert certificatoCAX509.der \
          --cakey chiaveCA.pem \
          --certs certificato_Leonardo.pem \
          --outform der > crls/certificato_client-REVOCATO.der

Una volta completata questa procedura, verrà aggiunta una nuova entry, al percorso /etc/ipsec.d/crls con il nome indicato, ed indicherà che il certificato specificato alla voce "--certs" deve essere revocato. Anche qui, si usa la Certification Authority per autorizzare la richiesta di revoca di un certificato.

Quando si parla di VPN autenticate, non è tanto una questione di utenze a dare diritti, ma di chi possiede la coppia certificato CA e chiaveCA.


CategoryHomepage CategoryNuoviDocumenti

leonardochiodi/TunnelIPsec_ikev2 (l'ultima modifica è del 24/07/2024 10.23.08, fatta da andreas-xavier)