В частной сети есть удаленный сервер Windows, к которому я могу подключиться через Remote Desktop Connection. Я хотел бы иметь возможность устанавливать соединения TCP / IP со своего компьютера на другие компьютеры в сети этого сервера.
Подключение к удаленному рабочему столу позволяет совместно использовать принтеры, диски и другие локальные ресурсы через подключение. Есть ли способ «туннелировать» TCP / IP-соединение через RDC?
Я хотел бы что-то похожее на переадресацию портов, предоставляемую SSH. Я не вижу способа сделать это через RDC, но я надеюсь, что такая возможность есть, и я просто не знаю об этом.
remote-desktop
port-forwarding
Кристофер Джонсон
источник
источник
Если вы запускаете 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 - это Windows или Mac, B - это Linux, а C - это Windows. Если вы хотите, чтобы RDP к C из A и C не был напрямую доступен из A, то на A
Откройте клиент RD, затем укажите 127.0.0.1:7777, используя имя пользователя и пароль C. Я пробовал это с Mac, но должно работать для Windows.
источник