02 / 08 / 2011 – Mise à jour il-ne-faut-pas utiliser lo0 comme interface pivot, il ne faut pas. Pour une raison que j’ignore totalement, aucun autre protocole qu’ICMP n’a jamais fonctionné pendant nos tests, si d’aucuns ont une explication rationelle, je suis toutes ouïes. Le problème est résolu en utilisant les interfaces physiques.
IPsec. À l’évocation de ce terme technique, vous avez avalé d’un trait votre Gin Tonic, vous éteignez votre écran en espérant qu’il s’agisse d’un mauvais rève et vous décrivez des cercles dans votre bureau en vous frappant la tête avec une règle metallique.
Je le sais, j’étais pareil.
Et puis, avec l’ami mat, nous avons lu, épluché, factorisé, testé, pesté, hurlé, et finalement, je vous propose un petite petite bafouille sur l’art de mettre en place un tunnel IPsec entre deux machines NetBSD. Ouais.
Il me semble que cette configuration est assez classique, jugez plutot: une passerelle, chez vous, disposant d’un bridge vers un réseau quelconque d’opérateur qui fournit une adresse IP fixe publique (si ce n’est pas le cas, vous savez ce qu’il vous reste à faire), et de l’autre coté, une machine dédiée dont vous disposez chez l’un des multiples hébergeurs low-cost aujourd’hui disponibles.
Petite particularité, cette dernière, dans mon cas, est une machine virtuelle NetBSD, un domU hebergé par un dom0 Debian/GNU Linux.
En raison de cette particularité, la première étape consiste à manipuler iptables afin de translater les differents protocoles nécessaires à IPsec directement vers ma machine virtuelle. Sur mon dom0, j’ajoute donc les règles suivantes:
# isakmp
-A PREROUTING -i eth0 -p udp -m udp --dport 500 -j DNAT --to-destination 192.168.2.1:500
# isakmp + nat-t
-A PREROUTING -i eth0 -p udp -m udp --dport 4500 -j DNAT --to-destination 192.168.2.1:4500
# protocole ESP
-A PREROUTING -i eth0 -p esp -j DNAT --to-destination 192.168.2.1
# protocole AH
-A PREROUTING -i eth0 -p ah -j DNAT --to-destination 192.168.2.1
Nous considérerons que l’IP publique de cette machine est 1.2.3.4, l’IP privée du domU est 192.168.2.1.
Le logiciel que nous utiliserons pour établir notre tunnel IPsec, d’un coté et de l’autre, sera le fâmeux racoon.
Je vous jette en pâture la configuration simplifiée que j’utilise, cette dernière étant expliquée point par point à cette adresse:
# cat /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 192.168.2.1 [500];
}
remote anonymous
{
exchange_mode aggressive;
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;
}
Notez que je fais écouter isakmp sur l’adresse privée du domU.
Il faudra créer le fichier /etc/racoon/psk.txt avec des droits stricts (0600), qui contiendra l’adresse IP du peer et une passphrase:
# cat /etc/racoon/psk.txt
5.6.7.8 unepassphrasedunfortbeaugabarit
5.6.7.8 étant l’IP publique de ma passerelle.
Coté passerelle, justement, nous créons l’exacte copie de cette configuration en remplaçant l’ip d’écoute de isakmp et l’ip publique présente dans le fichier /etc/racoon/psk.txt par l’IP publique de notre machine hébergée (1.2.3.4, donc).
Ceci étant fait, il faut maintenant indiquer au noyau pour quels sous-réseaux il est nécessaire de crypter le trafic IP. Cette indication est donnée via l’outil setkey, qui lira le fichier /etc/ipsec.conf sous NetBSD (nous y reviendrons). Un peu de concentration, voici son contenu sur la machine hébergée:
# on fait le ménage
flush;
spdflush;
# et on indique nos routes
spdadd 10.0.0.1/32 10.0.0.2/32 any -P out ipsec esp/tunnel/192.168.2.1-5.6.7.8/require;
spdadd 10.0.0.2/32 10.0.0.1/32 any -P in ipsec esp/tunnel/5.6.7.8-192.168.2.1/require;
Ici, 10.0.0.1 est le “réseau” (une IP unique dans mon cas) joignable à travers IPsec, via le tunnel établi entre l’IP privée de mon domU et l’IP publique de ma passerelle. De l’autre côté, le “réseau” est 10.0.0.2.
Afin de clarifier les choses, voici la configuration coté passerelle:
flush;
spdflush;
spdadd 10.0.0.2/32 10.0.0.1/32 any -P out ipsec esp/tunnel/5.6.7.8-1.2.3.4/require;
spdadd 10.0.0.1/32 10.0.0.2/32 any -P in ipsec esp/tunnel/1.2.3.4-5.6.7.8/require;
Miroir miroir, c’est suykidikihé, on observe que la configuration est l’exacte symétrie de celle présente sur la machine hébergée à cette difference près que notre passerelle s’adresse à une IP publique, le dom0, de l’autre coté, s’occuppe de translater tout ce merdier en IP privée.
Ça va, vous suivez toujours ?
Il ne reste qu’une opération à mener pour que ces réseaux se voient: router effectivement ces divers réseaux entre eux; mais voila, pour l’instant les IPs endpoint du tunnel IPsec n’existent pas, et pour pallier à cela, nous allons une fois de plus abuser de l’ami loopback nous allons utiliser des alias sur les interfaces physiques (virtuelles dans le cas du domU) . Par exemple, sur notre domU:
# ifconfig xennet0 alias 10.0.0.1 netmask 255.255.255.255
Et sur notre passerelle:
# ifconfig sip0 alias 10.0.0.2 netmask 255.255.255.255
Reste à effectivement router ces “réseaux” entre eux, par exemple sur la passerelle:
# route add -host 10.0.0.1 10.0.0.2
Avant d’automatiser tout ce petit monde, vous pouvez d’ores et déjà réaliser quelques tests “live”. Chargez d’abord vos règles SPD des deux côtés:
# setkey -f /etc/ipsec.conf
Puis démarrez racoon en mode debug + verbose, sans passer en tâche de fond:
# racoon -F -d -v -f /etc/racoon/racoon.conf
Une fois satisfaits, nous allons pouvoir automatiser ces opérations afin qu’elles soient prises en compte à chaque boot. Non, nous n’allons pas écrire un script à la con.
Tout d’abord, nous préparons nos interfaces d’alias à l’aide du fichier /etc/ifaliases, sur notre machine hebergée par exemple:
# cat /etc/ifaliases
10.0.0.1 xennet0 255.255.255.255
Puis nous mettons en place les routes statiques:
# cat /etc/route.conf
host 10.0.0.2 10.0.0.1
Enfin, nous indiquons à rc qu’il devra charger la base SPD et démarrer racoon à l’aide du fichier /etc/rc.conf:
ipsec=YES
racoon=YES
Et nous y voila, une connectique sûre, standard et bidirectionelle en un tournemain.
En terme de latence, ça donne ça:
Sans IPsec
64 bytes from 1.2.3.4: icmp_seq=0 ttl=52 time=21.770 ms
Avec IPsec
64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=21.869 ms
Tranquille hein.
Je vous livre en sus les quelques liens qui nous ont aidé à peaufiner notre configuration:
- http://www.kame.net/newsletter/20001119/
- http://www.netbsd.org/docs/network/ipsec/
- http://www.netbsd.org/docs/network/ipsec/rasvpn.html
- http://wtf.hijacked.us/wiki/index.php/IPSEC-Racoon
- http://www.mad-hacking.net/documentation/linux/networking/ipsec/nat-vpn.xml
- http://www.lacave.net/~fred/racoon/config.html
Et vous souhaite une bonne nuit.
Recent Comments