Il est toujours intéressant de pouvoir choisir une interface de sortie lorsque qu’on dispose de plusieurs accès internet. Nous allons voir dans un premier temps comment mettre en place l’infrastructure avec un serveur (routeur) GNU/Linux et ensuite s’intéresser de plus près à la QoS et plus particulièrement à DSCP.
Tout d’abord l’environnement dont nous disposons est donc conipstitué d’un serveur sous Debian 6, d’un accès Internet fibre optique, un accès ADSL, plusieurs accès VPN.
La configuration du serveur en mode routeur tout d’abord, comme vous le savez surement le noyau Linux est capable de réaliser une myriade d’opérations de routage et de manipulation de paquets.
echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -j MASQUERADE
Nous allons cependant devoir faire quelques réglages. Il faut déjà bien comprendre que pour réaliser cette opération nous allons avoir besoin de plusieurs tables de routage, car qui dit interface de sortie sur Internet dit route par défaut. Une table de routage indique l’adresse du prochain routeur à joindre pour acheminer le paquet vers sa destination. La route par défaut d’une table de routage s’applique pour tout les paquets dont la destination finale est inconnue du routeur. C’est typiquement le cas du trafic à destination d’Internet. Nous ne pouvons avoir qu’une seule route par défaut par table de routage, il nous faut donc une table de routage par interface. On va déclarer ces dernières dans le fichier /etc/iproute2/rt_tables.
255 local 254 main 253 default 103 VPNJP 102 VPNUS 101 VPNFR 100 ADSL 0 unspec
Comme on peut le voir Linux utilise déjà 3 tables de routage, main est la table principale, les autres ne sont pas à modifier. Pour voir le contenu d’une table de routage on utilise la commande ip.
ip route show table main 10.100.100.0/30 dev tap0 ... link src 10.100.100.2 10.101.101.0/30 dev tap1 ... link src 10.101.101.2 10.102.102.0/30 dev tap2 ... link src 10.102.102.2 192.168.42.0/24 dev eth0 ... link src 192.168.42.1 192.168.26.0/24 dev eth1 ... link src 192.168.26.1 default via 192.168.42.254 dev eth0
Par défaut si on omet le terme table c’est la table main qui sera manipulée. 192.168.42.254 est l’ip de la box fibre optique, ça sera donc notre interface de sortie par défaut si le trafic ne match aucune règle. Il faut aussi noter que la commande ip route permet l’abréviation aussi la commande précédente peut s’écrire « ip r s t main ». On va maintenant remplir les autres tables de routage. même si il n’y a que la route par défaut qui nous intéresse il est toujours préférable de la remplir complètement pour éviter les mauvaises surprises et permettre au routage du réseau local de fonctionner correctement sur toutes les interfaces.
ip route add table ADSL 10.100.100.0/30 dev tap0 ip route add table ADSL 10.101.101.0/30 dev tap1 ip route add table ADSL 10.102.102.0/30 dev tap2 ip route add table ADSL 192.168.42.0/30 dev eth0 ip route add table ADSL 192.168.26.0/30 dev eth1 default via 192.168.26.254 dev eth1
ip route add table VPNFR 10.100.100.0/30 dev tap0 ip route add table VPNFR 10.101.101.0/30 dev tap1 ip route add table VPNFR 10.102.102.0/30 dev tap2 ip route add table VPNFR 192.168.42.0/30 dev eth0 ip route add table VPNFR 192.168.26.0/30 dev eth1 default via 10.100.100.1 dev tap0
Bien, maintenant il suffit d’ajouter des règles de routage pour choisir la table que l’on veut utiliser. Par exemple on peut rediriger automatiquement tous les paquets provenant de l’ip 192.168.42.42 via la sortie ADSL comme ceci :
ip rule add from 192.168.42.42/32 lookup ADSL
Cependant je veux plus de granularité, j’aimerais pouvoir choisir l’interface de sortie directement sur mon poste client sous Windows 7 / MacOS / Linux. Il est possible d’utiliser le champ IPv4 Type de service (TOS) pour marquer le paquet à travers le réseau ainsi influer sur la décision de routage. Pour remplir ce champ plusieurs possibilité existent, nous allons utiliser DSCP car c’est celle qui est implémentée sous Windows. Sur le serveur nous allons utiliser ces marques pour choisir une table de routage. Malheureusement iproute2 ne gère pas directement DSCP, ce n’est pas grave nous allons utiliser netfilter/iptables qui lui sais reconnaître et manipuler ce champ. Nous allons ainsi marquer le paquet dans le suivi de connexion de netfilter car iproute2 sait parfaitement matcher des paquet en fonction de ces marques. C’est juste un artifice, rien n’est modifié au niveau du paquet qui conservera sa marque DSCP. Sans vouloir faire un cours sur netfilter/iptables je remet ce schéma sous vos yeux. Nous allons utiliser la table mangle pour modifier les paquets directement en entrée ou en sortie du système.
iptables -t mangle -A PREROUTING -m dscp --dscp 10 -j MARK --set-mark 10 iptables -t mangle -A PREROUTING -m dscp --dscp 11 -j MARK --set-mark 11 iptables -t mangle -A PREROUTING -m dscp --dscp 12 -j MARK --set-mark 12 iptables -t mangle -A PREROUTING -m dscp --dscp 13 -j MARK --set-mark 13
Ainsi nous pouvons maintenant nous baser sur cette marque pour créer nos règles de routage.
ip rule add fwmark 10 lookup ADSL ip rule add fwmark 11 lookup VPNFR ip rule add fwmark 12 lookup VPNUS ip rule add fwmark 13 lookup VPNJP
Tout est prêt 
. Il ne nous reste plus qu’à utiliser DSCP pour marquer les paquets directement sur les postes clients et qu’il prennent ainsi la route que l’on à choisi.
Sous Linux rien de plus simple on utilise iptables, ainsi il est possible de tagger le champ TOS des paquet avec la précision que l’on connais déjà. Généralement le module owner est d’une grande aide ici puisqu’il permet de matcher les paquet en fonction de l’application, du processus, du user ou du groupe,…
iptables -t mangle -A OUTPUT -p tcp --dport 22 -j DSCP --set-dscp 10 iptables -t mangle -A OUTPUT -p tcp --dport 80 -j DSCP --set-dscp 11
Ainsi le trafic SSH à destination du port 22 passera maintenant par l’ADSL OVH qui est plus stable et le traffic web non chiffré à travers le VPNFR pour plus de confidentialité. A vous d’adapter à vos besoins.
Sous Windows rien de bien plus compliqué surtout si vous disposez d’un domaine ActiveDirectory. Si ce n’est pas le cas rendez vous dans la base de registre avec l’outil regedit.exe et créez la clef suivante.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\QoS
A l’intérieur ajoutez une chaîne de type REG_SZ nommée « Do not use NLA » et comme valeur 1. Ceci permet d’appliquer la QoS sur une connexion réseau qui n’est pas associée à un domaine ActiveDirectory.
Maintenant rendez-vous dans la GPMC via l’outil « Modifier la stratégie de groupe locale » et ajoutez vos règles dans « Paramètres Windows / QoS basée sur la stratégie ». La première fois il vous faudra peut-être exécuter la commande gpupdate et redémarrer pour que les modifications soient prisent en compte.
Voila, vous savez tout et vous et vos utilisateurs êtes maintenant capables de demander poliment une route à votre routeur Linux. Bien entendu il vous est possible d’outre passer leurs choix en utilisant la table mangle, ainsi si un lien venait à tomber, une petite règle iptables et tout le trafic à destination de l’ADSL passera par la fibre ou inversement. L’autre intérêt est que les marque DSCP sont conservées lors du routage, certes pas lors du passage par le FAI et les réseaux ATM ou autres non compatibles avec IP, mais à travers un lien OpenVPN aucun problème, vous pouvez ainsi vous servir de cette marque pour influer sur la décision de routage directement au niveau du point de sortie du VPN.
— avec un utilisateur wordpress disposant de tous les droits sur cette base.