Туннелирование соединения TCP / IP через подключение к удаленному рабочему столу

В частной сети есть удаленный сервер Windows, к которому я могу подключиться через Remote Desktop Connection. Я хотел бы иметь возможность устанавливать соединения TCP / IP со своего компьютера на другие компьютеры в сети этого сервера.

Подключение к удаленному рабочему столу позволяет совместно использовать принтеры, диски и другие локальные ресурсы через подключение. Есть ли способ «туннелировать» TCP / IP-соединение через RDC?

Я хотел бы что-то похожее на переадресацию портов, предоставляемую SSH. Я не вижу способа сделать это через RDC, но я надеюсь, что такая возможность есть, и я просто не знаю об этом.

Я не думаю, что вы можете туннелировать через RDP, однако, если вы захотите выполнить rdp к серверу и затем запустить ssh-туннель обратно к вашему клиенту, ваши машины будут подключены через ssh. Вы можете пересылать как удаленные, так и локальные порты, чтобы вы могли сделать все наоборот

РЕДАКТИРОВАТЬ

Если вы устанавливаете ssh-сервер на своем клиентском компьютере и настраиваете его на прием ssh-соединений через порт 443, то вы можете подключиться к ssh-серверу (вашему клиенту) со своего сервера (используя ssh-клиентское соединение), и вам не нужно открывать какие-либо порты 443 должен быть открыт для https)

Если вы запускаете rdesktop на стороне клиента (вместо собственного клиента Windows), вы можете использовать rdp2tcp .
Это позволяет вам управлять переадресацией портов TCP через соединение RDP.

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

Документация также отличная и лаконичная.

Что может показаться незначительным: если вы используете имя 'addin' с '-', rdesktop не сможет правильно проанализировать командную строку. Возможно, это был башизм, который требовал надлежащего побега, но я не уверен.

Обратите внимание, что, насколько я понимаю, это не «настоящий» туннель TCP, который «видит» блоки данных протокола TCP, поскольку это было бы невозможно без прав администратора на стороне Windows. Это больше похоже на прокси-сервер socks с конечной точкой, которая предварительно сконфигурирована (хотя и не очень важна). Это также показывает фактический прокси носков, если вам это нравится.

Я легко управлял с ним интерактивным SSH-сеансом, но он не выдерживал передачу файлов SSH (дал «виртуальный канал отключен» в консоли rdesktop (rdp2tcp запускается как дочерний процесс с stdout / stdin dup2'ed / piped by 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.