Вопрос или проблема
Среда: Все контроллеры домена и серверы-члены работают под управлением Windows Server 2019. Функциональный уровень леса/домена AD — 2016. Учетные записи защищены с использованием PKI/смарт-карт.
У меня возникают проблемы с серверами в сети — вход через RDP периодически не удается. Сразу после перезагрузки RDP работает. Через пару часов вход через RDP снова не удается, а через некоторое время начинает работать опять.
В журнале безопасности на контроллерах домена (у контроллеров домена также есть эта проблема) отображается успешный вход для пользователя, пытающегося подключиться через RDP. Журнал Operational Log службы Remote Desktop Services-RdpCoreTS показывает отключение по «причине 14».
Последовательность событий в журнале RDP выглядит следующим образом:
- Событие 131 – Сообщение: Сервер принял новое TCP соединение от клиента
- Событие 65 – Сообщение: Создано соединение RDP-Tcp#3
- Событие 72 – Сообщение: Вызван метод интерфейса: Подготовка к принятию
- Событие 72 – Сообщение: Вызван метод интерфейса: Отправка данных политики
- Событие 141 – Сообщение: Начата сессия PerfCounter с идентификатором экземпляра 3
- Событие 142 (ПРЕДУПРЕЖДЕНИЕ) – Сообщение: Операция TCP Socket READ завершилась неудачей, ошибка 64
- Событие 226 (ПРЕДУПРЕЖДЕНИЕ) – Сообщение: RDP_TCP: Ошибка при переходе из StateUnknown в ответ на Event_Disconnect (код ошибки 0x80070040)
- Событие 72 – Сообщение: Вызван метод интерфейса: OnDisconnected
- Событие 102 – Сообщение: Сервер завершил основное RDP соединение с клиентом
- Событие 145 – Сообщение: За время этого соединения сервер не отправил данные или обновление графики в течение 0 секунд (Idle1: 0, Idle2: 0)
- Событие 148 – Сообщение: Канал rdpinpt был закрыт между сервером и клиентом на транспортном туннеле: 0.
- Событие 148 – Сообщение: Канал rdpcmd был закрыт между сервером и клиентом на транспортном туннеле: 0.
- Событие 148 – Сообщение: Канал rdplic был закрыт между сервером и клиентом на транспортном туннеле: 0.
- Событие 103 – Сообщение: Причина отключения – 14
Что я пробовал:
- Перезапускать службы по одной и пытаться войти в систему
- Отключить службу NLA через изменение реестра
- Проверить kerberos, так как я вижу события Security-Kerberos в системном журнале. Эти события показывают попытку использования SPN “ldap/
<domain fqdn>” и “ldap/localhost”, но эти события появляются еще до попытки входа, так что, вероятно, это ложный след - Проверить настройки локальной политики в разделе RD Session Host, включив “Требовать использования определенного уровня безопасности для RDP соединений” и установив его на “RDP”
- Отключить UDP через изменение реестра в HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services\Client”
- Другие изменения реестра под этим же ключом реестра
- Пробовал учетные записи с именем пользователя и паролем, но безуспешно
Надеюсь, кто-нибудь здесь сможет помочь.
Ответ или решение
Теория:
Проблема с прерыванием работы удаленного рабочего стола (RDP) является достаточно распространенной в корпоративных средах и требует детального анализа как программных, так и сетевых аспектов. В описанной ситуации, где RDP работает после перезагрузки, а затем перестает функционировать через несколько часов, сразу бросается в глаза, что проблема может быть связана с сетевой конфигурацией, настройками безопасности, или может указывать на ошибки в конфигурации служб или драйверов. RDP протокол корректно обрабатывает подключения при старте, и это показывает, что глубинные программные ошибки маловероятны, но возможность конфликтов с определёнными службами или политиками не исключена. Регулярные неудачи при повторных попытках указывают на то, что что-то изменяется в состоянии системы или сети, что приводит к сбоям в работе RDP.
Примеры:
На основании предоставленных логов и сообщения об ошибке "reason 14" (означает разрыв подключения по причине таймаута поддержания соединения), возможно, что проблема кроется в политиках сетевой безопасности или неправильно настроенном мониторинге активности. Сетевые устройства могут автоматически выполнять операции блокировки или сброса сессий, основываясь на перерывах в передаче данных.
Событие 142 и ошибка TCP Socket READ с кодом 64 свидетельствуют о непредвиденной сетевой ошибке, которая, как правило, связана с проблемами на нижнем уровне TCP/IP или с нехваткой ресурсов для обработки входящих соединений. Это может происходить, если службы RDP сталкиваются с превышением или исчерпанием лимитов соединений или ресурсов.
Общие причины возникновения подобных ситуаций:
- Некорректные или устаревшие политики групповой политики, особенно касающиеся безопасности, сетевых настройках и контроля доступа.
- Неоптимальные политики таймаута соединения, установленные на уровне сервера или сети.
- Проблемы с сертификатами и аутентификацией, особенно в средах с использованием PKI/smartcard.
Применение:
Предлагаем пошаговый подход для решения проблемы:
-
Проверка и настройка сетевых параметров:
- Убедитесь, что сетевые соединения, особенно на маршрутизаторах и коммутаторах, не подвержены таймаутам или блокировкам при отсутствии активности.
- Проверьте максимальное количество подключений и установите соответствующие пределы.
-
Анализ и корректировка настроек безопасности:
- Перепроверьте настройки групповой политики в Active Directory и сетевой политики, обеспечивающие удалённый доступ. Убедитесь, что политики не накладывают излишние ограничения на сессии RDP.
- Переустановите или обновите сертификаты, связанные с PKI/smartcard, так как истекающие или некорректно настроенные сертификаты могут стать причиной неудач аутентификации.
-
Мониторинг и логирование:
- Включите более детализированный мониторинг RDP и сетевой активности для уточнения диагноза проблемы.
- Рассмотрите возможность использования инструментов диагностики, таких как Wireshark, для анализа пакетов, чтобы выявить какие пакеты или процессы вызывают разрыв соединения.
-
Обновление и проверка актуальности ПО:
- Проверьте актуальность обновлений для всех компонентов, включая драйверы сетевых интерфейсов и сервисы Windows.
- Примените последние патчи и апдейты, которые могут содержать исправления ошибок, влияющих на работу RDP.
-
Тестирование с изменением конфигурации:
- Испытайте изменение конфигураций, таких как отключение специфических компонентов, сохраняющих состояние сессий, чтобы изолировать и выявить причину проблемы.
Ваши попытки с изменением реестра и отключением UDP уже показывают, что вы на правильном пути, но проблема может потребовать более глубокого анализа как на уровне настроек, так и на уровне взаимодействий компонентов сети. Если применение всех вышеперечисленных шагов не приносит результаты, может потребоваться консультация со специалистами в области сетевых технологий или с технической поддержкой Microsoft для проведения полноценного аудита и нахождения специализированного решения.