ze's sandcastle

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[system:tunnelling|Contexte]]

====== IPsec ======

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
[[http://imil.net/wp/2011/07/29/ya-plus-simple-mais-cest-moins-rigolo/|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 :

<code>
# 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
</code>
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
<code>
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;
}
</code>

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
<code>
# Srv1
1.1.2.2         S3cr3tB3tw33n$rv1&$rv2
1.1.3.2         S3cr3tB3tw33n$rv1&$rv3
</code>
<code>
# Srv2
1.1.1.2         S3cr3tB3tw33n$rv1&$rv2
1.1.3.2         S3cr3tB3tw33n$rv2&$rv3
</code>
<code>
# Srv3
1.1.1.2         S3cr3tB3tw33n$rv1&$rv3
1.1.2.2         S3cr3tB3tw33n$rv2&$rv3
</code>

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:
<code>
#!/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;
</code>

Pour srv2:
<code>
#!/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;
</code>

Pour srv3:
<code>
#!/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;
</code>

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é
[[system:tunnelling:initial|précédement]], nous arrivons a avoir une
communication :
<code>
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
</code>

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

===== firewall =====

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 :
<code>
# local rules

# eth0 = net, we should masquerade what gets out
$iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
</code>
après:
<code>
# 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
</code>


====== Routage de sous-réseau via IPsec ======

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:
<code>
# 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;
</code>
Et sur srv2:
<code>
# 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;
</code>

Après la modif, il suffit de recharger sur les deux serveurs :
  /etc/ipsec-tools.conf

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

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...
ze's sandcastle

User Tools

Site Tools

Page Tools
