Налаштування TCP / IP-з'єднання через підключення до віддаленого робочого столу

У приватній мережі є віддалений сервер Windows, до якого я можу підключитися через підключення до віддаленого робочого столу. Я хотів би мати можливість з'єднати TCP / IP зі свого комп'ютера на інші комп'ютери в мережі цього сервера.

Підключення до віддаленого робочого столу дає змогу ділитися принтерами, накопичувачами та іншими локальними ресурсами через з'єднання. Чи є спосіб "тунелювати" TCP / IP-з'єднання через RDC?

Я хотів би щось подібне до переадресації портів, наданих SSH. Я не бачу жодного способу зробити це через RDC, але сподіваюся, що можливість є, і я просто не знаю про це.

Я не думаю, що ви зможете пройти тунель через RDP, однак, якщо ви перейдете на сервер і потім ініціюєте тунель ssh назад до свого клієнта, ваші машини будуть підключені ssh. Ви можете переслати як віддалені, так і локальні порти, щоб ви могли це зробити так, щоб все було в зворотному порядку

EDIT

Якщо ви встановите ssh-сервер на клієнтському ПК та встановите його для прийому ssh-з'єднань на порт 443, тоді ви можете підключитися до ssh-сервера (свого клієнта) з вашого сервера (використовуючи підключення ssh-клієнта), і вам не потрібно відкривати будь-які порти ( 443 має бути відкритим для https)

Якщо ви використовуєте rdesktop на стороні клієнта (замість рідного клієнта Windows), ви можете використовувати rdp2tcp .
Це дозволяє керувати переадресацією портів TCP через з'єднання RDP.

Я не знайшов нічого кращого, ніж rdp2tcp для використання з Windows Server, який не дозволяв адміністратору доступу до мережі та інтерфейсу до інтерфейсу. Вам потрібно буде зробити патч OOP на своєму rdesktop, щоб це працювало (перейдіть на останні сторінки, щоб знайти ту, що відповідає останній версії rdesktop). Я використовував компілятор MinGW для складання Windows кінця тунелю.

Документація також відмінна і стисла.

Що може здатися незначним: Якщо ви використовуєте ім'я 'addin' з '-', rdesktop не зможе правильно проаналізувати командний рядок. Це, можливо, був башизм, який вимагав належного втечі, але я не впевнений.

Зауважте, що наскільки я можу зрозуміти, це не справжній тунель TCP, який "бачить" одиниці даних протоколу TCP, як це було б неможливо без прав адміністратора на стороні Windows. Це більше схоже на проксі-носок із заздалегідь налаштованою кінцевою точкою (але не дуже послідовно). Він також містить фактичний проксі-шкарпетки, якщо ви це хочете.

Я легко керував ним інтерактивним сеансом SSH, але він не витримував передачі файлів SSH (дав "віртуальний канал відключений" в консолі rdesktop (rdp2tcp працює як його дочірній процес із stdout / stdin dup2'ed / piped rdesktop , але без зміни на stderr)). У джерелі була константа під назвою RDP2TCP_PING_TIMEOUT, яка виглядала як очікуваний час очікування для утримування тунелю. Якщо припустити, що в проміжній мережі відбувається якесь перешкоджання, збільшивши це з 5-х до 900-х років, здавалося, було зроблено трюк, і воно витримало передачу в розмірі до 100 МБ (це займало близько 15 хвилин у цій конкретній мережі).

Крім того, було виявлено, що rdp2tcp отримує SIGPIPE, який він стверджував, що отримав через поломку трубки rdesktop, хоча я не міг знайти жодних доказів того, що відбувається ні з коду rdesktop, ні з результату ' lsof ', який не показав зміни кількості труб для rdesktop до і після тригера SIGPIPE.

Якщо це станеться, вам доведеться перезапустити rdesktop, а можливо, і тунельну сторону Windows. Ви можете використовувати rsync та відновити передачу файлів, а можливо, ви можете автоматизувати весь процес відновлення.

Все це передбачало Linux як ваш клієнт. Я не пробував виправлену rdesktop у Windows через деякі непов'язані проблеми, які виникли у Cygwin / X. Я думаю, це повинно працювати.

Також мій досвід був із SSH, але величезна передача файлів будь-якими іншими способами, ймовірно, торкнеться тих самих проблем.

Я думаю, ви можете використовувати переадресацію локального порту на RDP:

A -> B -> C

A - це Windows або Mac, B - Linux і C - це Windows. Якщо ви хочете, щоб RDP до C від A, а C не був доступний безпосередньо від A, тоді A

ssh username@B -L 7777:C:3389

Відкрийте клієнт RD, тоді вказуйте 127.0.0.1:7777, використовуйте ім'я користувача та пароль C. Я спробував це на Mac, але повинен працювати для Windows.