Optimisations IPREDATOR sur Dedibox / Free

Dans un précédent billet, j’ai expliqué comment configurer PPTP sous Linux pour utiliser le VPN IPREDATOR. Rentrons maintenant dans quelques optimisations complémentaires. Je suppose que vous avez un minimum de connaissances en réseau, sinon passez votre chemin.

I) Monter l’interface automatiquement lors du démarrage

Editez le fichier /etc/network/interfaces et rajoutez :

Le tunnel VPN sera lancé automatiquement au démarrage de votre serveur. Vous pouvez utiliser ifdown ppp0 pour fermer le tunnel et ifup ppp0 pour le démarrer.

II) Router le traffic au travers du VPN

Vous avez deux possibilités :

1. Router toutes les applications au travers du VPN

C’est la solution préférée si vous souhaitez un anonymat maximum (voir la note en fin de billet sur l’anonymat tout relatif qu’il est possible d’obtenir). Par contre, l’utilisation du VPN rajoute une certaine latence (RTD de 68 ms dans mon cas précis) qui peut être préjudiciable : surf plus lent, jeux en ligne fortement ralentis, etc…

Ajoutez la route par défaut vers l’interface ppp0 :

Enlevez la route par défaut vers l’interface eth0 (je suppose que c’est votre interface avec la route par défaut) :

Évidemment, si vous passez ces commandes sur une machine sur laquelle vous êtes connecté en SSH, vous allez perdre la main dessus. Alors, attention, vous êtes prévenu.

Pour faire marche arrière :

Remettons la route par défaut sur la Freebox (IP 192.168.0.254) sur l’interface eth0 :

Enlevez la route par défaut vers l’interface ppp0 :

2. N’utiliser le VPN que pour certaines applications

La seconde possibilité est à mes yeux la plus élégante. Vous n’utilisez le tunnel que pour certaines applications (BitTorrent, Emule, etc). En plus, c’est simple. Il suffit de configurer votre client pour qu’il utilise le VPN. Il faut chercher un paramètre du genre « interface » (indiquez ppp0) ou « bind » (indiquez l’IP attribuée par le VPN).

SAUF QUE, ça ne marche pas forcément avec tous les fournisseurs d’accès (ou d’hébergement). Un test rapide consiste à envoyer un ping en utilisant l’IP du VPN en adresse source :

Si ça ne marche pas, il y a de fortes chances que votre FAI ait mis en place des filtres anti-spoofing. C’est le cas de Free et Dedibox (deux entreprises filiales d’ILIAD et partageant le même réseau). Les filtres anti-spoofing bloquent l’émission d’un paquet dont l’adresse source n’appartient pas à leur range d’IP. Or, par défaut, les paquets sont émis via l’interface eth0 et non pas via l’interface tunnel ppp0. Il faut impérativement forcer le routage des paquets via le tunnel et, pour cela, il faut configurer du policy routing (merci MikO pour m’avoir expliqué tout cela :-). L’idée consiste à avoir une table de routage séparée qui va traiter les paquets selon certaines rêgles (ip rule dans la terminologie Linux).

Ajoutez une nouvelle table de routage appelée IPRED :

Ajoutez à la table de routage IPRED une route par défaut utilisant l’interface ppp0 ;

A ce stade, affichez la table de routage pour vérifier que la route par défaut a bien été rajouté :

Si vous voyez s’afficher default dev ppp0 scope link, tout va bien. Si non, il est probable que votre kernel ne supporte par le policy routing. C’était le cas de mon kernel Dedibox 🙁 Il vous faudra recompiler votre kernel avec CONFIG_IP_MULTIPLE_TABLES=y (vous trouverez des explications pas à pas sur la compilation d’un kernel pour votre Dedibox sur le forum de www.dedibox-news.com).

Enfin, ajoutez une rêgle pour router les paquets en utilisant la table IPRED lorsqu’ils ont pour IP source l’IP du VPN (remplacez $IP par l’IP de votre VPN) :

Voilà, c’est terminé. Refaites le test avec ping -I 93.182.148.103 www.google.com, ca doit marcher.

III) Contourner le problème de l’IP dynamique

A chaque fois que le VPN est relancé (au redémarrage du serveur ou après une coupure réseau), vous obtiendrez une nouvelle IP et vous devrez reconfigurer vos applications. Hmmm… fastidieux. Pour éviter cela, une des solutions consiste à créer une deuxième interface de loopback, puis à NATer tout le trafic de l’interface ppp0 vers et depuis cette adresse.

Editez le fichier /etc/network/interfaces et rajoutez :

J’ai utilisé 192.168.0.1 comme adresse de loopback. A vous de choisir une adresse privée RFC 1918 disponible.

Enfin, modifiez vos rêgles IPTABLES pour NATer le trafic. Dans le sens « download » ce sont les rêgles DNAT (destination NAT). Dans le sens « upload », c’est la rêgle de MASQUERADE (source NAT) :

Et voilà, vous pouvez configurer vos logiciels pour se « binder » sur l’adresse 192.168.0.1. Plus besoin de les reconfigurer lorsque l’IP du VPN change.

IV) Automatiser tout cela

Une fois que ça marche, il est facile d’automatiser l’ajout / enlèvement des rêgles avec des scripts à déposer dans les répertoires /etc/ppp/ip-up.d/ et /etc/ppp/ip-down.d/

Voilà mon script /etc/ppp/ip-up.d/ipred-up

et mon script /etc/ppp/ip-down.d/ipred-down

N’oubliez pas de rendre les scripts exécutables :

Mot de la fin : VPN & anonymat

Un VPN PPTP ne vous rend pas « anonyme ». Il vous permet d’utiliser une adresse IP qui n’est pas celle attribuée par votre FAI. C’est un certain degré d’anonymat, mais ce n’est pas la panacée. C’est amplement suffisant pour faire échec à une loi injuste comme HADOPI ou tromper des systèmes de géolocalisation basés sur l’adresse IP, mais probablement insuffisant pour des militants des droits de l’homme chinois ou iraniens qui choisiront plutôt un réseau comme TOR. Bon surf 🙂