Tunneln einer TCP / IP-Verbindung über Remotedesktopverbindung

Wenn Sie rdesktop auf der Clientseite (anstelle des nativen Windows-Clients) ausführen, können Sie rdp2tcp.
Sie können die Weiterleitung von TCP-Ports über eine RDP-Verbindung verwalten.

Ich habe nichts Besseres als rdp2tcp für die Verwendung mit einem Windows-Server gefunden, der keinen Administratorzugriff oder kein Interface-to-Interface-Netzwerkrouting zuließ. Sie müssen den OOP-Patch auf Ihrem rdesktop ausführen, damit dies funktioniert (gehen Sie zu den letzten Seiten, um die zu finden, die einer aktuellen Version von rdesktop entspricht). Ich habe den MinGW-Compiler verwendet, um das Windows-Ende des Tunnels zu kompilieren.

Die Dokumentation ist auch hervorragend und prägnant.

Was wie ein Moll erscheinen mag punkt: Wenn Sie einen 'Addin' - Namen mit ' - ' verwenden, kann rdesktop die Befehlszeile nicht korrekt analysieren. Dies könnte ein Bashismus gewesen sein, der eine ordnungsgemäße Flucht erforderte, aber ich bin mir nicht sicher.

Beachten Sie, dass dies, soweit ich verstehen kann, kein "echter" TCP-Tunnel ist, der die TCP-Protokolldateneinheiten "sieht", da dies ohne Administratorrechte auf der Windows-Seite nicht möglich wäre. Es ist eher wie ein Socks-Proxy mit einem Endpunkt, der vorkonfiguriert ist (jedoch nicht sehr folgerichtig). Es bietet auch ein tatsächlicher Socks-Proxy, wenn Sie das mögen.

Ich habe leicht eine interaktive SSH-Sitzung damit verwaltet, aber es hielt nicht für SSH-Dateiübertragungen (gab 'virtual channel disconnected' in der rdesktop-Konsole (rdp2tcp läuft als untergeordneter Prozess mit stdout/stdin dup2 ' ed/piped von rdesktop, aber ohne Änderung an stderr)). Es gab eine Konstante in der Quelle namens RDP2TCP_PING_TIMEOUT, die wie ein Keepalive-Timeout für das Halten des Tunnels aussah. Unter der Annahme einer Art Drosselung in der Zwischennetzwerk, dies von 5s auf 900s zu erhöhen, schien den Trick getan zu haben, und es hielt für Übertragungen von bis zu 100MB (dauerte etwa 15 Minuten in diesem bestimmten Netzwerk).

Darüber hinaus wurde jedoch festgestellt, dass rdp2tcp eine SIGPIPE erhielt, die angeblich aufgrund eines Bruchs in der rdesktop-Pipe empfangen wurde, obwohl ich weder aus dem rdesktop-Code noch aus der Ausgabe von 'lsof' Hinweise darauf finden konnte, dass dies der Fall ist Die Ausgabe von 'lsof', die keine Änderung der Anzahl der Pipes für rdesktop vor und nach dem SIGPIPE-Trigger.

In diesem Fall müssen Sie rdesktop und möglicherweise auch die Windows-Seite des Tunnels neu starten. Sie können rsync verwenden und Dateiübertragungen fortsetzen, und vielleicht können Sie den gesamten Wiederherstellungsprozess automatisieren.

All dies nahm Linux als Ihren Client an. Ich habe den gepatchten Rdesktop unter Windows nicht ausprobiert, da ich Probleme mit Cygwin/X hatte.

Auch meine Erfahrung war mit SSH, aber riesige Dateiübertragungen mit allen anderen Mitteln sind wahrscheinlich die gleichen Probleme zu treffen.

Ich denke, Sie können die lokale Portweiterleitung an RDP verwenden:

A -> B -> C

A ist Windows oder Mac, B ist Linux und C ist Windows. Wenn Sie von A nach C RDP möchten und C nicht direkt von A aus erreichbar ist dann auf Einem

ssh username@B -L 7777:C:3389

Öffnen RD client, dann punkt 127.0.0.1: 7777 verwenden die benutzernamen und passwort von C. Ich habe das vom Mac versucht, sollte aber für Windows funktionieren.