Je n'ai rien trouvé de mieux que rdp2tcp à utiliser avec un serveur Windows qui n'autorisait pas l'accès administratif ou le routage réseau interface-à-interface. Vous devrez appliquer le patch OOP sur votre rdesktop pour que cela fonctionne (allez aux dernières pages pour trouver celui correspondant à 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 être un point mineur : Si vous utilisez un nom 'addin' avec un '-' dedans, rdesktop échoue à parser correctement la ligne de commande. Il s'agissait peut-être d'un bashism qui nécessitait un échappement approprié, mais je ne suis pas certain.
Notez que autant que je puisse comprendre, il ne s'agit pas d'un tunnel TCP "vrai" qui "voit" les unités de données du protocole TCP car ce ne serait pas possible sans privilèges administratifs du côté Windows. C'est plutôt comme un proxy socks avec un point d'extrémité préconfiguré (pas très conséquent toutefois). Il comporte également un proxy socks réel si cela vous intéresse.
J'ai facilement géré une session SSH interactive avec ça, mais ça ne tenait pas pour les transferts de fichiers SSH (affichait 'virtual channel disconnected' dans la console rdesktop (rdp2tcp s'exécute en tant que processus enfant avec stdout/stdin dupliqué/pipé par rdesktop, mais sans changement du stderr)). Il y avait une constante dans le code appelée RDP2TCP_PING_TIMEOUT qui ressemblait à un timeout d'keepalive pour maintenir le tunnel. En supposant une sorte d'étranglement dans le réseau intermédiaire, augmenter cela de 5s à 900s semblait avoir fait l'affaire, et ça a tenu pour des transferts allant jusqu'à 100 MB (ça a pris environ 15 minutes sur ce réseau particulier).
Cependant, rdp2tcp a été trouvé à recevoir un SIGPIPE, qu'il prétendait avoir reçu en raison d'une rupture dans le tuyau rdesktop, bien que je n'ai trouvé aucune preuve de cela se produisant de la part du code rdesktop, ou de la sortie de 'lsof' qui ne montrait aucun changement dans le nombre de tuyaux pour rdesktop avant et après le déclenchement de SIGPIPE.
Si cela se produit, vous devrez redémarrer rdesktop, et éventuellement l'extrémité Windows du tunnel aussi. Vous pouvez utiliser rsync et reprendre les transferts de fichiers, et peut-être automatiser tout le processus de récupération.
Tout ceci était en supposant Linux comme votre client. Je n'ai pas essayé le rdesktop patché sur Windows en raison de quelques problèmes non liés que j'ai eu avec Cygwin/X. Je suppose que cela devrait fonctionner.
Aussi, mon expérience était avec SSH, mais les transferts de fichiers volumineux par tout autre moyen risquent de rencontrer les mêmes problèmes.
