IntroductionRégulièrement, certains d'entre nous s'interrogent : est-il possible d'utiliser son p2p favori au travail, dans sa résidence universitaire ou chez ses parents, en tout cas quelque part où l'on n'a pas le contrôle sur le routeur/pare-feu.
La réponse qui est en général faite est "c'est compliqué et pas très intéressant", sans plus de détail. Cela dit, pour l'édification de tous, je vais ici présenter ce qui est, à mon avis, la meilleure méthode pour y parvenir. C'est assez long, donc je vais poster en plusieurs fois, soyez patients
Avertissements1 - Où que vous soyez, vérifiez que l'utilisation du p2p n'est pas interdite.
2 - Tout particulièrement si vous êtes au travail ou dans un cadre universitaire, ne téléchargez pas de contenu protégé par des lois sur le droit d'auteur. Si vous le faites, vous risquez non seulement les peines prévues par la loi, mais aussi de vous faire virer... Ne rigolez pas, il existe des utilisations légales du p2p : la version Windaube de mon économisateur d'écran préféré (
http://www.electricsheep.org ) diffuse ses économisateurs d'écran via BT, par exemple
3 - C'est possible. Ça ne veut pas dire que c'est intéressant. Voir ci-après le matériel requis et la présentation théorique de la méthode : vous allez gâcher beaucoup de bande passante
Matériel requisPour pouvoir faire du p2p derrière ce qu'il est convenu d'appeler un "parefeu fasciste", il vous faut :
1 - chercher à télécharger des données via du p2p derrière un parefeu n'autorisant que certaines connexions précises (sinon, c'est pas drôle).
2 - Un ordinateur derrière ce parefeu sur lequel vous avez le droit d'installer des programmes (Si vous n'avez pas ce droit et que vous êtes sous Window$, il y a plein de façon de l'obtenir, cherchez un peu. Si vous êtes sous *nix, c'est un peu plus compliqué, mais pas impossible, du moment que vous avez un accès physique à la machine. Le plus simple, dans ce dernier cas, c'est d'installer dans ~/bin et de modifier $PATH dans son .bashrc ou .cshrc, suivant les cas. Sinon, il y a toujours la possibilité de trifouiller /etc/sudoers, mais ça, c'est pas bien).
3 - C'est là que ça se complique : un ordinateur
à l'extérieur de ce parefeu, connecté à internet soit directement (ce qui n'est pas bien) soit derrière un parefeu dont vous avez le contrôle.
Un peu de théorieUn parefeu fasciste est un parefeu qui contrôle non seulement les connexions entrantes mais aussi les connexions sortantes, n'en autorisant que certaines, à savoir au moins vers les ports 80 et 443 (http et https), parfois aussi vers les ports 21 (ftp), 25 (smtp) et 110 (pop), voire 22 (ssh). Un tel parefeu ne fait que procurer une sécurité totalement illusoire aux sysadmins (Messieurs administrateurs réseaux qui me liraient éventuellement : il y a longtemps que même les pire hackers ont compris les principes que je vais exposer ici. Si vous voulez vraiment contrôler votre réseau, la bonne solution, à mon sens, est de bloquer toutes les communications vers l'extérieur et d'avoir un serveur en DMZ qui serve non seulement de relais pour votre messagerie et autres services utilisés par vos utilisateurs, mais également où soit installés leurs navigateurs, qu'ils font tourner en remote. Passons...).
La solution à utiliser est simple en théorie, mais je m'y suis pourtant longtemps cassé les dents : pour utiliser n'importe quel service, on utilise une machine extérieure relais, vers laquelle on ouvre un tunnel http, on encrypte les données transférées, et c'est parti.
Pour ouvrir le tunnel, il y a plein de petits programmes, proxytunnel, http_tunnel, corkscrew, etc. Pour transmettre des données de façon cryptée, le meilleur programme sur le marché est OpenSSH (ssh pour secure shell), qui permet, notamment, de transmettre les données arrivant sur un port donné de la machine relais vers un port donné de la machine interne et vice-versa.
Donc, pendant longtemps, j'ai cru que la solution était là, et elle marche en effet pour pratiquement tous les services internet, d'http à irc en passant par pop, smtp et les autres : faire suivre un port externe, sur la machine relais, vers la machine bloquée et, en retour, faire suivre un port sur la machine interne vers la machine relais.
Le problème est que cela ne marche ni avec FTP, ni avec les programmes de p2p qui tous (à l'exception, semble-t-il, de utorrent) utilisent des ports aléatoires pour les connexions sortantes.
La solution est donc ailleurs : au lieu de faire suivre les connexions sortantes port par port, il faut que toutes les connexions sortantes aillent vers la machine relais, autrement dit trouver le moyen de mettre ces deux machines sur un pseudo réseau local.
Et c'est tout à fait possible : ça s'appelle un réseau privé virtuel (virtual private network, ou VPN), et il y a un excellent couple client/serveur libre, openvpn (
http://www.openvpn.org ) que nous allons donc utiliser pour parvenir à nos fins.
Vous aurez cependant immédiatement compris les deux bémols à apporter à la merveilleuse méthode que je vais vous développer dans les jours suivants :
1 - Si on a le contrôle d'une machine extérieure, pourquoi s'obstiner à faire du p2p sur sa machine interne ? A part le cas d'electricsheep que j'ai évoqué plus tôt, je pense personnellement que ça n'a strictement aucun intérêt, surtout que
2 - La machine relais va devoir utiliser sa bande passante pour recevoir les données et vous les faire parvenir, mais également pour renvoyer les données que vous lui enverrez, ce qui veut dire, en gros, que vous ne pouvez, au mieux, qu'espérer un débit de téléchargement égal à la moitié de votre bande passante montante. Autrement dit, si votre machine est seule sur une connexion ADSL2 optimale (20 Mb/s en descente, 1Mb/s en montant) vous aurez des performances équivalentes à du 512 kb/s, et encore, si votre machine interne a accès à 512kb/s de bande passante montante et descendante). Dans la pratique, il faut compter sur l'équivalent d'une connexion simétrique 128/128.
I - Mettre en place un VPN : le serveurPour les anglophones, il y a un très bon HOWTO là :
http://openvpn.net/howto.htmlNous allons mettre en place un vpn dynamique routé. Première étape : installez OpenVPN 2 sur l'ordinateur externe, soit via votre gestionnaire de paquet, soit en téléchargeant la source ou l'exécutable Windows là :
http://openvpn.net/download.html1 - Choisir une plage d'adresse pour votre VPN.Comme tout réseau local, votre VPN va devoir avoir une plage d'adresse. Vous pouvez choisir dans 10/8, 172.16/12 et 192.168/16 (les trois plages réservées pour les réseaux privés). D'expérience, c'est dans 10/8 qu'il y a le moins de chances de confilits avec d'autres réseaux, notamment si l'un des ordinateurs de votre VPN est un portable qui risque d'être utilisé dans des hôtels. On va prendre, par exemple, 10.8.5/24 (10.8.5.1 à 10.8.5.254), mais vous êtes libres du choix de votre plage, évidemment.
2 - Générer les clefsLa première étape va être de générer les clefs utilisées pour l'authentification, soit une paire de clefs publique/privée pour le serveur et chaque client, et un certificat d'autorité pour le serveur, qui signera chacune des clefs.
Si vous êtes sous Windows, ouvrez une fenêtre d'invite de commande et faites
Code:
cd \Program Files\OpenVPN\easy-rsa
init-config
Sous *nix,
Code:
cp /usr/share/doc/openvpn/easy-rsa/2.0 /etc/openvpn
cd /etc/openvpn
Maintenant, il faut éditer le fichier vars (ou vars.bat sous Windows) et renseigner les champs importants, soit
KEY_COUNTRY (votre pays), KEY_PROVINCE (votre région), KEY_CITY (votre ville), KEY_ORG (normalement, le nom de la boîte, mettez ce que vous voulez) et KEY_EMAIL (votre email. Ce sont des données qui sont faites pour le certificat, pas pour être transmises à l'extérieur, donc pas d'inquiétude sur la vie privée). Personnellement, je change aussi KEY-SIZE en 2048 au lieu de 1024...
Prêts ? Alors on va générer les clefs. On commence par sourcer var et tout nettoyer
Code:
Sous Windows
vars
clean-all
Sous Linux
. ./vars
./clean-all
Puis on génère le certificat d'autorité
Code:
build-ca
ou
./build-ca
Toutes les réponses par défaut devraient être bonnes, sauf une, le "Common name". Entrez là le nom que vous voulez donner à votre serveur et retenez le.
Bien, maintenant, générons la paire de clefs du serveurs et des clients. C'est tout simple
Code:
build-key [Nom du serveur]
build-key [Nom du client]
ou
./build-key [Nom du serveur]
./build-key [Nom du client]
Reste à génèrer les paramètres pour le protocole Diffie-Hellman (
http://fr.wikipedia.org/wiki/Échange_de_clés_Diffie-Hellman )
Code:
build-dh
ou ./build-dh
Ensuite, installez openvpn sur les machines du futur réseau privé, mais ne générez pas de certificats. Sous Linux, en plus, il faut faire
Code:
mkdir /etc/openvpn
3 - Répartir les clefsPlusieurs fichiers ont été générés. Voici comment les répartir :
ca.crt doit être dans le /etc/openvpn (ou le \Program Files\OpenVPN) du serveur et de tous les clients. Le serveur garde le fichier dh{n}.pem et les fichiers [Nom du serveur].crt et [Nom du serveur].key. Chacun des clients prend les fichiers [Nom du client].crt et [Nom du client].key.
4 - Configurer le serveurÉditez le fichier de configuration par défaut du serveur.
Changez le port de 1194 en 443
changez
;proto tcp
proto udp
en
proto tcp
;proto udp
pointez ca, cert, key et dh vers les fichiers respectifs du serveur.
pour server, mettez (dans l'exemple choisi, pour 10.8.5/24) 10.8.5.0 255.255.255.0
décommentez la ligne push "redirect-gateway"
décommentez la lignes client-config-dir ccd
ensuite, créez un sous-dossier ccd. Dedans, mettez un fichier par client portant le nom [Nom du client] dans lequel vous mettez une seule ligne
Code:
ifconfig-push IPquevoussouhaitezdonnerauclient IPquevoussouhaitezdonnerauclient+1
.
Voilà, vous n'avez plus qu'à taper
Code:
openvpn [fichier de configuration]
et voir si tout démarre normalement. Si oui, créez la règle de NAT pour envoyer les paquets arrivant du VPN vers le reste du monde.
En supposant que la route par défaut soit sur l'interface eth0, les règles sont les suivantes
Code:
iptables
iptables -t nat -A POSTROUTING -s 10.8.5.0/255.255.255.0 -o eth0 -j MASQUERADE
pf
nat on eth0 from 10.8.5.0/24 to any -> eth0
Window$
Si quelqu'un connaît le bon réglage de NAT pour un serveur OpenVPN sous Window$, je suis preneur
routez les ports utilisez par vos logiciels de p2p vers l'adresse que vous avez assignée à votre ordinateur derrière le parefeu. Exemple ici pour BT sur le port 6881 redirigé vers 10.8.5.2
Code:
iptables
iptables -t nat -A PREROUTING -p tcp --dport 6881 -j DNAT --to-destination 10.8.5.2:6881
pf
rdr on eth0 proto tcp from any to any port 6881 -> 10.8.5.2
Pour Window$, voir
http://forum.p2pfr.com/ftopic15822.htmlRoutez le port 443 et le port 6881 (dans mon exemple) vers cet ordinateur et il est temps de passer au client
II - Mettre en place un VPN : le clientLà, c'est tout simple
Vous éditez le fichier de configuration client ( client.conf sur *nix, client.openvpn sur Windows) en pointant cert, key et ca au bon endroit, vous pointez remote sur votre machine distante (soit en utilisant son IP si vous avez une IP fixe, soit avec un dynDNS), vous réglez dev sur tun et proto sur tcp, et vous y êtes presque.
La seule chose à faire est d'ajouter une ligne http-proxy du type
http-proxy 192.168.0.1 8080
et c'est parti.
ConclusionVoilà, vous pouvez faire du p2p derrière un parefeu fasciste, mais à mon avis, ce n'est pas très productif. Il vaut mieux faire tourner le logiciel de p2p sur la machine relais et récupèrer via le VPN les fichiers une fois téléchargés.
Vous pouvez aller boire une aspirine à ma santé.