← На главную

В процессе администрирования корпоративной инфраструктуры терминальных серверов под управлением Windows Server 2008 R2 и более свежих версий системные администраторы нередко сталкиваются с ситуацией, когда штатный клиент «Подключение к удаленному рабочему столу» (mstsc) выдает ошибку: «Удаленному рабочему столу не удалось найти компьютер. Это может означать, что компьютер не принадлежит к указанной сети. Проверьте имя и домен компьютера, к которому выполняется подключение». При этом подключение по прямому IP-адресу сервера проходит моментально и без сбоев, а по полному доменному имени (FQDN) проблема проявляется периодически — то успешно подключается, то падает на нескольких клиентских станциях.

Выясним причину такого поведения сетевого стека и разберем по шагам надежные способы устранения неполадки.

Причина проблемы: сбои разрешения имен (DNS)

Поскольку соединение по IP-адресу устанавливается без задержек, сетевой уровень, маршрутизация, фильтрация портов брандмауэром и сама служба Remote Desktop Services функционируют штатно. Сбой локализован на уровне преобразования доменного имени в IP-адрес службой DNS на клиентском компьютере или контроллере домена Active Directory. Разберем ключевые факторы, приводящие к плавающему характеру ошибки:

1. Неправильная конфигурация DNS на сетевых картах клиентов: наличие второго внешнего DNS-сервера (роутера или провайдера) в свойствах адаптера.
2. Использование псевдодоменной зоны .local: конфликты со службами нулевой конфигурации ZeroConf / Bonjour / Avahi.
3. Кэширование отрицательных ответов DNS (Negative Caching): фиксация временных сбоев разрешения имен на клиенте.
4. Несколько сетевых интерфейсов на самом сервере: регистрация в DNS недоступных служебных IP-адресов.
5. Параллельные запросы через механизм Smart Multi-Homed Name Resolution: приоритет ответов от сторонних адаптеров или IPv6.

Шаг 1. Правильная настройка DNS в сети с Active Directory

Самая распространенная ошибка при развертывании доменной сети — указание на клиентских машинах внешних DNS-серверов (например, адреса роутера, 8.8.8.8 или DNS интернет-провайдера) в качестве вторичного адреса. Windows не использует альтернативный DNS как резервный при недоступности первого — клиент может отправлять запросы случайным образом на любой из указанных серверов. Внешний сервер ничего не знает о домене home.local и возвращает отрицательный ответ.

Рассмотрим правильную схему настройки:

1. На всех клиентских рабочих станциях (в параметрах сетевого адаптера или в пуле DHCP-сервера) укажем контроллер домена в качестве единственного DNS-сервера. Дополнительные адреса внешних DNS на клиентах должны отсутствовать.
2. Откроем оснастку управления dnsmgmt.msc на контроллере домена Active Directory.
3. В свойствах сервера DNS перейдем на вкладку «Серверы пересылки» (Forwarders).
4. Добавим адрес корпоративного интернет-шлюза (роутера) или надежные публичные DNS-серверы (например, провайдера).

В результате рабочие станции обращаются исключительно к доменному контроллеру: внутренние запросы к домену разрешаются напрямую локальной зоной, а внешние интернет-адреса прозрачно перенаправляются наружу через настроенные серверы пересылки.

Шаг 2. Нейтрализация конфликтов зоны .local и протокола mDNS

Проанализируем специфику доменного имени .local. Международный стандарт RFC 6762 закрепил суффикс .local за протоколом Multicast DNS (mDNS). Утилиты Apple Bonjour, службы сетевой печати, сетевые принтеры и служба Avahi в Linux перехватывают широковещательные запросы к зоне .local в широковещательном сегменте сети.

Если на клиентском ПК активны такие службы, они могут попытаться разрешить имя SERVER-RDP.home.local в обход DNS-сервера Active Directory через локальный широковещательный опрос. Не получив ответа от службы mDNS сервера, клиент прерывает попытку с ошибкой. Чтобы исключить эту проблему, необходимо проверить список запущенных служб на рабочих станциях, отключить неиспользуемые службы Bonjour/Avahi либо обеспечить приоритет unicast DNS в политиках ОС.

Шаг 3. Очистка и отключение кэширования отрицательных ответов DNS

Если в сети произошел единичный таймаут пакета или кратковременная недоступность контроллера домена, служба Dnscache в Windows кэширует ошибку разрешения имени (ответ NXDOMAIN). Из-за этого последующие подключения не проходят даже после восстановления доступности сервера вплоть до очистки кэша командой:

ipconfig /flushdns

Чтобы исключить длительные простои из-за негативного кэша, настроим на клиентских машинах параметр реестра, ограничивающий время жизни таких записей. В ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters создадим параметр MaxNegativeCacheTtl типа DWORD со значением 0 (кэширование ошибок отключено) или 5 (хранить ошибку не более 5 секунд).

Шаг 4. Проверка множественных сетевых интерфейсов на терминальном сервере

Проанализируем конфигурацию самого сервера Windows Server 2008 R2. Если на сервере терминалов установлено несколько сетевых адаптеров (например, основная сеть, интерфейс управления гипервизором, отдельная карта для резервного копирования или iSCSI), служба сетевого стека по умолчанию регистрирует IP-адреса всех активных адаптеров в DNS-зоне Active Directory.

В этом случае в оснастке DNS для одного имени SERVER-RDP будут существовать сразу несколько A-записей. Клиентские компьютеры по алгоритму Round-Robin получают разные адреса: при попадании на рабочий IP сессия RDP открывается, а при получении адреса изолированного сетевого интерфейса клиент выдает ошибку невозможности найти узел.

Разберем, как исправить эту ситуацию:

1. Откроем сетевые подключения на терминальном сервере.
2. В свойствах каждого вспомогательного адаптера выберем Протокол Интернета версии 4 (TCP/IPv4) -> Свойства -> Дополнительно -> вкладка DNS.
3. Снимем флажок «Зарегистрировать адреса этого подключения в DNS».
4. В оснастке DNS на контроллере домена вручную удалим некорректные A-записи с нерабочими адресами терминального сервера.
5. На терминальном сервере выполним принудительную перерегистрацию в командной строке с правами администратора:

ipconfig /registerdns

Шаг 5. Отключение Smart Multi-Homed Name Resolution и IPv6

Начиная с Windows 8 и Windows 10, операционная система использует механизм Smart Multi-Homed Name Resolution. Клиент отправляет DNS-запросы параллельно по всем интерфейсам (включая Wi-Fi, VPN и неактивные адаптеры) по протоколам IPv4 и IPv6. Если сторонний DNS отвечает быстрее с сообщением «Имя не найдено», система прекращает ожидание ответа от контроллера домена.

Для предотвращения конфликтов выполним настройку групповой политики: перейдем в редактор локальной или доменной политики gpedit.msc по пути Конфигурация компьютера -> Административные шаблоны -> Сеть -> DNS-клиент и включим политику «Отключить интеллектуальное разрешение имен на нескольких сетевых адаптерах». Если протокол IPv6 не настроен в локальной сети, снимем привязку компонента IPv6 на сетевых адаптерах клиентов и сервера.

Быстрое временное решение (Workaround)

Если диагностика сетевой топологии требует времени, а пользователям необходимо срочно восстановить доступ к 1С на терминале по привычному имени, временно пропишем статическое соответствие имени и IP-адреса на клиентских компьютерах в файле hosts. Откроем текстовый редактор от имени Администратора, отредактируем файл C:\Windows\System32\drivers\etc\hosts и добавим строку:

192.168.1.10 SERVER-RDP.home.local SERVER-RDP

Такой способ гарантирует немедленное разрешение имени, минуя сетевые сбои DNS, однако для постоянной работы корпоративной инфраструктуры необходимо реализовать базовую схему с единым доменным DNS и серверами пересылки.