Y'a plus simple mais c'est moins rigolo (updated)

by Emile `iMil' Heitor - 2011-07-29

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:

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:

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:

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:

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:

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:

Et sur notre passerelle:

Reste à effectivement router ces “réseaux” entre eux, par exemple sur la passerelle:

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:

Puis démarrez racoon en mode debug + verbose, sans passer en tâche de fond:

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:

Puis nous mettons en place les routes statiques:

Enfin, nous indiquons à rc qu’il devra charger la base SPD et démarrer racoon à l’aide du fichier /etc/rc.conf:

Et nous y voila, une connectique sûre, standard et bidirectionelle en un tournemain.

En terme de latence, ça donne ça: Sans IPsec

Avec IPsec

Tranquille hein.

Je vous livre en sus les quelques liens qui nous ont aidé à peaufiner notre configuration: