Cette page présente la mise en place d'IPsec entre les 3 serveurs srv1, srv2 et srv3.

La configuration a été réalisée avec une très forte influence d'un billet qui explique de façon fort sympathique comment faire quelque chose de similaire sous NetBSD.

Le logiciel que l'on utilise est donc racoon. L'installer est très simple :

apt-get install racoon

Lorsqu'il demande le mode de configuration, on lui indique que l'on utilisera le mode direct.

Afin d'éviter un petit nombre de problème tout de suite, et un grand nombre plus tard, je vais attribuer a chaque serveur une IP qui lui sera propre, et correspondra a son IP privée IPsec.

srv1: 172.16.0.1/32
srv2: 172.16.0.2/32
srv3: 172.16.0.3/32

Le but de cette IP est que chaque machine ai une IP qui servira explicitement a parler avec ses peers IPsec via les tunnels.

On ajoute donc l'adresse en local sur la machine, ainsi que des routes explicite a partir de cette interface vers ses peers. L'interface n'ayant que peux d'importance, et ne souhaitant pas polluer une interface existante, je vais utiliser l'interface dummy0.

On ajoute donc dans /etc/network/interfaces :

# srv1
auto dummy0
iface dummy0 inet static
        address 172.16.0.1
        netmask 255.255.255.255
        up ip route add 172.16.0.2 via 172.16.0.1
        up ip route add 172.16.0.3 via 172.16.0.1

On changera simplement les IPs pour les deux autres serveurs.

Maintenant, la configuration IPsec se fait en 3 parties.

La première partie se fait dans /etc/racoon/racoon.conf. Elle correspond au mode de fonctionnement d'IPsec, des informations sur les méthodes de négociation, de chiffrement, de timeout, …

/etc/racoon/racoon.conf

path pre_shared_key "/etc/racoon/psk.txt";

padding {
    maximum_length 20;
    randomize off;
    strict_check off;
    exclusive_tail off;
}

listen
{
    isakmp 1.1.1.2 [500];
}

remote anonymous
{
    exchange_mode main;
    dpd_delay 20;

    weak_phase1_check on;

    proposal
    {
        encryption_algorithm 3des;
        hash_algorithm sha1;
        authentication_method pre_shared_key;
        dh_group 2;
    }
}

sainfo anonymous
{
    pfs_group 2;
    encryption_algorithm 3des;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

On notera que le fichier contient l'interface publique a utiliser pour communiquer en IPsec avec les autres. Il est important de la modifier de façon adéquate sur les deux autres serveurs.

Au début du fichier, nous indiquons que nous utilisons des clef partagées (PSK - Pre-Shared Key). La deuxième étape est donc de définir ces clefs.

Le fichier /etc/racoon/psk.txt contiendra simplement pour nous l'IP publique du peer, et la clef partagée a utiliser avec celui-ci.

/etc/racoon/psk.txt

# Srv1
1.1.2.2         S3cr3tB3tw33n$rv1&$rv2
1.1.3.2         S3cr3tB3tw33n$rv1&$rv3

# Srv2
1.1.1.2         S3cr3tB3tw33n$rv1&$rv2
1.1.3.2         S3cr3tB3tw33n$rv2&$rv3

# Srv3
1.1.1.2         S3cr3tB3tw33n$rv1&$rv3
1.1.2.2         S3cr3tB3tw33n$rv2&$rv3

Bien évidement, les clefs partagées utilisées ici sont purement arbitraire, et il est préférable de les choisir avec un peu plus d'antropie. (par exemple avec un apg en une taille de clef raisonable… apg -a 1 -m 64)

Il ne nous reste plus qu'a définir les SPD/SPA. Des informations clefs permettant a IPsec de savoir quels paquets doivent passer dans un tunnel et vers ou…

Cela se configure dans le fichier /etc/ipsec-tools.conf. La configuration est un peu laborieuse, elle inclus les réseaux sources et destination, ainsi que les IP publiques source et destination du tunnel, avec des informations d'encapsulation… dans les deux sens.

Pour srv1:

#!/usr/sbin/setkey -f

## Flush the SAD and SPD
flush;
spdflush;

# Srv1 <-> Srv2
spdadd 172.16.0.1/32 172.16.0.2/32 any -P out ipsec
        esp/tunnel/1.1.1.2-1.1.2.2/require;
spdadd 172.16.0.2/32 172.16.0.1/32 any -P in ipsec
        esp/tunnel/1.1.2.2-1.1.1.2/require;

# Srv1 <-> Srv3
spdadd 172.16.0.1/32 172.16.0.3/32 any -P out ipsec
        esp/tunnel/1.1.1.2-1.1.3.2/require;
spdadd 172.16.0.3/32 172.16.0.1/32 any -P in ipsec
        esp/tunnel/1.1.3.2-1.1.1.2/require;

Pour srv2:

#!/usr/sbin/setkey -f

## Flush the SAD and SPD
flush;
spdflush;

# Srv2 <-> Srv1
spdadd 172.16.0.2/32 172.16.0.1/32 any -P out ipsec
        esp/tunnel/1.1.2.2-1.1.1.2/require;
spdadd 172.16.0.1/32 172.16.0.2/32 any -P in ipsec
        esp/tunnel/1.1.1.2-1.1.2.2/require;

# Srv2 <-> Srv3
spdadd 172.16.0.2/32 172.16.0.3/32 any -P out ipsec
        esp/tunnel/1.1.2.2-1.1.3.2/require;
spdadd 172.16.0.3/32 172.16.0.2/32 any -P in ipsec
        esp/tunnel/1.1.3.2-1.1.2.2/require;

Pour srv3:

#!/usr/sbin/setkey -f

## Flush the SAD and SPD
flush;
spdflush;

# Srv3 <-> Srv1
spdadd 172.16.0.3/32 172.16.0.1/32 any -P out ipsec
        esp/tunnel/1.1.3.2-1.1.1.2/require;
spdadd 172.16.0.1/32 172.16.0.3/32 any -P in ipsec
        esp/tunnel/1.1.1.2-1.1.3.2/require;

# Srv3 <-> Srv2
spdadd 172.16.0.3/32 172.16.0.2/32 any -P out ipsec
        esp/tunnel/1.1.3.2-1.1.2.2/require;
spdadd 172.16.0.2/32 172.16.0.3/32 any -P in ipsec
        esp/tunnel/1.1.2.2-1.1.3.2/require;

Il ne reste plus qu'a charger tout cela. Pour les clefs, il y a deux commandes possible, il est possible de lancer directement :

/etc/ipsec-tools.conf

ou d'utiliser le script de démarrage :

/etc/init.d/setkey start

Pour lancer racoon, nous pouvons soit le lancer a la main en mode debug (pratique le temps de vérifier que cela fonctionne) :

racoon -F -d -v

ou avec le script d'init pour le lancer en daemon :

/etc/init.d/racoon start

En désactivant le MASQUERADING dans le firewall (nous reviendrons juste après sur le pourquoi, et comment corriger) que nous avons configuré précédement, nous arrivons a avoir une communication :

root@srv1:~# ping -c 4 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
64 bytes from 172.16.0.2: icmp_req=3 ttl=64 time=0.926 ms
64 bytes from 172.16.0.2: icmp_req=4 ttl=64 time=0.846 ms

La perte des premiers paquets est du au temps d'établissement de la connexion. Une fois celle-ci établie, le reste des paquets passent correctement dans les deux sens…

Comme nous venons de le voir, nous avons du désactiver le MASQUERADING afin de pouvoir communiquer via le tunnel. La raison est simple, les paquets qui passent dans le tunnel passent plusieurs fois dans les chaines iptables, et le paquet qui va sortir via ipsec y passe en étant marqué comme sortant vers notre interface net (eth0).

Nous allons donc modifier notre firewall pour ne pas effectuer de MASQUERADING sur des paquets a destinations d'IP privées. (Pour le moment, nous n'avons que des tunnels vers des IPs privées)

Nous modifions donc les firewalls précédent : avant :

# local rules

# eth0 = net, we should masquerade what gets out
$iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

après:

# local rules

# eth0 = net, we should masquerade what gets out
$iptables -t nat -N masq_net
$iptables -t nat -A POSTROUTING -o eth0 -j masq_net
# as ipsec still goes out via eth0 (but ciphered), 
# and we only ipsec to private networks... we don't mask to private IP
$iptables -t nat -A masq_net -d 10.0.0.0/8 -j RETURN
$iptables -t nat -A masq_net -d 172.16.0.0/12 -j RETURN
$iptables -t nat -A masq_net -d 192.168.0.0/16 -j RETURN
$iptables -t nat -A masq_net -j MASQUERADE

Note: ce qui est présenté ici est présenté pour montrer a quel point c'est vraiment pas pratique dans la vrai vie quand on besoin de routage dynamique via IPsec. Nous verrons juste après comment défaire tout ca, et refaire de facon plus conviviale.

Nous avons un tunnel IPsec qui permet au serveurs (srv1, srv2 et srv3) de discuter ensemble. Nous allons voir comment faire communiquer directement les LAN1 et LAN2 entre eux via le même tunnel que srv1 et srv2.

Afin de faire discuter le LAN1 avec le LAN2, le LAN1 avec srv2, srv1 avec le LAN2… il faut ajouter des règles dans ipsec-tools.conf, et les recharger. Et de même sur srv2…

On ajoute sur srv1:

# Net1 <-> Srv2
spdadd 192.168.1.0/24 172.16.0.2/32 any -P out ipsec
        esp/tunnel/1.1.1.2-1.1.2.2/require;
spdadd 172.16.0.2/32 192.168.1.0/24 any -P in ipsec
        esp/tunnel/1.1.2.2-1.1.1.2/require;

# Net1 <-> Net2
spdadd 192.168.1.0/24 192.168.2.0/24 any -P out ipsec
        esp/tunnel/1.1.1.2-1.1.2.2/require;
spdadd 192.168.2.0/24 192.168.1.0/24 any -P in ipsec
        esp/tunnel/1.1.2.2-1.1.1.2/require;

# Srv1 <-> Net2
spdadd 172.16.0.1/32 192.168.2.0/24 any -P out ipsec
        esp/tunnel/1.1.1.2-1.1.2.2/require;
spdadd 192.168.2.0/24 172.16.0.1/32 any -P in ipsec
        esp/tunnel/1.1.2.2-1.1.1.2/require;

Et sur srv2:

# Net2 <-> Srv1
spdadd 192.168.2.0/24 172.16.0.1/32 any -P out ipsec
        esp/tunnel/1.1.2.2-1.1.1.2/require;
spdadd 172.16.0.1/32 192.168.2.0/24 any -P in ipsec
        esp/tunnel/1.1.1.2-1.1.2.2/require;

# Net2 <-> Net1
spdadd 192.168.2.0/24 192.168.1.0/24 any -P out ipsec
        esp/tunnel/1.1.2.2-1.1.1.2/require;
spdadd 192.168.1.0/24 192.168.2.0/24 any -P in ipsec
        esp/tunnel/1.1.1.2-1.1.2.2/require;

# Srv2 <-> Net1
spdadd 172.16.0.2/32 192.168.1.0/24 any -P out ipsec
        esp/tunnel/1.1.2.2-1.1.1.2/require;
spdadd 192.168.1.0/24 172.16.0.2/32 any -P in ipsec
        esp/tunnel/1.1.1.2-1.1.2.2/require;

Après la modif, il suffit de recharger sur les deux serveurs :

/etc/ipsec-tools.conf

# ws1 -> srv2
64 bytes from 172.16.0.2: icmp_req=1 ttl=63 time=1.11 ms
# ws1 -> ws2
64 bytes from 192.168.2.2: icmp_req=1 ttl=62 time=1.46 ms

Et hop, voila, ca marche… mais :

• c'est pompeux
• pas évident a faire a la main
• ca sent le copier/coller, avec des modifs… mais une erreur arrive si vite
• si l'on a 10 réseau de chaque coté, que l'on ne peux pas agrégé… ah bah oui, 100 règles in, et 100 out.

En gros, c'est bien… tant que ça bouge pas.

Et si on ajoutais srv3 a la liste ? non ? pas motivé ? bah moi non plus. Enfin, srv3, ca irait encore… il a pas de sous-réseau avec lui…