← На главную

При попытке опубликовать сервер 1С:Предприятия в глобальной сети через обычный маршрутизатор с трансляцией сетевых адресов (NAT) администраторы часто сталкиваются с ситуацией, когда локально база открывается штатно, а удаленный клиент при попытке подключения по внешнему IP-адресу выдает ошибку вида: Не найдено ни одного сервера с размещенным сервисом serviceName=ClusterConfigService. Разберем по шагам архитектуру сетевого взаимодействия кластера 1С, выясним причину такого поведения и определим, как правильно организовать удаленный доступ.

Причина ошибки ClusterConfigService и назначение портов кластера

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

1. Порт 1540 (ragent): Агент сервера. Предназначен исключительно для взаимодействия с консолью администрирования кластера и управления фоновыми процессами операционной системы. Если клиентское приложение пытается подключиться напрямую к порту 1540 как к кластеру баз данных, оно получает отказ, так как служба ClusterConfigService на нем не размещается.
2. Порт 1541 (rmngr): Главный менеджер кластера. Именно к нему должно обращаться клиентское приложение при входе в информационную базу. Именно на менеджере кластера запущен сервис ClusterConfigService.
3. Диапазон портов 1560–1591 (rphost): Рабочие процессы кластера. Менеджер кластера распределяет пользовательские сеансы и фоновые задания по свободным рабочим процессам из этого диапазона.

Если для удаленного доступа пробросить на роутере только порт 1540, клиент не сможет инициализировать подключение к базе данных. Чтобы соединение состоялось, на маршрутизаторе необходимо открыть и пробросить весь спектр портов: 1540, 1541 и диапазон 1560–1591.

Почему нельзя подменять номера внешних портов (PAT)

Проанализируем частую попытку администраторов обезопасить подключение путем трансляции нестандартных внешних портов на внутренние (например, направить внешний 4541 на внутренний 1541). В случае с кластером 1С такая схема работать не будет.

Внутренний протокол 1С передает номера портов в теле служебных пакетов данных. Когда тонкий или толстый клиент связывается с менеджером кластера, менеджер возвращает клиенту список выделенных рабочих процессов rphost и конкретные номера портов, на которых они работают внутри локальной сети (например, 1561 или 1562). Клиентское приложение принимает эти данные и пытается открыть второе соединение строго по тем портам, которые ему сообщил сервер. Если на внешнем интерфейсе роутера открыт диапазон 4560–4591, а сервер передал стандартные 1560–1591, соединение будет немедленно разорвано. Проброс сетевых портов должен выполняться исключительно один к одному (внешний 1541 транслируется во внутренний 1541, а внешний диапазон 1560–1591 — во внутренний 1560–1591).

Проблема разрешения сетевых имен (DNS и NetBIOS)

Вторая ключевая проблема при прямом доступе через NAT — механизм маршрутизации сессий. Клиент обращается к серверу по IP-адресу, но менеджер кластера возвращает клиенту имя хоста (компьютера), зарегистрированного в свойствах рабочего сервера кластера (например, srv-1c). Удаленный клиент из интернета не имеет доступа к внутренней WINS/DNS-службе предприятия и не знает, какому IP-адресу соответствует полученное сетевое имя.

Рассмотрим способы решения этой проблемы:

1. Редактирование файла hosts на клиентском компьютере: В файл hosts на удаленной машине добавляется запись вида: [ВНЕШНИЙ_БЕЛЫЙ_IP] srv-1c. В этом случае удаленный клиент успешно преобразует полученное от кластера имя хоста в публичный адрес вашего шлюза.
2. Задание рабочего сервера через IP-адрес: В консоли администрирования кластера серверов 1С можно задать имя центрального сервера кластера не сетевым именем, а IP-адресом. В платформе 8.3 для этого создается новый рабочий сервер с IP-адресом в поле сетевого имени, на него переносятся требования назначения функционала, после чего старый узел удаляется. Однако если указать внешний IP-адрес, для работы локальных пользователей потребуется обязательная поддержка маршрутизатором технологии Hairpin NAT (NAT Loopback), чтобы внутренние запросы к публичному адресу корректно возвращались на локальный сервер.
3. Использование Split-DNS: Наиболее масштабируемый вариант без использования VPN. В консоли кластера сервер регистрируется под полным доменным именем (FQDN), например, 1c.company.local. Внутри локальной сети офисный DNS-сервер разрешает это доменное имя в локальный адрес (например, 192.168.1.100), а публичный DNS-провайдер в интернете связывает то же имя с внешним статическим IP-адресом роутера.

Специфика работы протокола 1С через интернет и безопасность

Если мы решаем оставить прямое подключение через интернет без туннелирования, важно учитывать эксплуатационные ограничения собственного протокола кластера:

1. Разрывы сессий роутерами (TCP Keep-Alive): Сетевые шлюзы часто принудительно закрывают таблицы трансляций неактивных соединений NAT через 5–15 минут отсутствия трафика. Если пользователь отошел от компьютера, роутер сбрасывает TCP-сессию, и 1С выдает ошибку «Удаленный хост принудительно разорвал существующее подключение» или «Сеанс отсутствует или удален». Чтобы этого избежать, на сервере и клиентах настраивают уменьшенные интервалы отправки сигналов проверки связи KeepAliveTime на уровне операционной системы.
2. Чувствительность к сетевым задержкам (RTT): Собственный бинарный RPC-протокол кластера разработан для быстрых локальных сетей (ping до 5 мс). При удаленной работе через интернет задержки выше 30–50 мс приведут к ощутимым зависаниям интерфейса в сравнении с локальной сетью.
3. Безопасность: Службы ragent, rmngr и rphost не содержат встроенных механизмов защиты от распределенных атак отказа в обслуживании (DDoS) и перебора портов. При прямом выводе портов в сеть рекомендуется настроить в кластере обязательное шифрование трафика (TLS) с выпуском сертификатов.

Альтернативные и рекомендуемые варианты организации доступа

Рассмотрим, какие технологии предпочтительнее использовать вместо прямого проброса диапазона портов 1540–1591:

1. Публикация через веб-сервер (Apache / IIS): Оптимальный выбор при наличии тонкого клиента. На сервере поднимается веб-сервер, на котором публикуется информационная база. На роутере открывается только один стандартный защищенный порт (HTTPS — 443). Тонкий клиент работает по оптимизированному HTTP-протоколу, потребляет минимальный объем трафика, а имя сервера перестает иметь значение для клиентских DNS.
2. Организация VPN-соединения: Позволяет объединить удаленное рабочее место и локальную сеть офиса в единое адресное пространство (например, посредством WireGuard, OpenVPN или IPsec/L2TP). Это решает проблему безопасности, устраняет необходимость проброса десятков открытых портов наружу и делает доступ к именам компьютеров прозрачным для внутренней DNS-зоны.