Jouons à cache-cache

Aujourd’hui, en raison des diverses lois liberticides mises en oeuvre pour controler l’activité des usagers sur Internet dans notre beau pays de la plainte, je me suis abonné à un très bon service de VPN fourni par la société Suédoise VPNtunnel.

Le service est impeccable, la conf OpenVPN fonctionne out-of-the-box, et ainsi la route par defaut de ma machine client prend le chemin de la Suède. Nickel.

Mais vous me connaissez, j’aime bien me compliquer la vie.
Le service en question ne fournit pas d’IP fixe, et c’est bien normal au vu de l’objectif même de l’offre; seulement voila, la machine que j’ai raccordé à ce service n’est pas une bête workstation, mais plutot un serveur situé “quelque part”. Évidemment, je me connecte via ssh à cette machine, et il m’est fort désagréable de devoir retrouver son IP en permanence. Pas question de bidouiller un truc à base de dynamic DNS, on est pas des sauvages tout de même.

Le problème, je vous le donne en mille, c’est que lorsque je ssh vers l’IP publique habituelle de cette machine, le paquet de retour emprunte la route par défaut, le tunnel donc, et que le serveur en question, c’est une machine virtuelle, dont le port SSH est translaté par le dom0. Oui je sais ça commence à donner mal à la tête. En un mot comme en cent, la connexion SSH n’aboutit jamais, passant par un endroit et sortant par un autre.

La solution: PF le magnifique !

Je vous entretenais il y a quelques temps déjà de la fabuleuse directive route-to, mais cette dernière ne s’applique pas au cas présent. Fort heureusement, sa soeur jumelle, reply-to réalise exactement le travail voulu, et ce en 2 coups de cuiller à pot. Démonstration:

Sur mon dom0, une machine Debian/GNU Linux, je redirige le traffic du port 2323 sur le port 22 de ma machine virtuelle NetBSD de cette façon:


-A PREROUTING -i eth0 -p tcp -m tcp –dport 2323 -j DNAT –to-destination 192.168.0.8:22
-A POSTROUTING -s 192.168.0.8/32 -j MASQUERADE # ici, on NAT la sortie de sorte que le domU puisse répondre au client

Mais lorsque le domU souhaite répondre à l’IP qui le sollicite sur le port 22, il emprunte sa route par défaut, et nous nous retrouvons dans un bon vieux cas de routage asymétrique, la lose.
On peut lire dans le man de pf.conf la prose suivante:


reply-to
The reply-to option is similar to route-to, but routes packets that
pass in the opposite direction (replies) to the specified inter-
face. Opposite direction is only defined in the context of a state
entry, and reply-to is useful only in rules that create state. It
can be used on systems with multiple external connections to route
all outgoing packets of a connection through the interface the
incoming connection arrived through (symmetric routing enforce-
ment).

Et j’ai envie de dire “pile poil”. Voyons ce que cela nous donne:


real_if=”xennet0”
gateway=”192.168.0.254”

direct_ports=”{ 22,80,443 }”

pass in quick log on $real_if reply-to ($real_if $gateway) proto tcp \
from any to any port $direct_ports

Wooooh, trop balèse Watson !

Moyennant ces quelques lignes, nous pouvons constater, heureux:


imil@tatooine:~$ telnet foobar.imil.net 2323
Trying 1.2.3.4…
Connected to foobar.imil.net.
Escape character is ‘^]’.
SSH-2.0-OpenSSH_5.0 NetBSD_Secure_Shell-20080403-hpn13v1

C’est la classe ou bien ?
[tags]VPN,pf,reply-to,OpenSSH[/tags]