Как настроить доступ к серверу 1С:Предприятие из разных подсетей?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Ситуация, когда сервер 1С (особенно под управлением Linux и PostgreSQL) доступен внутри своей подсети, но отказывается принимать подключения от клиентов из других сегментов сети, является классической задачей для системного администратора. На первый взгляд кажется, что если telnet на порт 3541 проходит, то и тонкий клиент должен работать, но в архитектуре 1С скрыто несколько важных нюансов. Давайте подробно разберем, почему так происходит и как заставить систему работать стабильно.

Разберем механизм подключения клиента к кластеру

Для начала проанализируем, как именно происходит установка соединения. Когда мы указываем в строке подключения адрес 10.10.1.5:3541, происходит следующее:

  1. Тонкий клиент обращается к менеджеру кластера по указанному IP-адресу и порту.
  2. Менеджер кластера принимает запрос, определяет, в какой базе хочет работать пользователь, и выбирает свободный рабочий процесс.
  3. Важный момент: Менеджер кластера передает клиенту ответ, в котором содержится сетевое имя (Hostname) сервера и номер порта рабочего процесса (например, ALT005:3562).
  4. Клиент получает этот ответ и пытается установить новое соединение, используя именно полученное имя хоста ALT005.

Если на компьютере пользователя имя ALT005 не разрешается в IP-адрес 10.10.1.5, то соединение обрывается с ошибкой "Сервер не доступен", даже если первый этап прошел успешно.

Решение 1: Настройка разрешения имен через файл hosts

Поскольку в разных подсетях механизмы автоматического обнаружения имен (NetBIOS) часто не работают, нам необходимо обеспечить корректный резолвинг имен вручную или через DNS. Рассмотрим, как правильно прописать данные в файл hosts.

На клиентской машине (Windows) откроем блокнот от имени администратора и отредактируем файл по пути: C:\Windows\System32\drivers\etc\hosts. Добавим туда строку:

10.10.1.5 ALT005

Теперь проанализируем настройки самого сервера на Linux. Файл /etc/hosts на сервере также играет критическую роль. Часто там встречается запись:

127.0.1.1 ALT005

Если сервер видит себя как 127.0.1.1, он может передать этот адрес клиенту. В результате клиент из другой подсети попытается подключиться к самому себе (на свой localhost) и получит ошибку. Обязательно исправим это, сопоставив имя сервера с его реальным сетевым адресом:

10.10.1.5 ALT005

Решение 2: Открытие полного диапазона портов

Выясним причину, по которой telnet на один порт работает, а база — нет. Как мы уже выяснили, менеджер кластера лишь координирует работу, а основные данные передаются через рабочие процессы. Для каждого рабочего процесса 1С динамически выделяет порты из заданного диапазона.

Стандартные порты 1С (если база одна и настройки типовые):

В вашем случае используется нестандартный порт 3541. Это означает, что весь диапазон смещен. Проанализируем настройки вашего роутера: если вы пробросили только порт 3541, то клиент не сможет достучаться до рабочих процессов. Вам необходимо открыть (пробросить между подсетями) следующий список портов:

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

Решение 3: Проверка MTU и фрагментации пакетов

Если порты открыты и имена резолвятся, но соединение все равно нестабильно или обрывается при попытке открыть тяжелый отчет, проанализируем параметр MTU (Maximum Transmission Unit). При передаче трафика между подсетями через маршрутизаторы или VPN-туннели пакеты могут фрагментироваться.

Попробуем выполнить диагностику командой ping с запретом фрагментации:

ping -f -l 1472 10.10.1.5

Если вы получаете сообщение "Требуется фрагментация пакета, но установлен флаг DF", это означает, что сетевое оборудование на пути не может пропустить стандартный пакет 1500 байт. В этом случае стоит либо уменьшить MTU на сетевых интерфейсах, либо настроить MSS clamping на роутере.

Решение 4: Настройка параметров TCP Keep-Alive

Рассмотрим ситуацию, когда соединение устанавливается, но "отваливается" через некоторое время простоя. Межсетевые экраны (Firewalls) между подсетями часто закрывают сессии, по которым долго не передавались данные. 1С может держать соединение открытым, ожидая действий пользователя.

Для Linux-сервера рекомендуется настроить параметры ядра, чтобы он чаще проверял активность соединения:


sysctl -w net.ipv4.tcp_keepalive_time=600
sysctl -w net.ipv4.tcp_keepalive_intvl=60
sysctl -w net.ipv4.tcp_keepalive_probes=20

Это заставит сервер отправлять контрольные пакеты, которые не дадут роутеру закрыть сессию по таймауту.

Итоги и рекомендации

Для успешного подключения 1С из другой подсети выполним следующие шаги:

  1. Убедимся, что на клиенте прописан hosts: IP-адрес Имя-сервера.
  2. Проверим, что на Linux-сервере в /etc/hosts имя сервера привязано к внешнему IP, а не к 127.0.1.1.
  3. Откроем на маршрутизаторе не только порт 3541, но и весь диапазон портов рабочих процессов (обычно 3560–3591).
  4. Если используется авторизация Windows (хотя для Linux это реже), убедимся в доступности контроллера домена из обеих подсетей.

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

← На главную