При администрировании серверов 1С:Предприятие системные администраторы часто разворачивают несколько параллельных служб на одном физическом сервере (или виртуальной машине). Это необходимо для тестирования новых релизов, разделения сред разработки и продакшена или поддержки устаревших конфигураций. Обычно для второй службы выделяют альтернативный диапазон портов (например, вместо стандартных 15xx используют 16xx).
Однако при обновлении платформы (например, при переходе с очень старых версий вроде 8.3.6 на современные релизы ветки 8.3.15 и выше) администраторы сталкиваются с загадочным поведением: тонкие клиенты и Конфигуратор внезапно отказываются подключаться к информационной базе по старому порту 1640, выдавая ошибку «нет такого сервера:порт», но при этом всё мгновенно начинает работать, если изменить порт подключения на 1641. Проанализируем, почему так происходит, и разберем внутреннее устройство сетевых механизмов платформы 1С.
Для понимания сути проблемы нам необходимо детально разобрать роли сетевых портов, которые выделяются для работы сервера 1С. По умолчанию при установке службы резервируется определенный диапазон портов. Если мы разворачиваем второй (параллельный) сервер, мы сдвигаем этот диапазон. В рассматриваемом случае порты были сдвинуты на 100 позиций вверх — с диапазона 15xx на 16xx. Распределим их по ролям:
ragent.exe): по умолчанию имеет номер 1540 (в нашей параллельной службе — 1640). Этот порт предназначен исключительно для служебных целей службы агента: запуск процессов, сбор статистики, координация работы кластера и подключение утилит администрирования (таких как консоль MMC или утилита RAS). Он не предназначен для прямой маршрутизации пользовательских сессий в базу данных.rmngr.exe): по умолчанию имеет номер 1541 (в нашей параллельной службе — 1641). Именно на этом порту разворачивается служба конфигурации кластера (ClusterConfigService). Этот порт является единственной официальной и легитимной «входной дверью» для всех клиентских подключений (будь то Конфигуратор, тонкий или толстый клиент).rphost.exe): по умолчанию занимает диапазон 1560-1591 (в нашей службе — 1660-1691). Здесь живут сами сеансы пользователей и исполняется программный код.Рассмотрим ситуацию, которая существовала до обновления. В старых релизах платформы 1С (особенно в ветках 8.3.5–8.3.8) механизмы сетевого взаимодействия были спроектированы гораздо более «лояльно» к неточностям настройки.
Если администратор при регистрации базы в списке информационных баз ошибочно указывал порт агента сервера (1640) вместо порта менеджера кластера (1641), происходило следующее:
1640.ragent.exe, принимая этот запрос, понимал, что клиент пытается подключиться к конкретной информационной базе.1641 или сразу возвращал клиенту адрес свободного рабочего процесса rphost.exe из диапазона рабочих портов.Таким образом, пользователи годами работали с некорректно прописанными портами в строке подключения, даже не подозревая, что конфигурация сети выполнена с ошибкой. Платформа просто «прощала» эту опечатку.
С выходом новых версий технологической платформы фирма «1С» проделала колоссальную работу по оптимизации сетевой безопасности, отказоустойчивости и производительности клиент-серверного взаимодействия. Архитектура претерпела серьезные ужесточения:
Устранение небезопасной переадресации. В целях безопасности и изоляции процессов механизмы «попутной» маршрутизации трафика между агентом сервера и менеджером кластера были полностью упразднены. Теперь роли разделены жестко. Если клиентское приложение пытается постучаться на порт агента (1640) с запросом на открытие сессии базы данных, процесс ragent.exe просто отклоняет этот запрос как нецелевой. Он больше не занимается «самодеятельным» перенаправлением пакетов.
Различие в поведении Конфигуратора и Предприятия. Как заметил автор темы, при некорректном порте «Предприятие» иногда все-таки умудрялось запустить сессию, тогда как «Конфигуратор» категорически отказывался работать. Это объясняется особенностями кэширования сетевых путей. Тонкий клиент 1С:Предприятия при определенных настройках может использовать ранее сохраненные в локальном кэше данные маршрутизации (адреса конкретных rphost.exe) или существующие открытые сессии. Конфигуратор же устроен гораздо строже: при каждом запуске он выполняет глубокую проверку метаданных, пытается монопольно захватить таблицы конфигурации и требует прямого авторизованного соединения с ClusterConfigService на порту менеджера кластера (1641). При отсутствии прямого доступа к менеджеру Конфигуратор сразу аварийно завершает работу.
Чтобы избежать подобных проблем при обновлении платформы на серверах с нестандартными портами, разберем по шагам правильный алгоритм действий.
Шаг 1. Анализ строки запуска службы в реестре Windows. Откроем редактор реестра и проверим параметры запуска службы сервера 1С. Путь в реестре:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent (имя вашей службы)
Обратим внимание на параметр ImagePath. Шаблон запуска для параллельного сервера должен выглядеть следующим образом:
"C:\Program Files\1cv8\8.3.15.1656\bin\ragent.exe" -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d "C:\ProgramData\1C\1cv8"
В этой строке запуска четко определены роли портов:
-port 1640 указывает порт самого агента.-regport 1641 указывает порт главного менеджера кластера, который будет создан по умолчанию.-range 1660:1691 выделяет диапазон под рабочие процессы.Шаг 2. Корректировка настроек подключения на клиенте. Проанализируем строку подключения информационной базы в списке баз у пользователей (в файле ibases.v8i или в окне запуска).
Если ранее строка подключения выглядела так:
SRVR="имя_сервера:1640";Ref="имя_базы";
То ее необходимо в обязательном порядке отредактировать, указав порт менеджера кластера:
SRVR="имя_сервера:1641";Ref="имя_базы";
Если порт опущен вовсе (например, указано просто SRVR="имя_сервера"), то платформа по умолчанию попытается подключиться к порту 1541. Для параллельного сервера явное указание альтернативного порта менеджера (1641) является строго обязательным.
Шаг 3. Проверка доступности портов через брандмауэр. Убедимся, что сетевой экран (брандмауэр Windows или внешний файрвол) не блокирует порт 1641. Часто администраторы открывают только порт агента 1640, забывая про порт менеджера и диапазон рабочих процессов. Для быстрой диагностики из командной строки клиента можно воспользоваться утилитой PowerShell:
Test-NetConnection -ComputerName имя_сервера -Port 1641
Если статус проверки возвращает значение TcpTestSucceeded : True, значит, сетевой уровень настроен корректно.
Напоследок зафиксируем важный нюанс: при автоматическом обновлении платформы с помощью штатного дистрибутива установщик 1С может полностью перезаписать параметры службы в реестре Windows, сбросив их на дефолтные значения (порт 1540 и 1541).
Если это произойдет, ваша параллельная служба попытается запуститься на стандартных портах и вступит в конфликт с основной (рабочей) службой 1С. Всегда контролируйте значение параметра ImagePath в реестре после проведения инсталляционных работ и запускайте утилиту настройки параметров службы заново при необходимости.
Подведем итог: никакой мистики в поведении сервера не было. Новая платформа 8.3.15 лишь заставила администраторов исправить старую методологическую ошибку настройки и привела сетевые соединения к строгим стандартам безопасности 1С.