Sie müssen einen Weg finden, wie RDP über einen Reverse-SSH-Tunnel an einen lokalen Listener an einem angegebenen kurzlebigen Port zurückgerufen werden kann

1996
Kentgrav

Dies bezieht sich auf eine vorherige Frage, die aufgrund meiner ständigen Aktualisierungen und Bearbeitungen völlig zu lang und verwirrend wurde, und ich wurde aufgefordert, sie erneut zu fragen. Ich säubere es also und stelle eine direktere Frage.

Zunächst einmal ist dies ein theoretisches Experiment, das ich durchführen muss, um zu lernen, wie Vorwärts- und Rückwärtsfahren von SSH-Tunneln funktionieren, und insbesondere, um jederzeit die vollständige Kontrolle darüber zu haben, wo ich im Netzwerk bin, und meine Schritte während des gesamten Prozesses zu verbergen. Mein Trainer hat mir diese Aufgabe übertragen, aber er vertraut darauf, dass ich es ohne Hilfe von mir selbst herausfinde.

Ich muss einen Weg finden, um zu erzwingen RDP(Remote Desktop), auf einen bestimmten Port anstelle eines RHP (Random High Port) zu reagieren. Ich frage nicht, wie ich den Port ändern soll RDP, sondern das Gegenteil.

Ich versuche, einen experimentellen Forward / Reverse- SSHTunnel zwischen zwei Systemen einzurichten . Ich verwende ein drittes System als Pivot-Punkt, um meine IP im Vorwärtskanal zu verbergen. Aber ich möchte, dass das System, in dem ich Remoting bin, durch den Forward SSH-Tunnel die Antwort durch einen separaten Reverse- SSHTunnel an einen "angegebenen" Port anstelle eines RHP sendet. Die Grundidee ist, ich möchte in der Lage sein zu steuern, welche Ports ich hören und empfangen möchte, und ich möchte nicht, dass irgendetwas zufällig ist.

Das sind meine drei Maschinen. Devilsmilkist der Drehpunkt, der Client ist eingeschaltet kgravesund ich bin in Remoting duclaw.

  • KGRAVES - 10.0.10.113
  • Teufelsmilch - 10.0.10.121
  • DUCLAW - 10.0.10.120

Ich möchte also zwei Pipes für meine RDPSession haben. Einer für den Vorwärts- und der andere für den Rückwärtsgang. Aber ich möchte es nicht per RHP zurücksenden. Ich kann nicht herausfinden, wie ich es sagen soll, um es an einen bestimmten Port zu senden, :44444zum Beispiel.

Weiß jemand, wie das geht?

Ich brauche dies auf eine bestimmte Weise. Dies sind die Anschlüsse I Have zu verwenden. Ich habe bereits so eingestellt Duclaw, dass RDPauf Port 1337statt auf überwacht wird 3389. Ich weiß, dass dies keinesfalls der einfachste Weg ist, dies zu tun.

Ich brauche die Remote-Desktop-Verbindung, um "so zu erscheinen", als würde sie kommen, devilsmilkwas laut Wireshark bereits geschieht. Aber ich möchte duclawdie Antwort direkt zurückschicken, kgravesohne durchzugehen devilsmilk. So zu kgravesder RDPSitzung an den gesendet wird, localhostdie über weitergeleitet wird dann sshdurchtunneln devilsmilkzu duclaw, aber die RDPPakete, die aus direkt in Reaktion auf diese Verbindung empfangen empfangen werden Duclaw. Derzeit kommt die Antwort auf ein RHP durchdevilsmilk

Meine Befehle lauten wie folgt, und alle werden von derselben CYGWIN sshKonsole aus ausgeführt, mit kgravesAusnahme der mstscVerbindung, die ich von einem anderen CYGWINTerminal aus anbrachte. kgravesIch habe einen Zeilenumbruch für den Switch hinzugefügt:

CNO\kgraves@KGRAVES ~ $ ssh -vg -L 3333:localhost:6666 misfitred@devilsmilk OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012 debug1: Reading configuration data /etc/ssh_config debug1: Connecting to devilsmilk [10.0.10.121] port 22. debug1: Connection established. debug1: identity file /home/kgraves/.ssh/id_rsa type 1 debug1: identity file /home/kgraves/.ssh/id_rsa-cert type -1 debug1: identity file /home/kgraves/.ssh/id_dsa type -1 debug1: identity file /home/kgraves/.ssh/id_dsa-cert type -1 debug1: identity file /home/kgraves/.ssh/id_ecdsa type -1 debug1: identity file /home/kgraves/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.1 key_read: uudecode devilsmilk ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwVZRlnAgPRPxTx cbTPALg5XPpOnAMhJabQ3Dv/7a95eqe5l7XnKRciYQZ41B61DRgXCzC/M9ObknMR79zG0mkSl+jQTGJ7 klol7nw0+U1dNFknv4fOn+YGAsqECclWEow3OK5xRcla5eBekRGWjrZ7Wbs4F3FeKGQNqU/OuGvdSaQb 3nqgLPGTZfRhNtykQvpNzXw5cjO7XvM0BBv9di4JblLx9Fk3iq2KwdgWmK9uFDPYjU1gkHR8hk+bns1t 16KFcyDKnzhR1CblU6JT/wlBtnFa11no1UJBEHC2UQy8trwkMU6NqUt0X+D/XqW5F6+uWNc/dY97CCky 9HdfWNGQ== failed debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA b5:d6:eb:64:50:2f:40:04:32:10:bb:4f:a8:d3:f5:37 key_read: uudecode devilsmilk ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwVZRlnAgPRPxTx cbTPALg5XPpOnAMhJabQ3Dv/7a95eqe5l7XnKRciYQZ41B61DRgXCzC/M9ObknMR79zG0mkSl+jQTGJ7 klol7nw0+U1dNFknv4fOn+YGAsqECclWEow3OK5xRcla5eBekRGWjrZ7Wbs4F3FeKGQNqU/OuGvdSaQb 3nqgLPGTZfRhNtykQvpNzXw5cjO7XvM0BBv9di4JblLx9Fk3iq2KwdgWmK9uFDPYjU1gkHR8hk+bns1t 16KFcyDKnzhR1CblU6JT/wlBtnFa11no1UJBEHC2UQy8trwkMU6NqUt0X+D/XqW5F6+uWNc/dY97CCky 9HdfWNGQ== failed The authenticity of host 'devilsmilk (10.0.10.121)' can't be established. RSA key fingerprint is b5:d6:eb:64:50:2f:40:04:32:10:bb:4f:a8:d3:f5:37. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'devilsmilk' (RSA) to the list of known hosts. debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/kgraves/.ssh/id_rsa debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug1: Trying private key: /home/kgraves/.ssh/id_dsa debug1: Trying private key: /home/kgraves/.ssh/id_ecdsa debug1: Next authentication method: keyboard-interactive Password: debug1: Authentication succeeded (keyboard-interactive). Authenticated to devilsmilk ([10.0.10.121]:22). debug1: Local connections to *:3333 forwarded to remote address localhost:6666 debug1: Local forwarding listening on :: port 3333. debug1: channel 0: new [port listener] debug1: Local forwarding listening on 0.0.0.0 port 3333. debug1: channel 1: new [port listener] debug1: channel 2: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. Last login: Wed Jan 30 16:13:02 2013 from kgraves.cno.local [misfitred@devilsmilk ~]$ ssh -vg -L 6666:localhost:1337 kgraves@duclaw OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to duclaw [10.0.10.120] port 22. debug1: Connection established. debug1: identity file /home/misfitred/.ssh/id_rsa type 1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1 debug1: match: OpenSSH_6.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'duclaw' is known and matches the RSA host key. debug1: Found key in /home/misfitred/.ssh/known_hosts:3 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug1: Next authentication method: publickey debug1: Offering public key: /home/misfitred/.ssh/id_rsa debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug1: Next authentication method: password kgraves@duclaw's password: debug1: Authentication succeeded (password). debug1: Local connections to *:6666 forwarded to remote address localhost:1337 debug1: Local forwarding listening on 0.0.0.0 port 6666. debug1: channel 0: new [port listener] debug1: Local forwarding listening on :: port 6666. debug1: channel 1: new [port listener] debug1: channel 2: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 Last login: Wed Jan 30 15:55:29 2013 from devilsmilk.cno.local "tty" option detected in CYGWIN environment variable. CYGWIN=tty is no longer supported. Please remove it from your CYGWIN environment variable and use a terminal emulator like mintty, xterm, or rxvt.  kgraves@DUCLAW ~ $ ssh -vg -R 3333:devilsmilk:6666 kgraves@kgraves OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012 debug1: Reading configuration data /etc/ssh_config debug1: Connecting to kgraves [10.0.10.113] port 22. debug1: Connection established. debug1: identity file /home/kgraves/.ssh/id_rsa type 1 debug1: identity file /home/kgraves/.ssh/id_rsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1 debug1: match: OpenSSH_6.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA de:1c:37:d7:84:0b:f8:f9:5e:da:11:49:57:4f:b8:f1 debug1: Host 'kgraves' is known and matches the ECDSA host key. debug1: Found key in /home/kgraves/.ssh/known_hosts:3 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/kgraves/.ssh/id_rsa debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug1: Next authentication method: password kgraves@kgraves's password: debug1: Authentication succeeded (password). Authenticated to kgraves ([10.0.10.113]:22). debug1: Remote connections from LOCALHOST:3333 forwarded to local address devils milk:6666 debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: remote forward failure for: listen 3333, connect devilsmilk:6666 Warning: remote port forwarding failed for listen port 3333 debug1: All remote forwarding requests processed Last login: Wed Jan 30 16:21:12 2013 from duclaw.cno.local "tty" option detected in CYGWIN environment variable. CYGWIN=tty is no longer supported. Please remove it from your CYGWIN environment variable and use a terminal emulator like mintty, xterm, or rxvt. _____________________________________________________________________________ ##From separate CYGWIN Terminal## CNO\kgraves@KGRAVES ~ $ mstsc /v:localhost:3333 /f  CNO\kgraves@KGRAVES ~ $ _____________________________________________________________________________  kgraves@KGRAVES ~ $ debug1: Connection to port 3333 forwarding to localhost port 6666 requested. debug1: channel 4: new [direct-tcpip] debug1: Connection to port 6666 forwarding to localhost port 1337 requested. debug1: channel 4: new [direct-tcpip] debug1: channel 4: free: direct-tcpip: listening port 3333 for localhost port 66 66, connect from ::1 port 49496, nchannels 5 debug1: channel 4: free: direct-tcpip: listening port 6666 for localhost port 13 37, connect from 127.0.0.1 port 48808, nchannels 5 debug1: Connection to port 3333 forwarding to localhost port 6666 requested. debug1: channel 4: new [direct-tcpip] debug1: Connection to port 6666 forwarding to localhost port 1337 requested. debug1: channel 4: new [direct-tcpip] $ debug1: channel 3: free: direct-tcpip: listening port 3333 for localhost port 6666, conne ct from ::1 port 49495, nchannels 5 debug1: channel 3: free: direct-tcpip: listening port 6666 for localhost port 1337, connect from 127.0.0.1 port 48807, nchannels 5 $

Remotedesktopverbindung zu localhost: 3333 wurde erfolgreich hergestellt. Und wie Sie sehen, sieht es so aus, als würde es von devilsmilkvorne kommen duclaw. Aber laut kgraveskommt es von zurück Devilsmilk.

Dies ist eine Momentaufnahme der wiresharkAusführung von Duclaw während der RDPSitzung:

enter image description here

Dies ist eine Momentaufnahme der wiresharkAusführung kgraveswährend der RDPSitzung:

enter image description here

Mein Problem bleibt also immer noch, dass ich möchte, dass Duclaw die RDP-Sitzung durch einen vollständig separaten Rücktunnel an Kgraves-pc zurücksendet. Das ist es, was ich tun muss und kann nicht herausfinden, wie ich das machen soll.

Ich muss duclawes nicht nur in einem separaten Tunnel zurückschicken, kgravesohne es zu durchlaufen devilsmilk, sondern ich muss auch kontrollieren, an welchen Ephemeral-Port es gesendet wird. Ich möchte, dass es an einen Port gesendet wird, :44444anstatt an einen zufälligen kurzlebigen Port. Es wird :48809zufällig im ausführlichen Debug- sshAusdruck oben verwendet.

In einem frühen Stadium wurde mir vom Benutzer John Siu nahe gebracht, dass dies aufgrund der TCP-Kommunikation nicht möglich ist. Weil kgraveserwartet, dass eine Verbindung von localhost hergestellt wird, seit sie mit localhost eingerichtet wurde. Es muss also einen Weg geben, duclawan den die Sitzung kgravesgesendet werden kann. Wurde sie jedoch so weitergeleitet, als würde sie localhostvielleicht von dort kommen?

Mein Trainer sagte mir jedoch, dass der TCP-Dreiwege-Handshake aufgrund der Art des RFC für 127.0.0.1 (Localhost) niemals Schicht 4 des OSI-Modells verlässt und eine Art "Features" enthält, die das ausschließen syn, syn-ack, ack erforderlich, wenn eine Verbindung zu 127.0.0.1 hergestellt wird. Daher folgt TCP nicht ganz den gleichen Regeln, wenn es mit localhost verbunden ist. Er sagte, wenn Sie ein "Wireshark" -Programm schreiben könnten, um an Schicht 4 zu schnüffeln und die Verbindung aufzubauen, würden Sie sehen, worüber er spricht.

Ich habe die folgenden möglichen Antworten erhalten, die dem Benutzer John Siu bisher gutgeschrieben wurden.

1.) Um das zu tun, was Sie fragen, ist die einzige Methode, die ich mir vorstellen kann, einen benutzerdefinierten rdp-Proxy zu schreiben und auf kgraves-pc und duclaw auszuführen.

2.) Mir wurde auch gesagt, dass es eine Art Virus gibt, das ich verwenden kann, der im Wesentlichen den rdp-Proxy spottet, über den John Siu sprach. In meinem virtuellen Labor kann ich die Malware / Viren verwenden, die ich verwenden möchte, um diese Systeme auszunutzen. So ist alles möglich.

Jede weitere Hilfe wäre sehr dankbar! Vielen Dank für Ihre Beiträge!

Hoffentlich macht das Sinn, wenn nicht ... Entschuldigung für die Verwirrung!

EDIT # 1: Ich konnte das, was ich anfangs sah, nachvollziehen, weil ich glaubte, dass dieser umgekehrte Tunnel anfänglich vor sich ging. Sie können aus dem wiresharkVerkehr sehen (Verkehr oben kommt von Duclawund Verkehr unten kgraves), was John unten erklärt hat, ist genau das, was gerade passiert. Jetzt, da dieses Rätsel gelöst ist, muss ich immer noch herausfinden, wie RDP zum Rückruf an einen bestimmten Port anstatt zu einem Random-Port geleitet wird.

enter image description here

2
Ich habe vor, das folgende Rätsel zu lösen: `... ABER auf Kgraves-PC hatte SSH-Verkehr direkt am 10.0.10.130 von Duclaw. Wie würde ich dann den Verkehr von Duclaw auf dem Kgraves-PC sehen? ... `Aber es wird nicht in Ihrem Wireshark angezeigt. Sehen Sie das immer noch oder ändert sich die IP? John Siu vor 11 Jahren 0
Ich sehe das nicht mehr. Auf "kgraves" sehe ich SSH-Verkehr von "devilsmilk". Ich hätte schwören können, als ich es anfangs aufgestellt hatte, dass ich es von "Duclaw" sah, aber ich sehe das jetzt nicht mehr. Nicht sicher, was ich anders gemacht habe. Oder vielleicht stellte ich mir Dinge vor. Kentgrav vor 11 Jahren 0
Eigentlich gab es eine Chance, vielleicht aufgrund der Bestellung, die Ihre SSH ausgestellt hat. Aber es ist immer noch alles in ssh tunnel. Ich werde darauf eine Antwort posten. Muss es in Zeichnung setzen, also vielleicht 30min. John Siu vor 11 Jahren 1
Was Sie tun möchten, ist nicht in der Lage zu sein, ohne kundenspezifische Software für Ihre speziellen Anforderungen zu arbeiten. Und was Ihr Trainer Ihnen über localhost über TCP erzählt hat, ist FALSCH. Denken Sie darüber nach: TCP hat keinerlei Kenntnis von IP-Adressen, das geschieht auf Schicht 3. Wie kann es also etwas Besonderes auf der Grundlage einer IP-Adresse tun? Oh, und wireshark tut genau das, was Sie in der Beschreibung eines "Wireshark" -Programms erwähnen, um auf Layer 4 zu schnüffeln. heavyd vor 11 Jahren 1
Ehrfürchtig, ich werde in den Himmel schauen. Ich werde auch das gesamte TCP auf das Missverständnis von localhost untersuchen. Ich versichere Ihnen, dass dieser Typ weiß, wovon er spricht. Was wahrscheinlich passiert ist, ist, dass ich missverstanden habe, was er mir sagen wollte, und es fehlte, es zu kommunizieren. Ich werde Klarstellung bekommen. Danke für deinen Beitrag. Kentgrav vor 11 Jahren 0
Post Antwort für das "Geheimnis". John Siu vor 11 Jahren 0

2 Antworten auf die Frage

1
John Siu

Dies ist, um ein "Geheimnis" aus einem vorherigen Kommentar zu beantworten

... ABER Am Kgraves-PC kam der SSH-Verkehr direkt am 10.0.10.120 von Duclaw. Wie würde ich dann den Verkehr von Duclaw auf dem Kgraves-PC sehen? ...

Geschichten von drei Tunneln

  1. Red kgraves-pc: 3333 to devilsmilk: 6666

    kgraves-pc $ ssh -vg -L 3333:localhost:6666 misfitred@devilsmilk(10.0.10.121)

  2. Grüne Teufelsmilch: 6666 bis Duclaw: 1337

    devilsmilk $ ssh -vg -L 6666:localhost:1337 kgraves@duclaw(10.0.10.120)

  3. Blau kgraves-pc: 3333 to (Duclaw) zu devilsmilk: 6666

    duclaw $ ssh -vg -R 3333:devilsmilk:6666 kgraves@kgraves(10.0.10.113)

Map Of 3 Tunnels

kgraves-pc$ $ mstsc /v:localhost:3333 /f

Rote Story Line

Wenn ein roter Tunnel verwendet wird, folgt das SSH (RDP) -Paket auf folgende Weise hin und her

kgraves-pc <--(Red)--> devilsmilk <--(Green)--> duclaw(RDP server end point)

Dies ist das, was in der OP-Bildschirmdarstellung gezeigt wird.

Blue Story Line

Wenn ein blauer Tunnel verwendet wird, folgt das SSH (RDP) -Paket auf folgende Weise hin und her

kgraves-pc <--(Blue-ssh)--> duclaw(en-route) <--(Blue-non-ssh)--> devilsmilk <--(Green)--> duclaw(RDP server end point)

In diesem Fall sieht es so aus, als ob kgraves-pc und Duclaw eine direkte SSH-RDP-Verbindung in Wireshark haben, aber nicht.

Übrigens danke für diese Antwort, ich überprüfe jetzt ein paar Dinge damit. Ich habe den ganzen Tag beschäftigt. Kentgrav vor 11 Jahren 0
Das macht sehr viel Sinn und ich konnte es neu erstellen! Danke für das Lösen dieses Rätsels! An diesem Punkt bin ich also wieder da, wo ich am Montag angefangen habe, aber ich habe auf dem Weg viel gelernt. Jetzt muss ich noch herausfinden, wie man RDP zum Rückruf an einen angegebenen Port bringt. Kentgrav vor 11 Jahren 0
Ich bin mir nicht sicher, ob ssh tunnel für Ihre tatsächlichen Bedürfnisse ein korrekter Ansatz ist. Die SSH-Tunnelfunktion arbeitet als normale TCP / IP. Ich werde heute Abend (einige Stunden) eine zusätzliche Antwort mit einer Konzeptzeichnung darüber, was Sie richtig suchen. Aber Sie müssen das eigentliche "Programm" finden, das dazu in der Lage ist. John Siu vor 11 Jahren 1
Mein Trainer sagte mir im Grunde, dass er mich durch ein Kaninchenloch führt und obwohl das, was ich hier zu erreichen versuche, möglich ist. Es liegt außerhalb des Rahmens dessen, was er im Moment zu lehren versucht, wobei er Daten durch einen Tunnel sendet, aber durch einen anderen Tunnel empfängt oder das empfangende Ende vollständig ein anderer Host ist. Also hat er mir gesagt, dass ich dasselbe mit FTP oder Telnet anstelle von RDP tun soll. Ich werde Ihnen also einen Schuss geben und Ihre Antwort als die richtige Antwort markieren, da Sie dazu beigetragen haben, viele Fragen zu diesem gesamten Prozess zu klären. Ich schätze es. Kentgrav vor 11 Jahren 0
Wie versprochen, zusätzliche Antwort mit Konzeptzeichnung: D John Siu vor 11 Jahren 0
1
John Siu

To do what you are asking, I can only think of the following way

enter image description here

  • C = Client (Client software of rdp, telnet, etc)
  • S = Server (Server software of rdp, telnet, etc)
  • Red and Green are separate TCP/IP connection.

Custome Proxy 1

(Blue) Listen to a local port to wait for client software connection (Red) Forward incoming packet from C to Custom Proxy 2 public port (Green) Listen to a public port, forward incoming packet from Custom Proxy 2 to C (via Blue)

Custome Proxy 2

(Red) Listen to public port for incoming packet from Custom Proxy 1 (Blue) Establish connection with S, forward incoming packet from Custom Proxy 1 to S (Green) Forward incoming packet from S to Custom Proxy 1 public port

PS: Focus on Telnet, RDP, which only use one tcp connection. FTP is much more difficult as it use additional tcp connection with a random port for data(file) transfer.

Vielen Dank Alter! Ich werde das nächste Woche testen. Schätzen Sie alle Ihre Hilfe. Kentgrav vor 11 Jahren 0
FTP .. your trainer really like rabbit holes ... John Siu vor 11 Jahren 0

Verwandte Probleme