-->[]

Super : j'ai réussi à faire exécuter un programme par un serveur RPC situé sur ma machine, à la demande d'un client RPC situé... sur ma machine. Le XML-RPC en question est transporté sur du Jabber, par un serveur situé... allez je vous laisse deviner. La magie d'internet.

lire la suite

Bon, je viens de découvrir un truc pas mal qui devrait intéresser pas mal de monde, par exemple les étudiants de l'INSIA.
Ce merveilleux protocole qu'est SSH comporte une fonctionnalité que je ne connaissais pas : le port-forwarding dynamique. Autrement dit, le client ssh transforme votre machine en proxy SOCKS (4 ou 5).
Comment ça marche : ssh -D nnnn login@machine_distante
Et ça fait quoi ? Ça permet d'utiliser localhost:nnnn comme serveur SOCKS quand on en a envie. Petit exemple.
Je suis sur une machine qui s'appelle par exemple "pfff" (on ne rigole pas). Je fais les opérations suivantes :

• davux@pfff% ssh -D 1080 dammouia@ssh.insia.org
• J'ouvre mon browser web préféré que j'ai préalablement configuré pour toujours passer par le serveur localhost sur le port 1080 (c'est juste pour l'exemple, il faut bien sûr le configurer de manière moins catégorique)
• J'essaie de charger une page sur 10.43.43.1 (oui oui, c'est bien une IP non routable)

Que se passe-t-il ? La page demandée est chargée : le browser l'a demandée au serveur SOCKS en local qui est allé demander à sa mère ssh.insia.org parce que tout seul il y connaît rien. Et pour ssh.insia.org, 10.43.43.1 ça répond, donc il fait passer. En plus, ce qui est cool c'est que la partie internet du voyage se fait sur une connexion chiffrée.
Total : on se retrouve avec la même chose que les tunnels SSH classiques, mais en mieux : chaque requête peut s'adresser à une machine différente (c'est un tunnel avec une entrée et plusieurs sorties en fait).

Alors y'a quand même un problème, qu'on connaissait avec le port-forwarding classique : si la machine en face est un serveur web qui bosse avec des virtual hosts, c'est pas cool de lui filer juste une IP. Le problème, c'est que c'est l'OS local qui essaie de résoudre le nom, et que forcément, il connaît pas la machine qu'on cherche, par exemple machinelocale.insia.org. Une solution est alors de mettre la correspondance entre 10.43.43.1 et machinelocale.insia.org dans le fichiers /etc/hosts (sous unix). Une autre solution serait que le DNS de insia.org (dans notre exemple) réponde aux requêtes qui demandent machinelocale.insia.org. Ça ne poserait pas de problème de sécurité énorme de dévoiler quelques noms de machines internes (puisqu'elles sont internes justement, donc inaccessibles), et ça permettrait d'éviter de maintenir une liste de mappings.

Enfin donc voilà : cette méthode devrait permettre d'éviter de configurer plein de tunnels SSH dans tous les sens. Un seul tunnel dynamique et ça roule...