À partir du réseau WAN, VNC ne parvient pas à se connecter via le tunnel ssh 5900 s'il n'est pas également proxy local
Sur mon réseau local, je peux très facilement passer par le tunnel VNC sur ssh. Je souhaite faire la même chose de l'étranger.
Le serveur est configuré pour accepter les connexions SSH côté WAN, et cela fonctionne de manière fiable. Le problème est qu’à l’étranger, je ne peux pas démarrer une session VNC réussie sur le tunnel SSH. Une configuration de tunneling similaire est utilisée lorsque je fais la même chose sur mon réseau local (ce qui fonctionne parfaitement).
Donc, "de là-bas", je peux connecter SSH, mais lorsque j'essaie de connecter VNC à 127.0.0.1, je reçois UltraVNC: Connection failed - End of stream Causes possibles - Un autre utilisateur écoute déjà sur cet ID - Mauvaise connexion .. .avec tous les ports que je peux utiliser.
Heureusement, TightVNC fournit un certain niveau de journalisation. Une connexion défaillante est enregistrée en tant que telle:
[ 512/ 1904] 2015-03-22 10:33:34:617 : Initialization of socket stream and input/output gates...
[ 512/ 1904] 2015-03-22 10:33:34:617 : Connection is established
[ 512/ 1904] 2015-03-22 10:33:34:617 - Protocol stage is "Handshake".
[ 512/ 1904] 2015-03-22 10:33:34:647 - onDisconnect: Connection has been gracefully closed
[ 512/ 2060] 2015-03-22 10:33:35:719 - Process focus restoration in the RfbKeySym class
[ 512/ 2060] 2015-03-22 10:33:35:719 - Process focus loss in the RfbKeySym class
[ 512/ 2060] 2015-03-22 10:33:35:829 - Process focus restoration in the RfbKeySym class
Et un succès ressemble à ceci (de mon réseau local):
[ 7536/ 2900] 2015-03-22 11:22:28:892 : Initialization of socket stream and input/output gates...
[ 7536/ 2900] 2015-03-22 11:22:28:892 : Connection is established
[ 7536/ 2900] 2015-03-22 11:22:28:892 - Protocol stage is "Handshake".
[ 7536/ 8032] 2015-03-22 11:22:28:946 client rect: 0, 0; 124, 31
[ 7536/ 8032] 2015-03-22 11:22:28:946 Desktop-window. (x, y): (0, 29); (w, h): (124, 2)
[ 7536/ 2900] 2015-03-22 11:22:29:040 - Server sent protocol version: RFB 003.008
[ 7536/ 2900] 2015-03-22 11:22:29:040 - Send to server protocol version: RFB 003.008
Après des semaines d'arrachage de cheveux, de tentatives de clients différents et d'essais de la configuration de transmission de port à laquelle je pouvais penser (sur les routeurs des deux côtés), j'ai finalement réussi une percée.
J'ai mis en place un deuxième tunnel ssh dans PuTTY - Dynamic sur le port 1080 (D1080). J'ai ensuite utilisé un client VNC qui permet une connexion proxy, RealVNC VNC-Viewer, et l'ai pointé sur le port localhost 1080 (type SOCKS 5).
CETTE. TRAVAUX. Je suis maintenant sûr que ma session VNC est sécurisée, mais uniquement si je passe par un proxy SOCKS local lorsque je suis à l'étranger. L'inconvénient est que je ne peux pas utiliser mon client préféré, UltraVNC Viewer.
De plus, je ne comprends pas ce qui se passe. Je cherche une explication. Pourquoi le simple tunnel L5900 ne fait-il pas le travail depuis le réseau étendu alors qu'il le fait dans le réseau local?
Le problème ici est la configuration du tunnel SSH dans PuTTY.
Sur la base d’un didacticiel Web, j’ai configuré mon tunnel 5900 SHH avec l’adresse IP du serveur 192.168.1.110 du réseau local. Elle ressemblait donc à L5900 192.168.1.110:5900 dans PuTTY. L'hôte cible était également 192.168.1.110. Comme nous le savons, cela a bien fonctionné.
Ensuite, j'ai configuré ma session SSH avec PuTTY pour une utilisation à l'étranger. Honte à moi, j'ai utilisé l'adresse IP WAN à la fois dans l'hôte cible et dans le tunnel. Je réalise maintenant que, lorsqu'il a reçu des paquets destinés au port 5900, le serveur OpenSSH a suivi les instructions - il les a transférés vers mon routeur NAT (ou a essayé de le faire, car le pointeur se trouvait sur un WAN adresse).
Le moyen sûr de configurer PuTTY est de toujours utiliser l'adresse IP du réseau local pour le tunnel 5900. Mieux encore, comme dans mon cas, le serveur VNC est sur la même machine que le serveur OpenSSH, utilisez simplement localhost pour le tunnel, comme dans L5900 localhost:5900.