Non ho trovato niente di meglio di rdp2tcp da utilizzare con un server Windows che non consentisse l'accesso da amministratore o il routing della rete da interfaccia a interfaccia. Dovrai eseguire la patch OOP sul tuo rdesktop per farlo funzionare (vai alle ultime pagine per trovare quella corrispondente a una versione recente di rdesktop). Ho usato il compilatore MinGW per compilare la fine di Windows del tunnel.
Anche la documentazione è eccellente e concisa.
Quello che potrebbe sembrare un punto secondario: se usi un nome 'addin' con '-', rdesktop non riesce ad analizzare correttamente la riga di comando. Questo potrebbe essere stato un bashismo che ha richiesto una corretta fuga, ma non ne sono sicuro.
Si noti che, per quanto posso capire, questo non è un tunnel "vero" TCP che "vede" le unità dati del protocollo TCP in quanto ciò non sarebbe possibile senza i privilegi di amministratore sul lato Windows. È più simile a un proxy calzini con un endpoint preconfigurato (anche se non molto consequenziale). Dispone anche di un proxy calzini se lo desideri.
Ho gestito facilmente una sessione SSH interattiva con essa, ma non ha resistito per i trasferimenti di file SSH (ha dato "canale virtuale disconnesso" nella console rdesktop (rdp2tcp viene eseguito come processo figlio con stdout / stdin dup2'ed / piped da rdesktop , ma senza alcuna modifica a stderr)). C'era una costante nella fonte chiamata RDP2TCP_PING_TIMEOUT che sembrava un timeout keepalive per sostenere il tunnel. Supponendo una sorta di limitazione nella rete intermedia, l'aumento da 5 a 900 sembrava aver risolto il problema, e ha resistito per trasferimenti fino a 100 MB (ci sono voluti circa 15 minuti su quella particolare rete).
Oltre a ciò, tuttavia, è stato scoperto che rdp2tcp riceve un SIGPIPE, che ha affermato di aver ricevuto a causa di un'interruzione nella pipe di rdesktop, anche se non sono riuscito a trovare alcuna prova di ciò che accadesse dal codice rdesktop o dall'output di ' lsof 'che non ha mostrato variazioni nel numero di pipe per rdesktop prima e dopo il trigger SIGPIPE.
In questo caso, dovrai riavviare rdesktop, e possibilmente anche il lato Windows del tunnel. È possibile utilizzare rsync e riprendere i trasferimenti di file e forse è possibile automatizzare l'intero processo di recupero.
Tutto questo presupponeva Linux come client. Non ho provato rdesktop con patch su Windows a causa di alcuni problemi non correlati che ho avuto con Cygwin / X. Immagino che dovrebbe funzionare.
Inoltre, la mia esperienza è stata con SSH, ma è probabile che enormi trasferimenti di file con qualsiasi altro mezzo incontrino gli stessi problemi.