Как настроить подключение клиентов 1С через WireGuard без правки файла hosts

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

Разберем детально, почему так происходит, как устроен механизм соединения клиента с кластером серверов 1С:Предприятия и какие существуют надежные способы решения этой задачи без модификации системных файлов на клиентских рабочих станциях.

Почему указания IP-адреса в строке подключения недостаточно

Выясним причину такого поведения платформы. Проанализируем алгоритм установления соединения тонкого клиента с кластером 1С:

1. На первом этапе клиентское приложение обращается к менеджеру кластера по адресу, указанному в строке подключения (параметр Srvr="192.168.1.10" или Srvr="Srv1c").
2. Менеджер кластера принимает запрос, определяет, какой рабочий процесс на каком рабочем сервере будет обслуживать сеанс, и отправляет клиенту сетевой адрес целевого рабочего сервера.
3. Клиент закрывает первоначальный диалог с менеджером и инициирует новое подключение непосредственно к рабочему серверу по тому адресу, который ему вернул кластер.

Главная сложность заключается в том, что кластер серверов возвращает клиенту значение, записанное в параметре Компьютер рабочего сервера в консоли администрирования 1С. Если при первоначальной установке и развертывании кластера сервер был зарегистрирован по локальному имени хоста (например, Srv1c), менеджер кластера всегда будет возвращать клиенту именно строку Srv1c, даже если изначально клиент подключился по прямому IP-адресу 192.168.1.10.

В локальной сети имя Srv1c успешно разрешается с помощью широковещательных протоколов NetBIOS или LLMNR. Однако удаленный клиент, подключенный через туннель WireGuard с точечным маршрутом AllowedIPs = 192.168.1.10/32, не может использовать широковещательные пакеты. В результате клиентский компьютер не знает, какой IP-адрес соответствует имени Srv1c, и подключение завершается сетевой ошибкой.

Способ 1. Указание статического IP-адреса в свойствах рабочего сервера кластера

Рассмотрим самый простой и быстрый способ решения, не требующий развертывания дополнительных сетевых служб и изменения настроек на клиентских машинах.

Разберем по шагам, как перевести кластер на работу по прямому IP-адресу:

1. Откроем консоль Администрирование серверов 1С Предприятия на сервере.
2. Перейдем в ветку нашего центрального сервера, раскроем список Рабочие серверы.
3. Откроем свойства рабочего сервера.
4. В поле Компьютер вместо короткого сетевого имени хоста (например, Srv1c) пропишем его статический локальный IP-адрес: 192.168.1.10.
5. Нажмем кнопку применения настроек и сохраним изменения.

Посмотрим на результат: теперь при первичном подключении кластер возвращает рабочим станциям адрес 192.168.1.10. И локальные, и удаленные пользователи будут обращаться напрямую по IP-адресу, необходимость в разрешении имени через DNS, NetBIOS или файл hosts полностью отпадает.

Важное предостережение: сетевое имя самого компьютера в свойствах операционной системы Windows менять не требуется. Это критически важно, так как изменение сетевого имени компьютера или его основного DNS-суффикса приводит к изменению параметров привязки программных лицензий 1С (файлов с расширением .lic), что вызовет ошибку привязки и потребует повторной активации лицензии резервным пин-кодом.

Способ 2. Настройка доменного имени FQDN и Split DNS для туннеля WireGuard

Если в организации принято подключаться по буквенным доменным именам, проанализируем вариант с использованием полностью определенного имени домена (FQDN), например Srv1c.firma.ru.

При реализации данного варианта необходимо учитывать технические нюансы взаимодействия WireGuard и системных механизмов разрешения имен в Windows:

1. Защита от DNS Rebinding в публичных DNS: добавление записи вида Srv1c.firma.ru -> 192.168.1.10 на публичном DNS-хостинге может не сработать для удаленных пользователей. Большинство современных домашних маршрутизаторов (Keenetic, Mikrotik, OpenWrt, ASUS) по умолчанию блокируют ответы внешних DNS-серверов, содержащие серые IP-адреса локальных сетей (RFC 1918), расценивая это как сетевую атаку.
2. Маршрутизация DNS-запросов через туннель: если в параметрах WireGuard удаленного клиента указано AllowedIPs = 192.168.1.10/32, то клиент отправляет через VPN-туннель пакеты исключительно к самому серверу 1С. Запросы к внутреннему DNS-серверу (например, к роутеру 192.168.1.1) будут уходить мимо туннеля в интернет провайдера.

Чтобы корректно организовать работу по схеме Split DNS, выполним следующие настройки:

1. На корпоративном роутере локальной сети внесем статическую запись DNS: имя Srv1c.firma.ru сопоставим с адресом 192.168.1.10.
2. В конфигурационном файле WireGuard удаленного клиента в секции интерфейса укажем внутренний DNS-сервер: DNS = 192.168.1.1.
3. В секции пира расширим список разрешенных адресов, чтобы трафик к локальному DNS-серверу направлялся в туннель: AllowedIPs = 192.168.1.10/32, 192.168.1.1/32.
4. В консоли администрирования 1С изменим параметр Компьютер рабочего сервера на полное имя Srv1c.firma.ru.
5. В локальной сети настроим выдачу адреса корпоративного роутера в качестве первичного DNS-сервера через параметры DHCP, чтобы локальные рабочие станции также могли разрешать FQDN-имя без использования широковещательного NetBIOS.

Способ 3. Публикация базы на веб-сервере (HTTP/HTTPS)

Рассмотрим альтернативное решение, которое полностью исключает специфику взаимодействия кластера 1С с портами рабочих процессов и сетевыми именами.

Базу данных можно опубликовать на веб-сервере (Apache или IIS), развернутом непосредственно на сервере 1С. В этом случае тонкий клиент подключается к базе не по протоколу TCP кластера (порты 1540, 1541, 1560-1591), а по стандартному веб-протоколу через единственный веб-порт.

Разберем преимущества этого подхода:

1. Клиенту достаточно указать прямую веб-ссылку в строке подключения, например: http://192.168.1.10/Base2026.
2. Веб-сервер самостоятельно взаимодействует с кластером 1С локально на машине 127.0.0.1. Удаленный клиент вообще не взаимодействует с менеджером кластера напрямую и не получает внутренних сетевых имен.
3. Для работы WireGuard достаточно оставить правило AllowedIPs = 192.168.1.10/32, при этом через туннель будет проходить только веб-трафик (порты 80 или 443), что повышает безопасность и снижает требования к сетевым настройкам на стороне пользователя.

Сравнение вариантов и итоговые рекомендации

Проанализируем предложенные варианты и выделим оптимальный:

1. Если требуется решить задачу с минимальными трудозатратами за несколько минут — укажем IP-адрес 192.168.1.10 в поле Компьютер рабочего сервера в оснастке кластера 1С. Это избавит от необходимости редактировать файл hosts и не затронет программные лицензии платформы.
2. Если планируется масштабирование сети, защищенный веб-доступ или работа через браузер — настроим веб-публикацию базы данных через IIS или Apache.
3. Использование публичных DNS-записей для частных IP-адресов применять не рекомендуется из-за конфликтов со встроенными механизмами защиты клиентских роутеров (DNS Rebinding).