Virtualbox : rerouter une IP vers 127.0.0.1 sur l'hôte

Support Debian
#1

Bonjour à tous

J’ai Windows 7 sur la machine “host” (= le PC physique quoi, c’est mon OS de base).
Dans Windows, j’ai installé Virtualbox avec une machine virtuelle “guest” dans laquelle je fais tourner Debian Wheezy.

Il se trouve que mon Windows tourne derrière un proxy NTLM. Le problème avec ce truc, c’est que toutes les applications ne sont pas capables de gérer un tel proxy.

Donc j’ai installé sous Windows CNTLM qui permet de créer localement un proxy SOCKS 5 qui permet de faire le pont vers le proxy NTLM automatiquement, c’est très pratique !

Ainsi, si je veux par exemple configurer FileZilla pour accéder à un FTP situé sur Internet, je n’ai qu’à rentrer “127.0.0.1” port “999” dans les paramètres de proxy SOCKS 5 de FileZilla. Et donc lorsque je lance une connexion, FileZilla va se connecter à mon proxy local SOCKS 5 (en utilisant 127.0.0.1:999), qui lui va se connecter au proxy NTLM, qui lui va me laisser passer.

Voici maintenant mon problème.

Lorsque je suis dans ma machine virtuelle Debian, si je configure FileZilla en utilisant 127.0.0.1, cela va faire référence à l’adresse locale de la machine virtuelle (= la machine “guest”), et non l’adresse locale de la machine “host”.

Qu’à cela ne tienne me direz-vous, il suffit d’utiliser l’IP de la machine “host” (10.180.202.124, port 999) sous Debian. Ainsi, lorsque je lance une connexion sous FileZilla en utilisant cette IP, FileZilla va vouloir se connecter à 10.180.202.124 sur le port 999, autrement dit le proxy SOCKS 5. Oui mais voilà, il y a un pare-feu à la fois sous Windows et sur le réseau. Donc impossible d’utiliser cette IP, sinon le pare-feu me bloque la connexion.

Dooooonc, ce que j’aimerais, c’est dire à Virtualbox de rerouter l’IP 10.180.202.124 vers l’IP 127.0.0.1 de la machine “host”.

Est-ce que quelqu’un saurait comment faire ça ?? J’ai bien cherché un peu partout sur le net mais je n’ai trouvé personne qui ait évoqué un cas pareil. Ou alors je m’y prends comme un pied…

Merci à ceux qui répondront :smiley:

#2

Je ne sais pas si ça peut marcher dans ton cas mais sinon avec putty tu fais un tunnel ssh vers ta machine sous debian wheezy et apres sur ta debian wheezy tu dis redirige le traffic vers ce tunnel pour sortir sur internet.

#3

A mon avis le problème restera le même car il faut que je puisse me connecter à un serveur qui tourner sous Windows depuis la machine virtuelle, et je ne peux pas utiliser l’IP de la machine Windows puisqu’elle est bloquée par le pare-feu. Le seul moyen que je vois pour l’instant est de rerouter l’IP de la machine Windows vers 127.0.0.1 de la machine Windows.

#4

Je pense que ce lien peut régler ton problème.
http://www.dmesg.fr/categorie-reseau/54-passer-un-proxy-avec-authentification-ntlm

#5

Bonjour,

Je pense qu’en configurant une interface réseau en hostonly ça devrait le faire.

#6

[quote=“P’tit g”]Je pense que ce lien peut régler ton problème.
dmesg.fr/categorie-reseau/54 … ation-ntlm[/quote]
Malheureusement non car j’ai bien pris la peine de tester mais la connexion n’est pas fiable malheureusement. Tandis qu’avec CNTLM sous Windows il n’y a aucun problème.

#7

Je ne vois pas comment le pare-feu sur le réseau pourrait bloquer les communications entre une machine virtuelle et son hôte. Quant au pare-feu sur l’hôte, tu ne peux pas le configurer pour laisser passer ces communications ? Dans le cas contraire, je ne vois pas de solution même avec une redirection car avant d’être redirigée vers 127.0.0.1, il faut bien que la communication vers 10.180.202.124 passe.

Et non, on ne peut pas envoyer des paquets destinés à 127.0.0.1 vers l’extérieur. De toute façon, ces paquets reçus de l’extérieur seraient bloqués à la réception.

#8

Effectivement ça me paraissait bizarre à moi aussi mais comme je ne suis pas encore spécialement calé en réseaux je suis parti de ce principe. J’avais tort.

Si. Mais je n’étais pas sûr que ma règle était prise en compte. En effet il s’agit de Windows 7 et c’est déjà un OS obscur, mais en plus il faut rajouter toutes les règles déjà appliquées par la politique de sécurité définie par l’admin. Donc on ne sait jamais trop ce qu’on fait. Mais au final elle est bien prise en compte en fait.

J’ai en fait fini par trouver la solution. Après avoir testé les IP avec “nmap” depuis la machine virtuelle sous Debian, j’ai fini par comprendre.

La machine sous Windows répondait bien à un ping depuis la machine virtuelle Debian. J’en ai donc déduis que le pare-feu faisait barrage. Mais après avoir définit une règle pour bien laisser le port ouvert, j’ai vu dans la configuration de “CNTLM” une option “Gateway” qui était commentée et le commentaire au-dessus disait d’activer cette option si l’on souhaitait pouvoir utiliser le proxy SOCKS 5 depuis d’autres machines. J’ai donc décommenté la ligne… et miracle, ça fonctionne !! :smiley:

Merci beaucoup à tous pour vos réponses qui m’ont bien aidées à cerner le problème et à trouver la solution.

#9

[quote=“Cluxter”][quote=“P’tit g”]Je pense que ce lien peut régler ton problème.
dmesg.fr/categorie-reseau/54 … ation-ntlm[/quote]
Malheureusement non car j’ai bien pris la peine de tester mais la connexion n’est pas fiable malheureusement. Tandis qu’avec CNTLM sous Windows il n’y a aucun problème.[/quote]
Pour compléter ma réponse : le problème de ce logiciel est non seulement que la connexion n’est pas fiable, mais aussi et surtout qu’il repose sur l’utilisation de variables d’environnement et tous les logiciels ne les utilisent pas pour savoir s’ils doivent utiliser un proxy. Du coup on se retrouve avec des logiciels qui ne voient pas le proxy et il faut configurer pour chaque logiciel qui ne marche pas les options qui vont bien pour le proxy. Or c’est précisément ce que je cherche à éviter.
“tsocks” est déjà mieux puisqu’il remplace une bibliothèque système mais il continue d’utiliser des variables d’environnement et il faut le lancer très en amont pour qu’il englobe tout le traffic, ce qui n’est pas très joli.

J’ai donc trouvé une solution plus propre que “tsocks” ou “ntlmaps” : redsocks.

Ce logiciel se connecte au proxy SOCKS 5 et se met en écoute sur un port que l’on choisit. Il suffit alors de configurer “iptables” pour rediriger tout le traffic TCP vers le serveur “redsocks” qui va transférer au proxy SOCKS le traffic en question. Ainsi, toutes les connexions TCP sans exceptions sont passées au proxy SOCKS de façon transparente et tous les logiciels peuvent fonctionner avec sans avoir à patcher quoique ce soit. Et si l’on souhaite seulement transférer certaines connexions TCP, pas de problèmes, on reconfigure “iptables”. C’est vraiment le top et c’est d’ailleurs pour moi la seule solution valable puisqu’on ne modifie rien en terme de code, on utilise déjà toute la structure existante, ce n’est que du paramétrage.