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.
remote-desktop
port-forwarding
Kristopher Johnson
źródło
źródło
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.
źródło
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.
źródło
Myślę, że możesz użyć lokalnego przekierowania portów do RDP:
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
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.
źródło