Зондирование порта для RDP

Question

Я использую туннель SSH для RDP в мой домашний компьютер ("дом").

Иногда программное обеспечение для туннелирования, работающее в домашних условиях, падает, и порт RDP перестает туннелироваться. Я попытался решить эту проблему, запланировав запуск сценария в домашних условиях каждые 15 минут, который запускает на моем маршрутизаторе команду «netstat -tln» и перезапускает программу туннелирования, если туннельный порт RDP больше не открыт.

К сожалению, иногда сбои таковы, что порт RDP остается открытым и принимает соединения, но не туннелирует трафик. Например, порт остается открытым в соответствии с netstat, и если я пытаюсь подключиться к порту через telnet, он подключается и показывает пустой экран. Если я пытаюсь выполнить RDP через туннель, сеанс подключается, но при этом отображается "Настройка удаленного сеанса".

Итог: я бы хотел, чтобы мой сценарий "сторожевого таймера" действительно пытался подключиться к порту RDP, чтобы определить, исправен ли туннель. Как вы исследуете порт, чтобы проверить, является ли он открытым портом RDP?

Я думаю, что идеальный тест на самом деле зондирование порта для RDP, но я также открыт для других идей.

Answer 1

Я выяснил простой способ сделать это. Когда мой скрипт выполняет команду netstat на маршрутизаторе, чтобы убедиться, что туннель RDP открыт, я также могу отправить запрос на соединение RDP через туннель, используя netcat !

Это команда, которую я использовал для отправки пакета запроса соединения. Я взял сам пакет из примера последовательности соединений в спецификации Microsoft RDP.

echo -ne '\x03\x00\x00\x2c\x27\xe0\x00\x00\x00\x00\x00'\
'Cookie: mstshash=eltons\r\n'\
'\x01\x00\x08\x00\x00\x00\x00\x00' |
nc -w 5 localhost 6000 |
xxd -p |
xargs -0 printf 'RDP response: %s\n'

Туннель проходит через порт 6000. Команда netcat имеет -w 5 поэтому соединение будет закрыто, если ответ не получен в течение 5 секунд. xxd преобразует его в простую шестнадцатеричную строку, и я префиксирую вывод xxd с помощью RDP response: так что мой сценарий может легко найти эту строку в выводе.

Если RDP-сервер прослушивает, я получу вывод, подобный этому.

RDP response: 030000130ed000001234000209080000000000

Единственная другая проверка, которую я делаю, - это поиск байта 02 со смещением 11, чтобы убедиться, что это пакет RDP, который включает в себя структуру TYPE_RDP_NEG_RSP (ответ согласования RDP).

Устранение сбоев было бы очевидным решением, но у меня был программный сбой туннелирования несколькими различными способами, и я не делал с ним ничего необычного. Я использую программное обеспечение BitVise SSH Client. Я использую последнюю версию, и с некоторым поиском Google я не нашел никого другого, у которого есть подобные проблемы. Это происходит сбой раз в несколько дней или недель, но это разочаровывает попытки RDP на мой компьютер, чтобы выяснить, что он не принимает соединения, и я ничего не могу с этим поделать, пока не вернусь домой.