par 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 !
