13 décembre 2024

Tuto Strongswan, partie I : Installation et mise en place du tunnel

Article révisé le 27 Septembre 2020.

Première partie de la série de tutoriels sur la mise en place d’un lien IPSEC avec Strongswan.

Nous allons installer la bête et mettre en place le tunnel.

Évidement, comme mon architecture est particulière, y’aura de la bidouille.

Et si besoin de se remémorer l’architecture, c’est ici.

 

I – Installation

On installe Strongswan sur les deux VMs VPN :

vpnX# apt install strongswan

Côté sécurité Strongswan peut fonctionner avec un système de certificats.
Il peut également utiliser une clé partagée, c’est ce que nous allons faire ici, histoire d’aller rapidement à ce qui nous intéresse.
Je ferais cependant un article sur ce point plus tard.

A – Configuration VPN A (Dedibox)

Dans le fichier /etc/ipsec.conf :

config setup
        charondebug="all"
        uniqueids=yes
        strictcrlpolicy=no

conn vpn
        authby=secret
        left=%any
        leftsubnet=10.20.1.0/24
        right=IP.DOMICILE
        rightsubnet=10.168.1.0/24

        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev2
        mobike=no

        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        auto=start

Dans le fichier /etc/ipsec.secrets :

IP.DEDIBOX IP.DOMICILE : PSK 'maclesecrete'

B – Configuration VPN B (Domicile)

Dans le fichier /etc/ipsec.conf :

config setup
        charondebug="all"
        uniqueids=yes
        strictcrlpolicy=no

conn vpn
        authby=secret
        left=%any
        leftsubnet=10.168.1.0/24
        right=IP.DEDIBOX
        rightsubnet=10.20.1.0/24

        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev2
        mobike=no

        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        reqid=10
        auto=start

Le reqid=10 sera utile pour plus tard.

Dans le fichier /etc/ipsec.secrets :

IP.DOMICILE IP.DEDIBOX : PSK 'maclesecrete'

 

C – Configuration spécifique sur les deux VPNs

Autre petite chose à modifier sur chaque VPN, lié au fait que les VPNS ne soient pas sur les gateways de mes réseaux.

Par défaut, Ipsec monte des routes curieuses ( sur A, gateway A définie pour atteindre réseau B).
J’ai essayé pas mal de configurations différentes, à chaque fois, elles étaient présentes et fausses.

Bref, autant s’en débarrasser en demandant explicitement qu’il ne fasse rien.

Dans le fichier /etc/strongswan.d/charon.conf, trouvez la ligne

# install_routes = yes

et changez en

install_routes = no

Et ceci pour les deux Vpns.

D – Configuration des routeurs

Avant tout, il faut bien pense à rediriger les ports UDP 500 et 4500 vers les VM VPNs :

1 –  Routeur A,  Dedibox
routeurA# iptables -t nat -A PREROUTING -d IP.DEDIBOX -p udp  -m multiport --dports 500,4500 -j DNAT --to-destination 10.10.1.2
routeurA# iptables -t filter -A FORWARD -p udp -d 10.10.1.2 -m multiport --dports 500,4500 -j ACCEPT

La, le routeur communique avec le VPN  sur 10.10.1.0/24 vu qu’il s’agit d’une connexion Internet <-> Serveur, pour l’établissement du tunnel.

2 – Routeur B,  domicile

Comme je suis derrière ma box opérateur et que ce routeur est en 192.168.1.1,  en amont sur la box, je redirige les ports (udp 500 et 4500) sur 192.168.1.1 (l’adresse de ma VM routeur).

Au passage, on regarde pas si y’a pas une option Ipsec PassThrough (VPN) à activer (c’est le cas sur la box fibre SFR).
De mémoire, c’est le cas aussi sur une Freebox et ça doit être pareil pour les autres FAI je pense.

Puis sur le routeur lui même :

routeurB# iptables -t nat -A PREROUTING -d 192.168.1.1 -p udp  -m multiport --dports 500,4500 -j DNAT --to-destination 10.168.1.2
routeurB# iptables -t filter -A FORWARD -p udp -d 10.168.1.2 -m multiport --dports 500,4500 -j ACCEPT

 

Si au niveau blocage, en amont, on a fait le gros bourrin, faudra p’tet faire :

iptables -A FORWARD -p esp -j ACCEPT
iptables -A FORWARD -p ah -j ACCEPT

( les protocoles utilisés par Ipsec.)

II – Mise en place du tunnel

Maintenant, on va lancer le tunnel et pour cela, c’est simplement :

vpnX # ipsec start

sur les deux serveurs, peu importe l’ordre.

Et si tout va bien, on peut voir que le tunnel est UP :

vpnX# ipsec status

Ce qui donne, coté VPN A :

Security Associations (1 up, 0 connecting):
vpn[34]: ESTABLISHED 6 minutes ago, 10.10.1.2[IP.DEDIBOX]...IP.DOMICILE[IP.DOMICILE]
vpn{32}: INSTALLED, TUNNEL, reqid 32, ESP in UDP SPIs: c3ad330b_i c68f2171_o
vpn{32}: 10.20.1.0/24 === 10.168.1.0/24

et coté VPN B :

Security Associations (1 up, 0 connecting):
vpn[32]: ESTABLISHED 6 minutes ago, 10.168.1.2[IP.DOMICILE]...IP.DEDIBOX[IP.DEDIBOX]
vpn{31}: INSTALLED, TUNNEL, reqid 10, ESP in UDP SPIs: c68f2171_i c3ad330b_o
vpn{31}: 10.168.1.0/24 === 10.20.1.0/24

Il existe également la commande :

# ipsec statusall

qui est un peu plus bavarde.

C’est bon, on a déjà fini ?

Bah non, car avec mes architectures alambiquées, il était convenu que ça allait faire des trucs « bizarres ».

Le premier test qu’on peut faire, c’est de s’assurer que les deux VPNs se voient bien mutuellement.

Depuis le vpnB (domicile) :

vpnB# ping 10.20.1.2

Yeah ! Mais ne nous réjouissons pas trop vite :

vpnA# ping 10.168.1.2

Ha, ça ne marche pas …

Et sur VpnB :

vpnB# tcpdump icmp -i any

Il est comme Sœur Anne… Il ne voit rien venir…

Pourquoi ça ne passe pas ? On va essayer de le comprendre en regardant comment fonctionne Ipsec

 

III – Fonctionnement

A – Les Policies IP

Ipsec passe par les IP policies, agissant au niveau kernel.

Pour en prendre connaissance :

vpnX# ip xfrm policy

Ce qui doit donner sur le serveur VPN A :

src 10.168.1.0/24 dst 10.20.1.0/24
    dir fwd priority 187712 ptype main
    tmpl src IP.DOMICILE dst 10.10.1.2
        proto esp reqid 32 mode tunnel
src 10.168.1.0/24 dst 10.20.1.0/24
    dir in priority 187712 ptype main
    tmpl src IP.DOMICILE dst 10.10.1.2
        proto esp reqid 32 mode tunnel
src 10.20.1.0/24 dst 10.168.1.0/24
    dir out priority 187712 ptype main
    tmpl src 10.10.1.2 dst IP.DOMICILE
        proto esp reqid 32 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
    socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
    socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0 ptype main

Et sur le serveur VPN B :

src 10.20.1.0/24 dst 10.168.1.0/24
    dir fwd priority 187712 ptype main
    tmpl src IP.DEDIBOX dst 10.168.1.2
        proto esp reqid 10 mode tunnel
src 10.20.1.0/24 dst 10.168.1.0/24
    dir in priority 187712 ptype main
    tmpl src IP.DEDIBOX dst 10.168.1.2
        proto esp reqid 10 mode tunnel
src 10.168.1.0/24 dst 10.20.1.0/24
    dir out priority 187712 ptype main
    tmpl src 10.168.1.2 dst IP.DEDIBOX
        proto esp reqid 10 mode tunnel

[fin identique]

Au final, c’est très simple à comprendre , je prend le cas du VPN A :

Cette règle :

src 10.168.1.0/24 dst 10.20.1.0/24
    dir fwd priority 187712 ptype main
    tmpl src IP.DOMICILE dst 10.10.1.2
        proto esp reqid 32 mode tunnel

stipule que le trafic ayant pour source le réseau 10.168.1.0/24 et pour destination le réseau 10.20.1.0/24 en forward, c’est pour le tunnel IPSEC.

Pour celle ci :

src 10.168.1.0/24 dst 10.20.1.0/24
    dir in priority 187712 ptype main
    tmpl src IP.DOMICILE dst 10.10.1.2
        proto esp reqid 32 mode tunnel

le trafic ayant pour source le réseau 10.168.1.0/24 et pour destination le réseau 10.20.1.0/24 en entrée …, la aussi c’est le tunel qui gere.

Celle ci :

src 10.20.1.0/24 dst 10.168.1.0/24
    dir out priority 187712 ptype main
    tmpl src 10.10.1.2 dst IP.DOMICILE
        proto esp reqid 32 mode tunnel

le trafic ayant pour sources le réseau 10.20.1.0/24 et pour destination le réseau 10.168.1.0/24 en sortie…, toujours et encore le tunnel.

Et pour finir, le reste passe passe par main, à savoir le routage classique.

 

B – Et notre problème alors ?

Et bien, c’est simple en fait.

La règle qui fait qu’un paquet sur le VPN A prend le tunnel, c’est celle ci :

src 10.20.1.0/24 dst 10.168.1.0/24
    dir out priority 187712 ptype main
    tmpl src 10.10.1.2 dst IP.DOMICILE
        proto esp reqid 32 mode tunnel

En route, on a ceci :

default via 10.10.1.1 dev eth0 onlink
10.10.1.0/24 dev eth0 proto kernel scope link src 10.10.1.2
10.20.1.0/24 dev eth1 proto kernel scope link src 10.20.1.2

Et un truc pour vous aider à comprendre le problème…

vpnA# ping 10.168.1.2 -I eth1
PING 10.168.1.2 (10.168.1.2) from 10.20.1.2 eth1: 56(84) bytes of data.

Rien la aussi, mais sur VpnB :

vpnB# tcpdump icmp -i any

On constate que le Vpn A arrive bien, avec son ip 10.20.1.2.
Le retour ne se fait pas mais y’a du mieux. Et y’a au moins ce qu’il faut pour comprendre…

S’il sort en 10.20.1.2 sur eth1, il doit sortir en 10.10.1.2 sur eth0…

En fait, au moment ou le kernel génère le paquet, il regarde la table de routage, et pour lui, par défaut, c’est etho sur 10.10.1.2…

Du coup, notre paquet pour 10.168.1.0/24, avec une source 10.10.1.2 ne matche pas la police  ip xfrm (vu qu’elle ne « capte » que ce qui vient de 10.20.1.0/24.)

C’est ballot…

C – Solution

Il faut donc faire en sorte que le VpnA, quand il demande 10.168.1.0/24, le fasse sur eth1.

La solution est tordue mais fonctionne :

On va rajouter une route :

# ip route add 10.168.1.0/24 via 10.20.1.2

On ajoute une route vers lui même et sur son ip 10.20.1.2.

Et la, on peut tester depuis le vpnA :

vpnA# ping 10.168.1.2

Youpee !!

On pourrait aussi modifier les polices XFRM, mais on verra cette manipulation plus tard.

 

IV -Conclusion

La base est en place et les deux concentrateurs peuvent dialoguer. C’est un début !

Maintenant, il faut passer aux autres machines et vous allez voir qu’il y a encore de la manipulation réseau au programme.

Tout ceci, c’est dans l’article Communications entre VMs.


Envie de me soutenir et de me payer un café ? C’est sur la page Don !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *