Là, vous avez deux solutions : payer (ce qui peut vite devenir cher si vous passer plus d’une semaine à l’hôtel) ou contourner les limitations. Vous vous rendrez vite compte que, même avant d’avoir payé, tous les hotspots résolvent les DNS… et il ne vous aura pas échappé qu’une résolution de DNS est un échange de données!

Le port UDP 53

Pour faciliter la configuration de ces hotspots, de nombreux administrateurs n’hésitent pas à tout simplement ouvrir le port DNS, c’est-à-dire le port UDP 53. Une solution simple pour accéder à internet serait donc d’avoir un serveur VPN sur ce port.

Malheureusement on tombe souvent sur des hotspots bien configurés, qui n’autorisent du trafic que vers leur propre serveur DNS. Pourtant, vous avez remarqué qu’un dig geekfault.org vous a retourné la bonne adresse IP (81.93.247.142 actuellement) et non une adresse IP du hotspot. Vous venez de communiquer avec l’internet!

Échange de données over DNS

L’idée est donc simple : traduire vos “requêtes IP” en requêtes DNS. Un faux serveur DNS va comprendre ces requêtes, les exécuter et retourner la “réponse IP” en réponse DNS! Ce détournement du système DNS est réalisable grâce à NSTX, ou Name Service Transfer Procotol qui crée un véritable tunnel IP entre votre laptop et votre serveur, grâce aux requêtes DNS.

Par exemple vous essayez de vous connecter à Geekfault.

• Firefox génère une requête HTTP vers geekfault.org
• Celle-ci est interceptée par le client NSTX tournant sur le laptop. Il génère une requête vers le domaine KJhjh33.dd_2sT-XXT.dAAoi_f.tunnel.example.com
• Le NSTX tournant sur le serveur reçoit cette requête DNS et décode le KJhjh33.dd_2sT-XXT.dAAoi_f en “requête HTTP vers geekfault.org”
• Le serveur se connecte alors à geekfault.org et récupère son contenu
• Le contenu récupéré est encodé de la même manière et transmis vers votre laptop en tant que réponse DNS TXT
• Le NSTX tournant sur le laptop décode les données, reformant les paquets IP
• Firefox reçoit les données HTTP, Geekfault.org s’affiche

Mise en place du serveur

Attention il est important que votre vrai serveur DNS et votre serveur NSTX soient sur deux machines différentes, ou au moins sur deux IP différentes. En effet, il faut qu’un vrai serveur DNS fasse pointer le sous-domaine tunnel.example.com vers NSTX. Pour cela, ajoutez à la fin de votre zone DNS $ORIGIN tunnel.example.com.
@ IN NS ns.tunnel.example.com.
ns IN A 1.2.3.4 où example.com est votre domaine et 1.2.3.4 est l’IP du serveur où vous installerez NSTX.

Vérifiez que votre kernel est compilé avec le “Universal TUN/TAP device driver support” (dans Network device support) . Installez NSTX, disponible en package pour de nombreuses distributions.

Et il ne reste plus qu’à créer le tunnel côté serveur: # modprobe tun #Uniquement si compilé en module
# nstxd -i 1.2.3.4 tunnel.example.com
# ifconfig tun0 up 172.16.42.1 netmask 255.255.255.0
# iptables -t nat -A POSTROUTING -s 172.16.42.2 -o eth0 -j SNAT

Le client sur le laptop

De la même manière, vérifiez que vous avez le support TUN/TAP dans le kernel et installez NSTX.

Récupérez l’adresse IP du serveur DNS fourni par DHCP (dans /etc/resolv.conf) ainsi que l’adresse IP du routeur (dans route). On crée alors l’autre bout du tunnel et on route le trafic approprié dans celui-ci: # modprobe tun #Uniquement si compilé en module
# nstxcd tunnel.example.com
# ifconfig tun0 up 172.16.42.2 netmask 255.255.255.0
# route del default
# route add -host gw dev
# route add default gw 172.16.42.1 tun0

Performances

Vous devriez maintenant être capable de surfer sur le web. Selon le serveur DNS du fournisseur, vous pouvez espérer entre 10 et 60ko/s. Malheureusement les fortes latences de toutes les requêtes empêchent l’utilisation de plusieurs services, dont le SSH. Mais, hé, vous accédez à internet sans vous défaire de 10€

Vous aurez aussi sans doute compris que nous sommes là au bord de la légalité : on exploite en quelque sorte une faille dans le système de hotspot. À utiliser avec précaution et parcimonie.

Si vous avez aimé ce post...

1. Le tunnel SSH facile
2. Allocation d’adresses IPv4 publiques over VPN
3. Reverse SSH : accéder à un serveur derrière un NAT/Firewall