Tunnelling d'une connexion TCP / IP via une connexion Bureau à distance
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 pas comment faire cela via RDC, mais j'espère que la capacité existe et que je ne le sais tout simplement pas.
Je ne pense pas que vous puissiez utiliser un tunnel via RDP. Toutefois, si vous deviez créer un protocole rdp sur le serveur puis initier 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.
EDIT
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)
Si vous exécutez rdesktop côté client (au lieu du client Windows natif), vous pouvez utiliser rdp2tcp .
Il vous permet de gérer TCP transferts de ports via une connexion RDP.
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 appliquer le correctif OOP sur votre ordinateur (vous devez vous reporter 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 exigeait 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 tunnel "vrai" TCP qui "voit" le TCP unités de données de protocole, car cela ne serait pas possible sans privilèges d'administrateur. du côté de 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é, et cela a retardé les transferts allant jusqu'à 100 Mo (cela a pris environ 15 minutes sur ce réseau particulier).
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.
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.