« IPsec sous debian avec strongswan » : différence entre les versions

De Linux Server Wiki
Aller à la navigation Aller à la recherche
Ligne 113 : Ligne 113 :


==Routage==
==Routage==
Avec cette configuration, il vous suffira de router votre range, par exemple 192.168.1.0/24, vers l'ip distante du tunnel.
<pre>ip route add 192.168.1.0/24 via $REMOTE_TUNNEL dev ipsec0</pre>
Cela fait passer les paquets par le tunnel VTI, qui applique la mark (42 ici), et la marqué détectée permet au paquet de passer par ipsec.

Version du 1 janvier 2020 à 00:46

aptitude install strongswan strongswan-swanctl

Placer la CA dans /etc/ipsec.d/cacerts puis :

cd /etc/ipsec.d/cacerts/
ln -s myca.pem `openssl x509 -hash -noout -in myca.pem`.0

Placer le certificat dans /etc/ipsec.d/certs/
Placer la clé privée dans /etc/ipsec.d/private/

Il faut définir la clé privé dans /etc/ipsec.secrets sous le format ID : TYPE KEY. L'ID peut être vide, contenir une ip, un FQDN, user@FQSN, %any ou any6. TYPE est PSK ou RSA. KEY peut être soit une clé, soit un chemin vers une clé.

: RSA /etc/ipsec.d/private/mykey.key

VTI auth RSA

Basé sur https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN

Dans /etc/strongswan.d/charon.conf, ajoutez l'option suivante :

install_routes = no

ipsec.conf

De manière générale :

  • left* correspond à la machine locale
  • right* correspond à la machine distante


Les champs suivant sont à modifier :

  • left = l'ip de la machine locale (peut être une ip rfc1918)
  • right = l'ip de la machine distante (obligatoirement une ip accessible sur le réseau, donc pas d'ip rfc1918)
  • leftid une manière d'identifier la machine locale (IP, FQDN, etc). En cas d'authentification RSA, cet identifiant devra exister soit au champ CN soit au champ SubjectAltName du certificat local.
  • rightid une manière d'identifier la machine distante (IP, FQDN, etc). En cas d'authentification RSA, cet identifiant devra exister soit au champ CN soit au champ SubjectAltName du certificat distant.
  • leftcert contient le chemin vers le certificat ssl local. La clé privé est définie dans /etc/ipsec.secret
  • rightca contient une manière d'identifier la CA ayant généré le certificat distant.
  • leftsubnet est défini à l'ip locale servant de transport VTI. Vous avez besoin d'un minimum de deux ip pour définir un transport VTI, le choix de /30 est donc à privilégier.
  • rightsubnet est défini à l'ip distante servant de transport VTI.
conn ipsec1
        reqid = 1
        fragmentation = yes
        keyexchange = ikev2
        reauth = yes
        forceencaps = no
        mobike = no
        rekey = yes
        installpolicy = yes
        auto = start
        dpdaction = restart
        dpddelay = 10s
        dpdtimeout = 60s
        left = 211.124.34.153
        right = 92.119.29.26
        leftid = fqdn:nodeA.domain.tld
        rightid = fqdn:nodeB.domain.tld
        ikelifetime = 28800s
        lifetime = 3600s
        ike = aes128gcm128-sha512-modp4096!
        esp = aes128gcm128-sha256-modp2048!
        leftauth = pubkey
        rightauth = pubkey
        leftcert="/etc/ipsec.d/certs/mycert.crt"
        leftsendcert=always
        rightca="/CN=My Ca/ST=My Location/L=My City/O=My Company/OU=My Company Unit/"
        leftsubnet = 10.66.10.2/30
        rightsubnet = 10.66.10.1
        mark = 42
        leftupdown = /etc/ipsec.updown

Notez l'option mark = 42 qui devra être équivalente sur la définition du tunnel VTI au niveau de linux, sinon les paquets le traverserons pas ipsec.

Lancement

ipsec start
ipsec status
ipsec statusall

création de l'interface

LOCAL_IP=211.124.34.153
REMOTE_IP=92.119.29.26
LOCAL_TUNNEL=10.66.10.2
REMOTE_TUNNEL=10.66.10.1

ip tunnel add ipsec0 local $LOCAL_IP remote $REMOTE_IP mode vti okey 42 ikey 42
ip link set ipsec0 up
ip addr add ${LOCAL_TUNNEL}/30 remote ${REMOTE_TUNNEL}/30 dev ipsec0
sysctl -wq net.ipv4.conf.ipsec0.disable_policy=1 #recommandé

okey et ikey (qui peuvent être substitué par un seul et unique key) doivent être équivalent à la mark défini dans ipsec.conf

A ce stade, seul le tunnel sera joignable (10.66.10.1 et 10.66.10.2) car ipsec a installé une policy restrictive (ip xfrm policy).
Si d'autres ranges doivent être joignable de part et d'autres du VPN (ce qui est probable sinon vous n'utiliseriez pas VTI), vous avez deux solutions : désactiver l'installation automatique des policy et installer votre policy manuellement, ou modifier la configuration d'ipsec.

Solution 1 : installation manuelle des policy

  • Passez installpolicy à no dans /etc/ipsec.conf
  • Installez votre propre policy ouverte :
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 368255 ptype main mark 0x2a tmpl src $REMOTE_IP dst $LOCAL_IP proto esp reqid 1 mode tunnel
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 368255 ptype main mark 0x2a tmpl src $REMOTE_IP dst $LOCAL_IP proto esp reqid 1 mode tunnel
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 368255 ptype main mark 0x2a tmpl src $LOCAL_IP dst $REMOTE_IP proto esp reqid 1 mode tunnel

Solution 2 : modification de la configuration IPsec

Note : Cette solution est compatible avec pfsense depuis la version 2.4.4-p3

Dans ipsec.conf :

  • maintenez installpolicy = yes
  • Modifiez

Routage

Avec cette configuration, il vous suffira de router votre range, par exemple 192.168.1.0/24, vers l'ip distante du tunnel.

ip route add 192.168.1.0/24 via $REMOTE_TUNNEL dev ipsec0

Cela fait passer les paquets par le tunnel VTI, qui applique la mark (42 ici), et la marqué détectée permet au paquet de passer par ipsec.