Tunnelling d'une connexion TCP / IP via une connexion Bureau à distance


31

Il existe un serveur Windows distant sur un réseau privé auquel je peux me connecter via Remote Desktop Connection. J'aimerais pouvoir établir des connexions TCP / IP de mon ordinateur à d'autres ordinateurs du réseau de ce serveur.

La connexion au bureau à distance permet de partager des imprimantes, des lecteurs et d'autres ressources locales via la connexion. Existe-t-il un moyen de "tunnel" une connexion TCP / IP via RDC?

Je voudrais quelque chose de similaire à la redirection de port fournie par SSH. Je ne vois aucun moyen de le faire via RDC, mais j'espère que la capacité existe et que je ne le sais tout simplement pas.

Réponses:


7

Je ne pense pas que vous puissiez utiliser un tunnel via RDP, cependant si vous deviez créer un protocole rdp sur le serveur, puis créer un tunnel ssh vers votre client, vos machines seraient connectées par ssh. Vous pouvez transférer les ports locaux et distants pour pouvoir le faire en sens inverse.

MODIFIER

Si vous installez un serveur ssh sur votre ordinateur client et le configurez pour accepter les connexions ssh sur le port 443, vous pouvez vous connecter au serveur ssh (votre client) à partir de votre serveur (à l’aide de la connexion client ssh) sans avoir à ouvrir de port ( 443 devrait être ouvert pour https)


1
Oui, il va falloir installer un serveur SSH. Malheureusement, cela nécessitera une action de la part du MIS pour ouvrir le port dans le pare-feu, ce qui peut prendre quelques jours / semaines.
Kristopher Johnson

Mon ordinateur client est derrière plusieurs couches de pare-feu. Je ne sais pas si je peux me connecter depuis le serveur au client. (Le monde était tellement plus facile lorsque tous les ports étaient ouverts.)
Kristopher Johnson

Imaginez un cas où il n’ya pas de communication viable du serveur au client même avec 443 tcp, la seule chose que nous ayons RDP
carpinchosaurio


1

Je n'ai rien trouvé de mieux que rdp2tcp à utiliser avec un serveur Windows qui n'autorisait aucun accès administrateur ni aucun routage réseau interface à interface. Pour que cela fonctionne, vous devez installer le correctif POO sur votre ordinateur rdesktop (reportez-vous aux dernières pages pour trouver celle qui correspond à une version récente de rdesktop). J'ai utilisé le compilateur MinGW pour compiler l'extrémité Windows du tunnel.

La documentation est également excellente et concise.

Ce qui peut sembler mineur: Si vous utilisez un 'addin' name avec '-', rdesktop ne parvient pas à analyser correctement la ligne de commande. C’était peut-être un penchant qui nécessitait de s’échapper, mais je ne suis pas sûr.

Notez que pour autant que je puisse comprendre, il ne s'agit pas d'un "vrai" tunnel TCP qui "voit" les unités de données du protocole TCP, car cela ne serait pas possible sans privilèges d'administrateur du côté Windows. Cela ressemble plus à un proxy socks avec un point de terminaison préconfiguré (pas très conséquent cependant). Il propose également un proxy socks si vous en avez envie.

Je gérais facilement une session SSH interactive avec elle, mais cela ne bloquait pas les transferts de fichiers SSH (donnait 'canal virtuel déconnecté' dans la console rdesktop (rdp2tcp est exécuté en tant que processus enfant avec stdout / stdin dup2'ed / acheminé par rdesktop , mais sans changement en stderr)). Il y avait une constante dans la source appelée RDP2TCP_PING_TIMEOUT qui ressemblait à un délai de maintien en attente pour bloquer le tunnel. En supposant une sorte de limitation dans le réseau intermédiaire, le passage de 5 à 900 semble avoir fonctionné, ce qui a empêché les transferts allant jusqu'à 100 Mo (cela a pris environ 15 minutes sur ce réseau).

Au-delà, cependant, il a été constaté que rdp2tcp recevait un SIGPIPE, qu’elle prétendait avoir reçu en raison d’une rupture du tuyau rdesktop, bien que je n’aie trouvé aucune preuve de ce qui se produise, ni du code rdesktop, ni de la sortie de ' lsof 'qui n'a montré aucun changement dans le nombre de canaux pour rdesktop avant et après le déclencheur SIGPIPE.

Si cela se produit, vous devrez redémarrer rdesktop et éventuellement le côté Windows du tunnel. Vous pouvez utiliser rsync et reprendre les transferts de fichiers et peut-être automatiser l’ensemble du processus de récupération.

Tout cela supposait que Linux était votre client. Je n'ai pas essayé la version corrigée de rdesktop sous Windows en raison de problèmes non liés que j'avais avec Cygwin / X. Je suppose que cela devrait fonctionner.

De plus, mon expérience portait sur SSH, mais d’énormes transferts de fichiers par tout autre moyen risquent de poser les mêmes problèmes.


comment configurer les éléments ci-dessus dans Windows 7
Thangamani Palanisamy

0

Je pense que vous pouvez utiliser la redirection de port locale vers RDP:

A -> B -> C

A est Windows ou Mac, B est Linux et C est Windows. Si vous voulez que RDP à C de A et C ne soit pas directement accessible de A puis sur A

ssh username@B -L 7777:C:3389

Ouvrez le client RD, puis sélectionnez 127.0.0.1:7777 le nom d'utilisateur et le mot de passe de C. J'ai essayé cela à partir d'un Mac, mais cela devrait fonctionner pour Windows.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.