Forum général.général Tunnel SSH avec rebond

Posté par  .
Étiquettes : aucune
0
3
déc.
2009
Bonjour,

Mon besoin : Contrôler via vnc la machine d'un client qui ne sait pas configurer son nat (ou ne peut pas).

Les intervenants :
Une machine chez un client : CLIENT (windows xp, putty, UltraVNC server)
Un serveur avec une ip publique : SERVEUR (debian lenny)
La machine du hotliner : HOTLINER (windows xp, putty, UltraVNC client)

Les tentatives :
Pour passer le NAT du client, un tunnel a été établi entre le port 10000 du serveur et le port local 5900 du client sous putty (remote tunnel). Voici ce qu'on voit sur le serveur :

# netstat -ant | grep 10000
tcp 0 0 127.0.0.1:10000 0.0.0.0:* LISTEN

Premier problème :
# telnet localhost 10000
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
Connection closed by foreign host.

Alors que sur CLIENT en utilisant telnet localhost 5900 on voit un peu d'ascii s'afficher.

UltraVNC a été installé sur le PC client à l'écoute de localhost:5900

Ensuite, sur HOTLINER, on configure un tunnel local avec putty entre le localhost:6000 et IPDUSERVEUR:10000.

Je pensais, probablement naîvement, que les paquets envoyés sur localhost:6000 (HOTLINER), passerait par le tunnel local pour arriver sur le port 10000 de SERVEUR, et ensuite par le tunnel remote du port 10000 de SERVEUR au port 5900 de CLIENT.

Mais en tentant une connexion depuis HOTLINER sur localhost 6000 via UltraVNC client, ce dernier dit "Connexion failed - Error reading protocol version".
En tentant un telnet localhost 6000 depuis HOTLINER, l'invite de commande est effacée, et au bout d'une dizaine de secondes elle rend la main sans message particulier.

J'ai mal fait un truc, ou alors ce que j'essaye de faire est impossible (ce que je n'espère pas) ?

  • # UltraVNC SingleClick

    Posté par  (site web personnel) . Évalué à 4.

    Bonjour,

    Personnellement, dans ce cas, j'utilise ultraVNC singleclick (http://www.uvnc.com/addons/singleclick.html)

    C'est le client qui initie la connexion, donc ça passe le NAT. L'avantage, c'est qu'il n'y a rien à installer sur le poste client.

    Sur SERVEUR, tu fais une redirection du port 5500 vers le 5500 de HOTLINER.

    Sur ce dernier tu fais tourner un vncviewer -listen.

    L'inconvénient, c'est que l'adresse ip du "SERVEUR" est en dur dans l'application, qui est générée en ligne.

    L'autre inconvénient, c'est que ce n'est pas bien libre apparemment.

    Cordialement

    • [^] # Re: UltraVNC SingleClick

      Posté par  . Évalué à 1.

      L'idée est intéressante, mais elle ne permet le contrôle que depuis un unique HOTLINER, car il faudra faire une redirection de port sur le NAT des hotlines, et l'ip de redirection est par définition fixe.

      Le besoin est que n'importe lequel des hotliners puisse prendre le contrôle de n'importe lequel des clients. C'est pour ça que je tente de passer par SERVEUR (qui n'est pas derrière un NAT, et qui a une ip fixe), afin qu'il mette en relation le CLIENT et le HOTLINER.

      Un autre avantage des tunnels ssh est que les mots de passe VNC ne circulent pas en clair sur le net. C'est un bonus intéressant.

  • # Essayons de faire simple

    Posté par  . Évalué à 4.

    Salut,

    J'ai l'impression que tu as pas mal compliqué la question avec tes doubles tunnels...

    Si j'ai bien compris, les hotliners peuvent se connecter en SSH sur le serveur SERVEUR.
    Dans ce cas, depuis les hotliners, il suffit d'ouvrir une connexion SSH en forwardant le port local 10000 vers le port 5900 de CLIENT. L'option à utiliser pour OpenSSH (ou putty) est :
    -L10000:CLIENT:5900
    Ensuite, les hotliners doivent se connecter avec VNC sur localhost:10000 pour accéder au serveur VNC de CLIENT.

    Est-ce clair comme ça ?

    A+
    JJD

    • [^] # Re: Essayons de faire simple

      Posté par  . Évalué à 2.

      Pour détailler un peu les problèmes qui font que ta solution ne fonctionnait pas (en dehors de sa complexité) voici quelques éléments :
      1- SERVEUR écoutait sur le port 10000 de l'interface de loopback (127.0.0.1). Pour que ça fonctionne, il faut, depuis HOTLINER, établir en tunnel entre localhost:6000 (ici localhost est HOTLINER) et localhost:10000 (et là localhost est SERVEUR !)
      2- Est-ce que SERVEUR peut accéder au port 5900 de CLIENT directement ? (sinon ma solution précédente ne fonctionne pas). Comment le tunnel entre SERVEUR:10000 et CLIENT:5900 a-t-il été établi ? Est-ce bien aussi un tunnel SSH ? Est-ce qu'il est créé avec putty depuis CLIENT avec les options -R10000:localhost:5900 ? Si c'est ça, il est normal que le port 10000 soit ouvert uniquement sur l'interface lo de SERVEUR et la remarque 1 de ce post reste valable.

      • [^] # Re: Essayons de faire simple

        Posté par  . Évalué à 1.

        1- Il y a, depuis HOTLINER, un tunnel entre localhost:6000 et SERVEUR:10000 via un tunnel "local" (-L6000:SERVEUR:10000)

        2- SERVEUR ne peut pas accéder au port 5900 de CLIENT directement, car CLIENT est derrière un NAT. Le tunnel entre SERVEUR:10000 et client:5900 a été établi via un -R10000:SERVEUR:5900.

        Si je comprends bien il faut que je l'établisse par un -R10000:localhost:5900 car localhost s'entend par rapport à SERVEUR et non pas CLIENT ?
        Pareil pour CLIENT (donc -L6000:localhost:10000) ?

        • [^] # Re: Essayons de faire simple

          Posté par  . Évalué à 2.

          En clair les deux tunnels à réaliser, via des connexions SSH sur SERVEUR sont :
          - sur HOTLINER : -L6000:localhost:10000
          - sur CLIENT : -R10000:localhost:5900
          Ensuite, sur hotliner on ouvre une session VNC sur localhost:6000


          Il est important d'utiliser localhost (ou 127.0.0.1) car :
          - le serveur VNC ne semble écouter que sur cette interface locale
          - lors de l'ouverture d'un tunnel "remote", le port ouvert ne l'est que sur l'interface de loopback (sauf demande explicite et modification de la configuration par défaut du serveur SSH)
          Il est vrai que mettre du "localhost" partout peut paraître déroutant, mais c'est juste un point de vue :
          - dans l'option -Lport1:SERVER:port2, le paramétre SERVER est géré par le serveur SSH. Dans ce cas, localhost désigne donc le serveur SSH lui-même
          - dans l'option -Rport1:SERVER:port2, le paramètre serveur est vu côté client SSH. localhost désigne alors le client SSH !

          J'espère que tu y vois maintenant plus clair dans ces histoires de tunneling SSH

          A+
          JJD

          • [^] # Re: Essayons de faire simple

            Posté par  . Évalué à 1.

            Bon je viens de tester, ça fonctionne ! :)

            J'étais pas très loin de la solution, mais tu m'as été d'une grande aide, merci à toi ! Je suis d'ailleurs tombé lors de ma recherche sur d'autres topics de ce forum où tu aides d'autres types sur des questions concernant les tunnels. Tu as l'air d'être spécialiste du sujet. ;)

            Bon reste plus qu'à fignoler, encapsuler tous ces lancements à coup de .bat pour simplifier la vie des CLIENTs et des HOTLINERs.

    • [^] # Re: Essayons de faire simple

      Posté par  . Évalué à 1.

      Salut,

      Voyons si j'ai bien compris :
      Sur CLIENT : ultravnc serveur qui écoute localhost:5900
      Sur SERVEUR : un simple serveur SSH
      Sur HOTLINER : un client UltraVNC et un tunnel putty -L10000:CLIENT:5900

      Mais dans ce cas, comment CLIENT va être contacté, vu qu'il est derrière un NAT ?

      HOTLINER est derrière un NAT, ainsi que client (c'est un autre NAT bien sûr). SERVEUR est directement joignable depuis internet (pas de nat, ip fixe).

      • [^] # Re: Essayons de faire simple

        Posté par  . Évalué à 1.

        J'avais d'abord cru comprendre que SERVEUR était sur le réseau de CLIENT et qeu c'était la seule machine de ce réseau accessible de puis HOTLINER. Visiblement je me suis trompé.
        La solution avec deux tunnels SSH vers SERVEUR est donc la bonne. Il ne te reste plus qu'à cacher la complexité de putty/SSH derrière une belle interface graphique et tu auras réinventé LogMeIn !

  • # Un VPN tout simplement.

    Posté par  . Évalué à 2.

    La réponse est dans le titre.. Tu installes un client OpenVPN sur le poste de chaque client, et voilà :)

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.