В практике системного администрирования часто возникает ситуация: в локальной сети развернуто несколько терминальных серверов (ТС), и все они прекрасно работают для внутренних пользователей. Однако при попытке опубликовать их для удаленной работы через прокси-сервер или шлюз с NAT, один из серверов упорно отказывается принимать внешние подключения. При этом пинги проходят, логи прокси показывают успешную переадресацию пакетов, но клиент получает ошибку по таймауту.
В данной статье мы подробно разберем, почему так происходит, проанализируем влияние сетевых маршрутов и рассмотрим специфические настройки Windows Server 2008 R2, которые могут блокировать внешний RDP-трафик.
Рассмотрим ситуацию, описанную специалистами: пакет от внешнего пользователя поступает на прокси-сервер, который выполняет маппинг порта (трансляцию) и отправляет запрос на целевой терминальный сервер. Логи прокси подтверждают, что пакет ушел в сторону сервера, но ответ не возвращается.
Выясним причину такого поведения. Чаще всего проблема кроется в асимметричной маршрутизации. Это ситуация, когда пакет приходит на сервер по одному пути (через прокси-шлюз), а сервер пытается отправить ответ по другому пути. Проанализируем, как это происходит:
Для решения этой проблемы необходимо проверить таблицу маршрутизации на проблемном сервере. Выполним команду в командной строке:
route print
Проанализируем вывод. Если мы видим статические маршруты в колонке "Постоянные маршруты" (Persistent Routes), которые не соответствуют текущей топологии сети, их следует удалить. Для удаления маршрута используем команду:
route delete [адрес_сети]
Как показывает практика, удаление лишних статических маршрутов часто мгновенно восстанавливает работоспособность внешних подключений.
Если с маршрутами всё в порядке, нам следует проверить базовые настройки сетевого интерфейса. Важно убедиться, что на проблемном сервере Default Gateway (шлюз по умолчанию) указан именно тот сервер (прокси/роутер), который занимается публикацией RDP во внешнюю сеть.
Разберем по шагам диагностику интерфейса:
Для операционной системы Windows Server 2008 R2 характерны проблемы с технологиями разгрузки сетевого стека. Эти функции призваны ускорить работу сети, перекладывая обработку пакетов на сетевую карту, но при работе через NAT и прокси они часто вызывают сбои в протоколе RDP.
Рассмотрим подробнее функции TCP Chimney Offload и Receive Side Scaling (RSS). При возникновении странных проблем с подключением (соединение устанавливается и тут же рвется, или не устанавливается вовсе только извне), рекомендуется принудительно отключить эти функции.
Для этого выполним следующие команды от имени администратора:
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global netdma=disabled
После выполнения этих команд обработка сетевых пакетов будет полностью производиться центральным процессором, что исключит ошибки, связанные с драйверами сетевых карт и некорректной обработкой фрагментированных пакетов.
При прохождении трафика через прокси-серверы, VPN-туннели или сложные маршруты, к пакету могут добавляться дополнительные заголовки. Если размер пакета превышает стандартный MTU 1500, пакет должен быть фрагментирован. Если на каком-то узле фрагментация запрещена, пакет будет отброшен.
Посмотрим на ситуацию со стороны сервера. Мы можем попробовать немного снизить размер MTU на интерфейсе терминального сервера, чтобы пакеты гарантированно проходили через любые шлюзы без фрагментации. Установим значение 1450 или 1400:
netsh interface ipv4 set subinterface "Local Area Connection" mtu=1400 store=persistent
Важно: замените "Local Area Connection" на реальное имя вашего сетевого интерфейса.
В современных версиях RDP (начиная с обновления для 2008 R2 до версий 8.0 и 8.1) протокол старается использовать не только TCP 3389, но и UDP 3389 для улучшения отклика. Если на вашем прокси-сервере проброшен только TCP-порт, а клиент пытается инициировать соединение через UDP, это может вызвать задержки на этапе согласования сессии.
Проанализируем настройки прокси: убедитесь, что правила трансляции включают оба протокола — и TCP, и UDP. Если ваш прокси не поддерживает UDP для RDP, можно принудительно заставить сервер использовать только TCP через групповые политики или реестр.
В случае, если на сервере установлено несколько сетевых адаптеров, служба TermService (Службы удаленных рабочих столов) может быть жестко привязана к определенному адресу. Если запрос от прокси приходит на интерфейс, который служба "не слушает", соединения не будет.
Проверим это через оснастку tsconfig.msc (Конфигурация узла сеансов удаленных рабочих столов):
Подводя итог, можно сказать, что решение сетевых проблем с терминальными серверами всегда требует комплексного подхода: от простой проверки маршрутов командой route print до тонкой настройки сетевого стека через netsh. Совместный анализ логов прокси-сервера и таблицы маршрутизации самого ТС позволяет быстро выявить и устранить "узкие места" в инфраструктуре.