rigacci.org

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== IPsec VPN Strongswan su Debian 10 Buster ======

Pacchetti da installare:

  * **strongswan** - Metapacchetto: serve a installare i pacchetti realmente necessari grazie al meccanismo delle dipendenze.
  * **strongswan-starter** - Interpreta i file di configurazione ''/etc/ipsec.conf'' e avvia il demone ''charon'', installato per dipendenza diretta da ''strongswan'' e ''strongswan-charon''.
  * **strongswan-charon** - Demone [[wp>Internet_Key_Exchange|Internet Key Exchange]], installato per dipendenza diretta da ''strongswan''.

La soluzione Debian supporta le connessioni **IKEv1** e **IKEv2**.

In alternativa al pacchetto **strongswan** è possibile installare **[[#alternativa_charon-systemd|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:

  * **Lato Left (host locale)**
    * IP pubblico: **132.82.168.98**
    * Classe IP privata: **172.17.48.96/29** (broadcast 172.17.48.103)
  * **Lato Right (host remoto)**
    * IP pubblico: **134.191.21.5**
    * Classe IP privata: **172.17.48.80/28** (broadcast 172.17.48.95)

**/etc/ipsec.conf**

<file>
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
</file>

**/etc/ipsec.secrets**

<file>
include /etc/ipsec.d/office1-office2.secrets.inc
</file>


**/etc/ipsec.d/office1-office2.conf**

<file>
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
</file>

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ù:

<file>
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]
</file>

**/etc/ipsec.d/office1-office2.secrets.inc** (impostare **mode 0600**):

<file>
# ------- 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"
</file>

===== 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:

<code>
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
</code>

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:

<code>
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
</code>

Nel file di configurazione **office1-office2.conf** va aggiunta l'opzione **rightid** per identificare l'host remoto con il suo IP privato:

<file>
    ...
    right=134.191.21.5
    rightid=10.151.252.18
    ...
</file>

e quindi nel file delle PSK si deve identificare l'host remoto con il suo IP privato:

<file>
# ------- 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"
</file>

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**

<file>
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
</file>

**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**

<file>
ipsec    net    134.191.21.5  # Remote IPSEC gateway
</file>

**/etc/shorewall/zones**

<file>
sec    ipv4
</file>

**/etc/shorewall/hosts**

<file>
sec    eth0:172.17.48.80/28,134.191.21.5 ipsec
</file>

===== Abilitare e avviare il servizio =====

In Debian 10 i servizi sono gestiti da **systemd**: ricordarsi di abilitare il servizio e se necessario avviarlo:

<code>
systemctl is-enabled strongswan.service
systemctl enable strongswan.service
systemctl start strongswan.service
</code>

===== 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**).

<code>
ipsec start
Starting strongSwan 5.7.2 IPsec [starter]...
</code>

In **syslog** si trovano le seguenti righe:

<code>
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 ...
</code>

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|abilitare e avviare il servizio]].

==== Tracciato tcpdump ====

Con tcpdump è possibile vedere l'inizio della connessione:

<code>
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]
</code>
==== 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:

<code>
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
</code>

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:

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

===== Servizi systemd =====

  * **strongswan.service** - Installato dal pacchetto ''strongswan-starter'', è responsabile dell'avvio del processo ''/usr/lib/ipsec/starter''.
  * **ipsec.service** - Installato dal pacchetto ''strongswan-starter''. Questo servizio viene abilitato, disabilitato, avviato o fermato automaticamente quando si agisce su ''strongswan.service''.

===== Processi in esecuzione =====

  * **/usr/lib/ipsec/starter** - Installato dal pacchetto ''strongswan-starter'', è un processo invocato dal servizio ''strongswan.service'' che provvede a leggere ''/etc/ipsec.conf''.
  * **/usr/lib/ipsec/charon** - Installato dal pacchetto ''strongswan-charon'', è il demone che provvede alla gestione di **[[wp>Internet_Key_Exchange|IKE]]** (il protocollo per lo scambio delle chiavi).

===== Tool da riga di comando =====

  * **/usr/sbin/ipsec** - Installato dal pacchetto ''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**.


===== 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 ====

  * **charon-systemd** - Supporto systemd per IPsec client. Svolge funzioni analoghe al pacchetto ''strongswan-charon''.
  * **strongswan-swanctl** - Viene installato per dipendenza diretta da ''charon-systemd''. Contiene l'eseguibile ''swanctl'' che è il tool da riga di comando per configurare, comandare e monitorare la VPN IPsec.

==== Servizi systemd per charon-systemd ====

  * **strongswan-swanctl.service** - Installato dal pacchetto ''charon-systemd'', il nome indica che il servizio basa il suo funzionamento sul tool ''swanctl''.

==== Processi in esecuzione per charon-systemd ====

  * **/usr/sbin/charon-systemd** - Installato dal pacchetto ''charon-systemd'', viene avviato dal ''strongswan-swanctl.service''.

==== 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**):

<file>
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)
</file>

====== Web Referencese ======

  * **[[https://www.tecmint.com/setup-ipsec-vpn-with-strongswan-on-debian-ubuntu/|How to Set Up IPsec-based VPN with Strongswan on Debian and Ubuntu]]**
  * **[[https://wiki.strongswan.org/projects/strongswan/wiki/Charon-systemd|charon-systemd]]**
  * **[[https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/security-edit-dh-group.html|dh-group (Security IKE)]]**
  * **[[https://tools.ietf.org/html/rfc3526|More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)]]**
  * **[[https://shorewall.org/IPSEC.htm|Shorewall IPSEC Tunnels]]**