Я не нашел ничего лучше, чем 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, но огромные передачи файлов любым другим способом, вероятно, столкнутся с теми же проблемами.
