No encontré nada mejor que rdp2tcp para usar con un servidor de Windows que no permitía acceso de administrador o enrutamiento de red de interfaz a interfaz. Necesitará hacer el parche OOP en su rdesktop para que esto funcione (vaya a las últimas páginas para encontrar el que corresponde a una versión reciente de rdesktop). Usé el compilador MinGW para compilar el extremo del túnel de Windows.
La documentación también es excelente y concisa.
Lo que podría parecer un punto menor: si usa un nombre 'addin' con '-', rdesktop no puede analizar la línea de comando correctamente. Esto podría haber sido un bashism que requirió escapar adecuadamente, pero no estoy seguro.
Tenga en cuenta que, por lo que puedo entender, este no es un túnel TCP 'verdadero' que 've' las unidades de datos del Protocolo TCP, ya que eso no sería posible sin privilegios de administrador en el lado de Windows. Es más como un proxy de calcetines con un punto final preconfigurado (aunque no muy consecuente). También cuenta con un proxy de calcetines real si te apetece.
Fácilmente administré una sesión SSH interactiva con él, pero no aguantó las transferencias de archivos SSH (dio 'canal virtual desconectado' en la consola rdesktop (rdp2tcp se ejecuta como su proceso hijo con stdout / stdin dup2'ed / piped por rdesktop , pero sin cambios en stderr)). Había una constante en la fuente llamada RDP2TCP_PING_TIMEOUT que parecía un tiempo de espera de keepalive para sostener el túnel. Asumiendo algún tipo de estrangulamiento en la red intermedia, aumentar esto de 5 a 900 parecía haber funcionado, y aguantó transferencias de hasta 100 MB (tomó alrededor de 15 minutos en esa red en particular).
Más allá de eso, sin embargo, se encontró que rdp2tcp recibió un SIGPIPE, que afirmó haber recibido debido a una ruptura en la tubería rdesktop, aunque no pude encontrar ninguna evidencia de que eso ocurriera ni en el código rdesktop ni en la salida de ' lsof 'que no mostró cambios en el número de tuberías para rdesktop antes y después del disparador SIGPIPE.
Si esto sucede, deberá reiniciar rdesktop, y posiblemente también el lado de Windows del túnel. Puede usar rsync y reanudar las transferencias de archivos, y tal vez pueda automatizar todo el proceso de recuperación.
Todo esto suponía que Linux era su cliente. No he probado el parche rdesktop en Windows debido a algunos problemas no relacionados que tuve con Cygwin / X. Supongo que debería funcionar.
Además, mi experiencia fue con SSH, pero es probable que grandes transferencias de archivos por cualquier otro medio tengan los mismos problemas.