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.
remote-desktop
port-forwarding
Kristopher Johnson
la source
la source
Si vous exécutez rdesktop côté client (au lieu du client Windows natif), vous pouvez utiliser rdp2tcp .
Il vous permet de gérer le transfert de ports TCP via une connexion RDP.
la source
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.
la source
Je pense que vous pouvez utiliser la redirection de port locale vers RDP:
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
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.
la source