Posons le décor : tu viens d’arriver dans un hôtel, tu t’installes confortablement afin de profiter de la connexion internet offerte gratuitement et de pouvoir téléphoner à ta tante Gertrude gratuitement grâce à ton compte SIP, et là ! Misère de misère, les ports SIP sont  bloqués, logique, l’hôtelier préfère faire payer les communications avec une légère surtaxe ! [IRONIE ON] Oui oui, cet exemple est sorti de mon imagination, non non, ça ne m’est jamais arrivé… [IRONIE OFF]

Le problème est le même si tu désires jouer à un jeu dont les ports sont bloqués.

Ce qu’on va donc réaliser, c’est un VPN entre son ordinateur, appelons le A, et son serveur personnel S situé chez soi ou encore chez un hébergeur, S doit bien entendu être affranchi de toute limitation au niveau des ports. S doit également posséder un serveur SSH accessible depuis un port débloqué à l’hôtel. Généralement le port 22 par défaut est débloqué, cela ne devrait donc pas poser de problème.

Pour rappel un VPN (Virtual Private Network) permet de se connecter à un réseau distant et d’envoyer tout le trafic réseau par cette nouvelle connexion.

Mais quels sont les avantages de cette méthode par rapport à un VPN PPTP, L2TP ou OpenVPN ???

Pratiquement aucun, ce tunnel va juste être très rapide à configurer, seulement quelques lignes de commandes seront nécessaires, sécurisé grâce au tunnel SSH, et souvent les ports requis par PPTP ou L2TP sont bloqués.

Bon, un petit schémas pour résumer peut-être ?

VPN et tunnel SSH, schémas

C’est plus clair ? En fin de compte, tout le trafic transitera au travers d’un tunnel SSH, notre ordinateur sera donc connecté au réseau distant (192.168.0.0) comme s’il en faisait parti.

Bien maintenant, on sait où on va, mais on sait pas trop comment ! Pas de panique je ne te largue pas comme ça juste avec le principe ^^, la théorie est faite, place à la pratique.

Configuration du server SSH

Quelques petits prérequis afin que notre tunnel s’établisse correctement, nous allons devoir modifier un petit peu la configuration de notre serveur SSH :

Ce fichier est généralement situé ici : /etc/ssh/sshd_config
Vous devez vérifier que les réglages suivant soit paramétrés comme ceci :

X11Forwarding yes

PermitTunnel yes

PermitRootLogin yes

Ensuite il nous faut activer la redirection des paquets, désactivé par défaut sur la majorité des Linux.

sudo echo 1 > /proc/sys/net/ipv4/ip_forward

Puis finalement redemarrer le serveur SSH :

sudo /etc/init.d/sshd restart

Création du Tunnel SSH

Sur la machine cliente (Ordinateur A sur notre schémas), la commande permettant de creer le tunnel est celle-ci :

sudo ssh -NTfv -w 11:10 root@ip_du_serveur_S

Passons en revu les différentes options :

• N : empêche l’execution d’une commande
• T : n’alloue pas un terminal TTY à cette instance de connection SSH
• f : executé en arrière plan
• v : mode verbose, afin d’afficher les différents messages
• w : lie deux interfaces, nous allons avoir l’interface tun11 sur Ordinateur A et tun10 sur Serveur S. Les deux auraient pu être tun10 ou encore tun0, mais je voulais bien les différencier pour ne pas les confondre. De plus dans mon cas tun0 est déjà utilisé sur mon serveur pour un VPN.
• C : je ne l’ai pas mise, à essayer avec, cette option permet de compresser les données, du coup gain énorme de bande passante, mais perte de réactivité, pour des jeux à bannir, pour des page web à utiliser.

Désormais, si tout c’est bien passé, nous avons notre tunnel SSH entre notre serveur et notre pc, il ne nous reste plus qu’a configurer les interfaces TUN et rediriger tout le traffic vers ce tunnel pour faire un pseudo-vpn.

Configuration des interfaces TUN

Sur notre machine cliente Ordinateur A :

sudo ifconfig tun11 192.168.0.61 pointopoint 192.168.0.60

si Ordinateur A tourne sous osx :

sudo ifconfig tun11 192.168.0.61 192.168.0.60

et sur notre serveur distant S :

sudo ifconfig tun10 192.168.0.60 pointopoint 192.168.0.61

ou sous osx :

sudo ifconfig tun10 192.168.0.60 192.168.0.61

Ces deux commandes a exécuter permette de définir une adresse ip aux interfaces TUN et de les lier en mode point-à-point pour simplifier les choses à l’interface distante.

Pour tester la configuration, faites un ping vers 192.168.0.60 depuis l’ordinateur A :

ping 192.168.0.60

Si 192.168.0.60 répond, c’est que vous êtes correctement relié au réseau distant.

Faites de même avec 192.168.0.61 depuis le serveur S pour tester dans l’autre sens.

Redirection du trafic et création des routes

Depuis le serveur S, nous allons redirigé tout le traffic envoyé par l’ordinateur A au travers de l’interface eth0 relié au réseau local.

sudo arp -sD 192.168.0.61 eth0 pub

Désormais, tout est bouclé du côté serveur, vous pouvez fermer votre terminal distant.

Maintenant sur ordinateur A, nous allons configurer les routes.

Pour voir les routes déjà configurée :

netstat -nr

sur linux :

sudo route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.0.61 tun11
sudo route add ip_du_serveur_S gw 172.16.0.254 eth0
sudo route del default gw 172.16.0.254 eth0
sudo route add default gw 192.168.0.61 tun11

sur mac :

sudo route add -net 192.168.0/24 192.168.0.61
sudo route add ip_du_serveur_S 172.16.0.254
sudo route delete default 172.16.0.254
sudo route add default 192.168.0.61

And it’s done !!!

Un petit test dans un navigateur depuis Ordinateur A sur le site http://monip.org devra montrer l’IP internet du réseau du serveur S. Si ce n’est pas le cas, il faut retester les ping, puis si tout est bon, vérifier les routes, il y a surement une erreur de ce coté là.

Edit: Il se peut que vous n’arriviez pas à joindre des adresses Web, si c’est votre cas,un petit ping des dns google :

ping 8.8.8.8

Si le ping passe, alors c’est que vos DNS ne sont pas correct, allez dans vos préférences réseau et changez les par :

8.8.8.8
4.4.4.4

(Ce sont les serveurs DNS de google).

Et normalement tout devrais fonctionner.

Si le ping 8.8.8.8 ne passe pas, vous devez surement avoir un problème dans votre configuration des routes, vérifiez là.