Tunelowanie połączenia TCP / IP za pomocą połączenia pulpitu zdalnego

W sieci prywatnej znajduje się zdalny serwer Windows, z którym mogę się połączyć za pomocą Podłączania pulpitu zdalnego. Chciałbym móc nawiązywać połączenia TCP / IP z mojego komputera do innych komputerów w sieci tego serwera.

Podłączanie pulpitu zdalnego umożliwia udostępnianie drukarek, napędów i innych lokalnych zasobów za pośrednictwem połączenia. Czy jest jakiś sposób na „tunelowanie” połączenia TCP / IP przez RDC?

Chciałbym coś podobnego do przekierowywania portów zapewnianego przez SSH. Nie widzę żadnego sposobu, aby to zrobić za pośrednictwem RDC, ale mam nadzieję, że istnieje taka możliwość i po prostu nie wiem o tym.

Nie sądzę, żebyś mógł tunelować przez RDP, jednak jeśli miałbyś zrobić rdp do serwera, a następnie zainicjować tunel ssh z powrotem do swojego klienta, twoje maszyny byłyby połączone przez ssh. Możesz przekierowywać zarówno zdalne, jak i lokalne porty, abyś mógł to zrobić, aby wszystko było odwrotnie

EDYTOWAĆ

Jeśli zainstalujesz serwer ssh na komputerze klienckim i ustawisz go tak, aby akceptował połączenia ssh na porcie 443, możesz połączyć się z serwerem ssh (twoim klientem) z serwera (używając połączenia klienta ssh) i nie będziesz musiał otwierać żadnych portów ( 443 powinien być otwarty dla https)

Jeśli używasz rdesktop po stronie klienta (zamiast natywnego klienta Windows), możesz użyć rdp2tcp .
Pozwala zarządzać przekierowaniem portów TCP przez połączenie RDP.

Nie znalazłem nic lepszego niż rdp2tcp do użycia z systemem Windows Server, który nie pozwalałby na dostęp administratora ani routing sieci między interfejsami. Musisz zrobić łatkę OOP na swoim rdesktop, aby to zadziałało (przejdź do ostatnich stron, aby znaleźć tę odpowiadającą najnowszej wersji rdesktop). Użyłem kompilatora MinGW do skompilowania końca tunelu w systemie Windows.

Dokumentacja jest również doskonała i zwięzła.

Co może wydawać się drobną kwestią: Jeśli użyjesz nazwy „addin” z „-”, to rdesktop nie będzie poprawnie analizował wiersza poleceń. To mógł być bashizm, który wymagał właściwej ucieczki, ale nie jestem pewien.

Zauważ, że o ile rozumiem, nie jest to „prawdziwy” tunel TCP, który „widzi” jednostki danych protokołu TCP, ponieważ nie byłoby to możliwe bez uprawnień administratora po stronie Windows. Przypomina bardziej proxy skarpet z wstępnie skonfigurowanym punktem końcowym (choć nie bardzo konsekwentnym). Zawiera również rzeczywiste proxy skarpet, jeśli masz na to ochotę.

Z łatwością zarządzałem z nim interaktywną sesją SSH, ale nie wytrzymała transferu plików SSH (dała „wirtualny kanał rozłączony” w konsoli rdesktop (rdp2tcp działa jako proces potomny z stdout / stdin dup2'ed / piped by rdesktop , ale bez zmiany na stderr)). W źródle istniała stała o nazwie RDP2TCP_PING_TIMEOUT, która wyglądała jak limit czasu podtrzymania tunelu. Zakładając pewien rodzaj dławienia w sieci pośredniej, wydawało się, że zwiększenie tej wartości z 5s do 900s załatwiło sprawę i wstrzymało się do transferu do 100 MB (zajęło to około 15 minut w tej konkretnej sieci).

Poza tym okazało się, że rdp2tcp odbiera SIGPIPE, który, jak twierdził, otrzymał z powodu przerwy w rurze rdesktop, chociaż nie mogłem znaleźć żadnych dowodów na to, że dzieje się to zarówno z kodu rdesktop, jak i wyniku „ lsof ', który nie wykazał zmiany liczby potoków dla rdesktop przed i po wyzwalaczu SIGPIPE.

Jeśli tak się stanie, będziesz musiał ponownie uruchomić rdesktop, a być może także stronę tunelu w systemie Windows. Możesz użyć rsync i wznowić przesyłanie plików, a może zautomatyzować cały proces odzyskiwania.

Wszystko to zakładało, że Linux będzie Twoim klientem. Nie próbowałem załatanego rdesktop na Windowsie z powodu pewnych niezwiązanych problemów z Cygwin / X. Myślę, że to powinno zadziałać.

Moje doświadczenie dotyczyło również SSH, ale ogromne transfery plików w jakikolwiek inny sposób prawdopodobnie napotkają te same problemy.

Myślę, że możesz użyć lokalnego przekierowania portów do RDP:

A -> B -> C

A to Windows lub Mac, B to Linux, a C to Windows. Jeśli chcesz przejść z RDP do C z A, a C nie jest bezpośrednio osiągalne z A, to z A

ssh username@B -L 7777:C:3389

Otwórz klienta RD, a następnie w punkcie 127.0.0.1:7777 użyj nazwy użytkownika i hasła C. Próbowałem tego z komputera Mac, ale powinien działać dla systemu Windows.