Table of Contents

IPsec VPN Strongswan su Debian 10 Buster

Pacchetti da installare:

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.

File di configurazione

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"

Host remoto (right) dietro NAT

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.

Configurazione Shorewall

/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

Abilitare e avviare il servizio

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

Verifica

Avvio della connessione

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.

Tracciato tcpdump

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]

Verifica stato della connessione

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.

Connessione PSK fallita

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) ]

Servizi systemd

Processi in esecuzione

Tool da riga di comando

Alternativa charon-systemd

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.

Pacchetti da installare per charon-systemd

Servizi systemd per charon-systemd

Processi in esecuzione per charon-systemd

Debug charon-system

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)

Web Referencese