I herd you liek tunnels... (updated)

so i put a tunnel in your tunnel so you can route while you route. Une fois n’est pas coutume, Xzibit résume assez bien la situation.

Mais revenons quelques heures en arrière.

Alors que nos tunnels IPsec fonctionnent sans broncher depuis nos dernières experiences, l’un des objectifs finaux de l’opération montrait le boût de son nez: router des réseaux à travers nos fâmeuses liaisons IPsec. Et “ça marche pas”(tm). Plus précisemment, il apparaît impossible de joindre d’autres réseaux que ceux liés par IPsec, ou plus particulièrement la SPD, et en y reflechissant à deux fois, ceci est parfaitement normal. La solution ? Un tunnel par dessus le tunnel !

Fort heureusement, nos UNIX modernes bénéficient de systèmes de tunneling peu coûteux en overhead, et parmi eux, gre(4). Pourquoi gre(4) et non gif(4) ? honteuse réponse: IPsec + domU + gif == kernel panic. Si.

En réalité, la mise en place d’un tel mécanisme est beaucoup plus simple qu’il n’y parait, nous allons simplement utiliser la liaison déjà établie par IPsec, 10.0.0.1 vers 10.0.0.2 selon l’exemple du billet précédent, pour établir un tunnel qui ne sera pas soumis à la base stricte d’IPsec et nous permettra de router ce que bon nous semble d’un bout du tunnel à l’autre.

Cela est à nouveau pris en charge très natuellement par NetBSD; il suffit, pour mettre en place cette nouvelle interconnexion, de créer un fichier /etc/ifconfig.gre0 de la forme suivante:

pour que s’établisse, sur notre interconnexion IPsec (10.0.0.1 - 10.0.0.2), une nouvelle liaison (10.0.1.1 - 10.0.1.2) libre d’être utilisée comme pivot de routage.

Attention ! Afin que ce petit monde fonctionne sans soucis à chaque démarrage, il ne faudra pas utiliser /etc/ifaliases comme je l’annonçais dans le précédent billet, mais compléter le fichier /etc/ifconfig.iface de cette façon:

car autrement, les alias seront montés après les tunnels gre(4), ifaliases étant manifestement appelé à la suite de ifconfig.if.

More to come…