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 :
# The tunnel interface to IPREDator
auto ppp0
iface ppp0 inet ppp
provider ipredator
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 :
sudo route add default dev ppp0
Enlevez la route par défaut vers l’interface eth0 (je suppose que c’est votre interface avec la route par défaut) :
sudo route del default dev eth0
É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 :
sudo route add default gw 192.168.0.254 dev eth0
Enlevez la route par défaut vers l’interface ppp0 :
sudo route del default dev 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 :
ping -I 93.182.148.103 www.google.com
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 :
echo 1 IPRED >> /etc/iproute2/rt_tables
Ajoutez à la table de routage IPRED une route par défaut utilisant l’interface ppp0 ;
sudo ip route add default dev ppp0 table IPRED
A ce stade, affichez la table de routage pour vérifier que la route par défaut a bien été rajouté :
sudo ip route show table IPRED
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) :
sudo ip rule add from $IP/32 table IPRED
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 :
# The secondary loopback network interface
auto lo:1
iface lo:1 inet static
address 192.168.0.1
netmask 255.255.255.255
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) :
# Source NAT and destination NAT rules to make sure the incoming and ougoing packets on 192.168.0.1 are correctly NATed
iptables -A PREROUTING -t nat -i ppp0 -p tcp --dport 6891:6899 -j DNAT --to 192.168.0.1
iptables -A PREROUTING -t nat -i ppp0 -p udp --dport 6890 -j DNAT --to 192.168.0.1
iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE
# Allow session continuation traffic
iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
# Allow Bittorrent traffic via ppp0
iptables -A INPUT -i ppp0 -p tcp --dport 6891:6899 -j ACCEPT # rTorrent random range
iptables -A INPUT -i ppp0 -p udp --dport 6890 -j ACCEPT # DHT
# Disallow BitTorrent traffic via eth0 - Just to be extra safe ;)
iptables -A FORWARD -s 192.168.0.1/32 -o eth0 -j DROP
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
#! /bin/sh
# This script enables policy routing after the tunnel interface is brought up
# Policy routing is used to make sure response packets go through the tunnel interface
# This is mandatory when your ISP has setup anti-spoofing filters
# Add a default route via ppp0 into the IPRED routing table
ip route add default dev ppp0 table IPRED
# Pass traffic from lo:1 (192.168.0.1) to the IPRED routing table, using policy routing ("ip rule" commands)
ip rule add from 192.168.0.1/32 table IPRED
# Pass traffic from ppp0 IP address to the IPRED routing table
ip rule add from $4/32 table IPRED
et mon script /etc/ppp/ip-down.d/ipred-down
#! /bin/sh
# This script disables policy routing before the tunnel interface is brought down
# Remove rule for the secondary loopback IP address (192.168.0.1)
ip rule del from 192.168.0.1/32 table IPRED
# Remove rule for ppp0 IP address
ip rule del from $4/32 table IPRED
# Remove the default route via ppp0 from the IPRED routing table
ip route del default dev ppp0 table IPRED
N’oubliez pas de rendre les scripts exécutables :
sudo chmod +x /etc/ppp/ip-up.d/ipred-up
sudo chmod +x /etc/ppp/ip-down.d/ipred-down
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 :-)
Commentaires
Commentaire par freerage
Bonjour Hervé,
Merci pour ce how to très intéressant. J’ai choisi pour ma part d’utiliser cette méthode pour un proxy pour que n’importe quel client puisse configurer le proxy pour sortir via le vpn.
J’ai installé Squid. Cependant, je ne trouve pas de commande de type bind ou interface qui me permettre de dire à SQUID de ne sortir que par telle interface ou adresse. As-tu une idée ?
Merci de ton aide.
Commentaire par 131
Merci beaucoup pour ces quelques lignes qui m’ont été fort precieuses.
J’ai juste une question, je suis des torrents trackés/demonoid sur des vitesses de 100/200k, c’est lent, quand avant de monter mon vpn j’etais plutot abonné à des 1.2M. Constatez vous le meme ratio en ralentissement ?
Commentaire par Hervé LE ROY
@131: Je n’ai pas constaté de ralentissements lorsque j’ai testé pour la première fois (en juillet dernier). Il est possible que cela ait ralenti depuis (serait ce lié à la fin de la période de béta-test et à de l’affluence sur Ipredator ?). Comme je n’utilise plus mon client BitTorrent sans Ipredator depuis de nombreux mois, je ne suis pas en mesure de dire s’il y a un ralentissement significatif récemment.
@freerage: Je n’ai jamais configuré Squid, donc c’est difficile de t’aider. Il doit certainement être possible de spécifier l’IP ou l’interface que Squid utilise pour « sortir ». Essaye d’abord de configurer Squid (sans utiliser Ipredator), puis de configurer Ipredator (en utilisant une deuxième interface de loopback en 192.168.0.1 comme expliqué dans ce tutoriel), vérifier qu’Ipredator fonctionne bien au travers de cette loopback (ping -I 192.168.0.1 http://www.google.com) et enfin de configurer Squid pour utiliser cette loopback.
Commentaire par free.rage
Salut Hervé,
Justement c’est ce que j’ai fait mais je n’arrive bizarrement pas à sortir via mon adresse de loopback. J’ai même posté une question sur debian forums http://forums.debian.net/viewtopic…. car je n’arrive pas à comprendre pourquoi… Bien que ma configuration soit proche de la tienne.
free.rage
Commentaire par Sxilderik
Bonjour
Sur ma Debian Wheezy, iptables -A SERVICES me donne » No chain/target/match by that name. »
Je suppose que la chaine SERVICES n’est pas installée… mais comment faire ?
Merci