|
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. |
Indice
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.derQuesta 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.derQui 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.pemQui, 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.derUna 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.