Pacchetti da installare:
/etc/ipsec.conf e avvia il demone charon, installato per dipendenza diretta da strongswan e strongswan-charon.strongswan.La soluzione Debian supporta le connessioni IKEv1 e IKEv2.
In alternativa al pacchetto strongswan è possibile installare charon-systemd, che offre alcuni vantaggi in termini di semplicità di integrazione con systemd, ma non utilizza il tradizionale file di configurazione /etc/ipsec.conf né i tradizionali processi /usr/lib/ipsec/starter e /usr/lib/ipsec/charon.
Qesti gli indirizzi IP coinvolti:
/etc/ipsec.conf
config setup
# strictcrlpolicy=yes
# uniqueids = no
charondebug="all"
# More control on Charon debug. Default level is 1 "control",
# level 2 is "controlmore".
#charondebug="ike 2, knl 2, cfg 2, net 2, esp 2, dmn 2, mgr 2"
uniqueids = yes
include /etc/ipsec.d/office1-office2.conf
/etc/ipsec.secrets
include /etc/ipsec.d/office1-office2.secrets.inc
/etc/ipsec.d/office1-office2.conf
conn office1-office2
type=tunnel
auto=start
keyexchange=ikev2
authby=secret
left=132.82.168.98
leftsubnet=172.17.48.97/29
right=134.191.21.5
rightsubnet=172.17.48.81/28
ike=aes256-sha256-modp1536
esp=aes256-sha256-modp1536
aggressive=no
keyingtries=%forever
ikelifetime=86400s
lifetime=28800s
dpddelay=30s
dpdtimeout=120s
dpdaction=restart
closeaction=restart
L'opzione closeaction=restart dovrebbe servire a far ripartire la connessione nel caso in cui il remote invii un segnale DELETE, altrimenti si rischia che la connessione termini con questo log e non riparta più:
charon: 07[IKE] received DELETE for IKE_SA office1-office2[5]
charon: 07[IKE] deleting IKE_SA office1-office2[5]
between 132.82.168.98[213.182.68.98]...134.191.21.5[134.191.21.5]
ipsec[30830]: 07[IKE] received DELETE for IKE_SA office1-office2[5]
ipsec[30830]: 07[IKE] deleting IKE_SA office1-office2[5]
between 132.82.168.98[213.182.68.98]...134.191.21.5[134.191.21.5]
/etc/ipsec.d/office1-office2.secrets.inc (impostare mode 0600):
# ------- Site 1 Gateway (office1-office2) ------- 132.82.168.98 134.191.21.5 : PSK "de66979eaa77587d6b0e74d5bf871565" # ------- Site 2 Gateway (office2-office1) ------- 134.191.21.5 132.82.168.98 : PSK "de66979eaa77587d6b0e74d5bf871565"
Se l'host remoto è dietro NAT è necessario cambiare la configurazione, altrimenti la SA non si stabilisce e nei log si trova qualcosa del genere:
ipsec[21090]: 05[NET] received packet: from 134.191.21.5[4500] to 213.182.68.98[4500] (224 bytes) ipsec[21090]: 05[ENC] parsed IKE_AUTH response 1 [ IDr AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ] ipsec[21090]: 05[IKE] authentication of '10.151.252.18' with pre-shared key successful ipsec[21090]: 05[CFG] constraint check failed: identity '134.191.21.5' required ipsec[21090]: 05[CFG] selected peer config 'office1-office2' unacceptable: constraint checking failed ipsec[21090]: 05[CFG] no alternative config found
Si vede che l'host remoto ha indirizzo IP 10.151.252.18, ma si presenta dietro NAT dall'IP 134.191.21.5. Nonostante la pre-shared key sia corretta, il controllo di identità dell'host remoto viene considerato fallito.
Anche questo messaggio è esplicativo: il match dell'host remoto con IP_pubblico[IP_privato] fallisce:
ipsec[21090]: 09[CFG] looking for peer configs matching 132.82.168.98[%any]...134.191.21.5[10.151.252.18] ipsec[21090]: 09[CFG] no matching peer config found
Nel file di configurazione office1-office2.conf va aggiunta l'opzione rightid per identificare l'host remoto con il suo IP privato:
...
right=134.191.21.5
rightid=10.151.252.18
...
e quindi nel file delle PSK si deve identificare l'host remoto con il suo IP privato:
# ------- Site 1 Gateway (office1-office2) ------- 132.82.168.98 10.151.252.18 : PSK "de66979eaa77587d6b0e74d5bf871565" # ------- Site 2 Gateway (office2-office1) ------- 10.151.252.18 132.82.168.98 : PSK "de66979eaa77587d6b0e74d5bf871565"5"
In alternativa si dovrebbe poter specificare rightid=%any in modo che un qualunque IP privato venga accettato. La PSK dovrebbe potersi selezionare in quel caso tramite l'IP pubblico.
/etc/shorewall/rules
ACCEPT net:134.191.21.5 $FW esp ACCEPT net:134.191.21.5 $FW udp 500 ACCEPT net:134.191.21.5 $FW udp 4500
ATTENZIONE: In effetti la porta 4500/UDP viene usata solo se il traffico IPsec deve attraversare qualche apparato che fa NAT e che non potrebbe trasportare il protocollo ESP (che non ha porte). In tal caso il traffico ESP viene incapsulato in pacchetti UDP con la porta 4500.
/etc/shorewall/tunnels
ipsec net 134.191.21.5 # Remote IPSEC gateway
/etc/shorewall/zones
sec ipv4
/etc/shorewall/hosts
sec eth0:172.17.48.80/28,134.191.21.5 ipsec
In Debian 10 i servizi sono gestiti da systemd: ricordarsi di abilitare il servizio e se necessario avviarlo:
systemctl is-enabled strongswan.service systemctl enable strongswan.service systemctl start strongswan.service
Per avviare la VPN si può utilizzare il comando ipsec start (attenzione, perché questo comando avvia il demone fuori dal controllo di systemd).
ipsec start Starting strongSwan 5.7.2 IPsec [starter]...
In syslog si trovano le seguenti righe:
charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.7.2, Linux 4.19.0-12-amd64, x86_64)
charon: 07[IKE] initiating IKE_SA office1-office2[1] to 134.191.21.5
charon: 07[NET] sending packet: from 132.82.168.98[500] to 134.191.21.5[500] (932 bytes)
charon: 09[NET] received packet: from 134.191.21.5[500] to 132.82.168.98[500] (360 bytes)
charon: 09[IKE] authentication of '132.82.168.98' (myself) with pre-shared key
charon: 09[IKE] establishing CHILD_SA office1-office2{1}
charon: 10[IKE] CHILD_SA office1-office2{1} established with SPIs cdd18e01_i ...
In Debian 10, che utilizza systemd, è opportuno utilizzare systemctl invece di invocare direttamente ipsec (che supporta gli eventuali parametri stop, restart, status, statusall). Vedere sopra come abilitare e avviare il servizio.
Con tcpdump è possibile vedere l'inizio della connessione:
18:10:58.636146 IP 134.191.21.5.500 > 132.82.168.98.500: isakmp: parent_sa ikev2_init[I] 18:10:58.650161 IP 132.82.168.98.500 > 134.191.21.5.500: isakmp: parent_sa ikev2_init[R] 18:10:58.713248 IP 134.191.21.5.4500 > 132.82.168.98.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 18:10:58.714463 IP 132.82.168.98.4500 > 134.191.21.5.4500: NONESP-encap: isakmp: child_sa ikev2_auth[R] 18:10:59.773185 IP 134.191.21.5.500 > 132.82.168.98.500: isakmp: parent_sa ikev2_init[I] 18:10:59.786532 IP 132.82.168.98.500 > 134.191.21.5.500: isakmp: parent_sa ikev2_init[R] 18:10:59.851299 IP 134.191.21.5.4500 > 132.82.168.98.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 18:10:59.852578 IP 132.82.168.98.4500 > 134.191.21.5.4500: NONESP-encap: isakmp: child_sa ikev2_auth[R]
Per verificare lo stato della VPN si utilizza il comando ipsec statusall, ecco un esempio di output per una connessione funzionante:
ipsec statusall
Status of IKE charon daemon (strongSwan 5.7.2, Linux 4.19.0-12-amd64, x86_64):
uptime: 31 seconds, since Feb 04 09:53:12 2021
malloc: sbrk 2437120, mmap 0, used 601632, free 1835488
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
loaded plugins: charon aes rc2 sha2 sha1 md5 mgf1 random nonce x509 ....
Listening IP addresses:
132.82.168.98
192.168.1.2
Connections:
office1-office2: 132.82.168.98...134.191.21.5 IKEv2, dpddelay=30s
office1-office2: local: [132.82.168.98] uses pre-shared key authentication
office1-office2: remote: [134.191.21.5] uses pre-shared key authentication
office1-office2: child: 172.17.48.96/29 === 172.17.48.80/28 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
office1-office2[1]: ESTABLISHED 31 seconds ago, 132.82.168.98[132.82.168.98]...134.191.21.5[134.191.21.5]
office1-office2[1]: IKEv2 SPIs: 16a74d9307ac7ef5_i* 40fc0fa3a279e9f9_r,
pre-shared key reauthentication in 23 hours
office1-office2[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536
office1-office2{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cdd18e01_i 866f2f1a_o
office1-office2{1}: AES_CBC_256/HMAC_SHA2_256_128, 578 bytes_i (10 pkts, 21s ago), ...
office1-office2{1}: 172.17.48.96/29 === 172.17.48.80/28
Se la VPN non è attiva, l'output è vuoto.
Ecco cosa appare in syslog quando una connessione fallisce per via della chiave condivisa PSK:
charon: 13[NET] received packet: from 134.191.21.5[500] to 132.82.168.98[500] (376 bytes) charon: 13[IKE] 134.191.21.5 is initiating an IKE_SA charon: 13[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536 charon: 13[IKE] remote host is behind NAT charon: 14[CFG] looking for peer configs matching 132.82.168.98[%any]...134.191.21.5[134.191.21.5] charon: 14[CFG] selected peer config 'office1-office2' charon: 14[IKE] no shared key found for '%any' - '134.191.21.5' charon: 14[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
strongswan-starter, è responsabile dell'avvio del processo /usr/lib/ipsec/starter.strongswan-starter. Questo servizio viene abilitato, disabilitato, avviato o fermato automaticamente quando si agisce su strongswan.service.strongswan-starter, è un processo invocato dal servizio strongswan.service che provvede a leggere /etc/ipsec.conf.strongswan-charon, è il demone che provvede alla gestione di IKE (il protocollo per lo scambio delle chiavi).strongswan-starter, viene utilizzato per invocare vari tool per la gestione di IPsec. A seconda del parametro passato interagisce con il processo starter oppure charon.Questo demone, fornito dal pacchetto Debian charon-systemd, è alternativo al pacchetto strongswan; non utilizza le configurazioni di /etc/ipsec.conf né fa affidamento a /usr/lib/ipsec/starter. Il programma charon-systemd si interfaccia direttamente con systemd e utilizza il tool da riga di comando swanctl per configurare e comandare IPsec.
Il vantaggio di charon-systemd rispetto a strongswan è una maggiore integrazione con systemd, per cui il servizio relativo ha una implementazione più semplice.
strongswan-charon.charon-systemd. Contiene l'eseguibile swanctl che è il tool da riga di comando per configurare, comandare e monitorare la VPN IPsec.charon-systemd, il nome indica che il servizio basa il suo funzionamento sul tool swanctl.charon-systemd, viene avviato dal strongswan-swanctl.service.Nel caso in cui si sia fatta una configurazione tradizionale con /etc/ipsec.conf, ma si avvia il servizio charon-systemd, questo è il syslog con gli errori (il demone rileva lo scambio IKE, ma fallisce perché manca la configurazione):
charon-systemd[851]: received packet: from 134.191.21.5[500] to 132.82.168.98[500] (376 bytes) charon-systemd[851]: parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ] charon-systemd[851]: no IKE config found for 132.82.168.98...134.191.21.5, sending NO_PROPOSAL_CHOSEN charon-systemd[851]: generating IKE_SA_INIT response 0 [ N(NO_PROP) ] charon-systemd[851]: sending packet: from 132.82.168.98[500] to 134.191.21.5[500] (36 bytes)