Emile "iMil" Heitor 's home

Avant de partir me dorer la pilule à la maison, je vous jette en pâture une toute nouvelle pre-release de pkgin, j’ai nommé 0.5.0.

Fruit des conseils avisés du sieur Bapt, fort de son experience avec son fâmeux pkgng, ainsi que des multiples feedbacks d’horizons très differents, le code de pkgin 0.5.0 est plus rapide, plus simple et embarque un certain nombre de features requests.

Dans l’ordre d’implémentation:

• Migration silencieuse d’une base 0.4 vers 0.5
• Fonction check_yesno() plus souple
• “Yes” par defaut pour pkgin install / remove / upgrade
• Une unique structure pour toutes les formes de listes de packages
• Nettoyage de dizaines de calculs de listes inutiles (perfs x10)
• Introduction du champs FULLPKGNAME, accélération des recherches
• unique_pkg(): plus de “many versions of foo available”, le plus récent est toujours choisi
• Import du progressmeter d’OpenSSH

Cette version restera en gestation dans wip le temps qu’elle soit correctement testée, les changements sont nombreux et profonds, je dois m’assurer que tout fonctionne comme il se doit.
Vous l’aurez compris, il faut tester, TESTER, TESTER !
Je vous invite à rapporter les problèmes potentiels sur la liste de developpement de pkgin, à pkgin-devel-at-lists-point-sourceforge-point-net.

Depuis que j’ai commencé la serie de billets qui parlent de tunnels, on me demande en substance “c’est chouette et tout mais… tu vas ou là ?”. Rappelez-vous, le premier billet de cette serie parlait de tunnels suédois, et bien évidemment, je ne suis pas le seul à désirer contrôler plus finement le chemin qu’empruntent les paquets IP qui sortent de mes machines. Aussi, avec quelques amis, avons nous décidé de mettre en place un réseau possiblement sécurisé, interconnecté, et hautement disponible. Ainsi, l’objectif est de pouvoir contacter nos réseaux à travers des liens cryptés, et de sortir sur le Net en utilisant differents tunnels, ces routes se construisant dynamiquement grâce au protocole BGP.
Hormis l’aspect purement pratique de la chose, le projet est passionnant et les techniques employées sont élégantes et interessantes. For teh lulz quoi.

Plus précisemment, considérons une machine, hébergée quelque part sur l’Internet. Cette machine fait office de routeur BGP à l’aide du logiciel Quagga. Ce routeur BGP est connecté à d’autres routeurs représentant autant de Systèmes Autonomes (AS), privés bien entendu, on parle ici d’EBGP (Exterior Border Gateway Protocol). À ce routeur, je connecte ma passerelle maison, qui fait partie de mon AS privé. C’est un lien IBGP (Interior Border Gateway Protocol).

Lorsqu’un noeud, que j’ai déclaré dans la configuration du routeur, se connecte à notre réseau, ce dernier annonce les routes qu’il souhaite. Par exemple un réseau d’échange ou encore une route par defaut. Un système de poids fera préférer tel ou tel chemin pour joindre un point du réseau.

Voici un exemple de configuration, très simple, de l’un des routeurs de bordure:

password trescomplique
enable password trestrescomplique
!
router bgp 65535
 bgp router-id 10.0.1.1
 network 192.168.10.0/24
 neighbor 10.0.1.2 remote-as 65535
 neighbor 10.0.2.1 remote-as 65536
!
ip forwarding

On établit ici une liaison IBGP vers 10.0.1.2 et EBGP vers 10.0.2.1, et on annonce sur ces réseaux comment joindre 192.168.10.0/24.

Comme vous vous en doutiez, ces routeurs sont tous reliés entre eux par une liaison point à point IPsec, routent leur traffic à travers des tunnels gre(4) sur les liaisons IPsec, et sortent tous par défaut sur Internet via la Suède.

Ce dernier point n’est pas anodin d’un point de vue routage; en effet, il est contre-productif qu’une partie du traffic, celui de l’infrastructure, emprunte la suède pour communiquer avec ses pairs. Pire, dans certains cas cela provoquera des cas de routage asymétrique. Aussi, il est indispensable de mettre en place des règles de gestion de routage… en amont de la table de routage ainsi que de la SPD d’IPsec. La solution ? PF bien sûr :)

Voici la configuration que j’utilise pour m’assurer que tout le traffic lié à l’infrastructure emprunte bien des chemins optimaux (explication dans la conf):

real_if="xennet0"
tun_if="tap0"
gateway="192.168.0.254"

openvpn="{ 1194 10010 10020 }"
direct_ports="{ 22 53 80 179 443 500 4500 }"
ipsec="{ 179 500 4500 }" # ipsec protocols + BGP

# comme vu dans un billet precedent, on s'assure de repondre via notre IP
# publique "reelle" lorsque l'on est interroges sur $direct_ports
pass in quick log on $real_if reply-to ($real_if $gateway) proto { tcp, udp } \
        from any to any port $direct_ports

# meme methode pour les protocoles utilises par IPsec
pass in quick log on $real_if reply-to ($real_if $gateway) proto { ah, esp } \
        from any to any

# on route les protocoles d'echange de cle (isakmp) sur l'interface
# reelle $real_if
pass out quick log route-to ($real_if $gateway) proto { tcp, udp } \
        from any to any port $ipsec
# on route tout le traffic AH/ESP via $real_if
pass out quick log route-to ($real_if $gateway) proto { ah, esp } \
        from any to any

# on bloque tout le traffic se dirigeant vers l'interface reelle $real_if
# sauf OpenVPN et les protocoles utilises par IPsec
block out log on $real_if
pass out on $real_if proto { tcp, udp } from any to any port $openvpn
pass out on $real_if proto { ah, esp } from any to any

Ces règles doivent être chargées après le chargement d’OpenVPN, on peut réaliser cette séquence très simplement à l’aide de la directive up du fichier de configuration du logiciel:

script-security 2
up /home/imil/bin/pf-up.sh

Le script en question est trivial:

#!/bin/sh

/sbin/pfctl -f /etc/pf.conf-ovpn

Moyennant quoi, à chaque démarrage d’OpenVPN, ces règles viendront s’assurer qu’aucun paquet hors contrôle ne transitera par l’IP publique “réelle” de notre serveur, tout le traffic non lié à l’infrastructure devant passer par le tunnel Suédois.

Le projet est toujours en cours de construction et il reste encore quelques boulons à serrer, mais ‘vous inquiétez pas, vous serez les permiers au courant des évolutions ;)

Un dernier mot, certains lecteurs m’envoient depuis quelque jours leur setup à debugger et m’expliquent en détail les problèmes qu’ils rencontrent, vous comprendrez aisemment que je ne peux humainement pas dépiler tout ça tout seul, mais n’oubliez pas que, modulo votre bienséance, vous êtes bienvenu sur le canal #gcu@freenode !

…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:

create
inet 10.0.1.1 10.0.1.2 netmask 255.255.255.255
tunnel 10.0.0.1 10.0.0.2 up

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:

up
inet 1.2.3.4 netmask 0xffffff00
inet 10.0.0.1 netmask 0xffffffff alias

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…