Как открыть порты на сервере 1С для работы клиентов и веб-доступа

Для работы клиент-серверной 1С недостаточно установить сервер предприятия и СУБД — между ними и клиентскими машинами должны быть открыты сетевые порты. Если брандмауэр блокирует трафик, пользователи получают ошибки вида «Ошибка соединения с сервером 1С:Предприятие» или «server_addr=... descr=... 10061», хотя сама служба агента сервера работает исправно.

По умолчанию сервер 1С использует диапазон портов 1540–1591: порт 1540 обслуживает агент сервера, 1541 — менеджер кластера, 1560–1591 — рабочие процессы (rphost). Дополнительно могут понадобиться порты 1545 (отладка), 1433 или 5432 для SQL Server и PostgreSQL, 80/443 для веб-доступа через публикацию базы. Какие именно порты открывать, зависит от вашей схемы развертывания.

Ниже разобрано, как определить нужные порты, открыть их в брандмауэре Windows Server и в Linux, а также как проверить, что подключение действительно проходит. Отдельно рассмотрены типичные ошибки, из-за которых даже правильно написанные правила не дают результата.

Какие порты использует сервер 1С

Прежде чем создавать правила, нужно понять, какие компоненты участвуют в обмене данными. Агент сервера 1С (процесс ragent) слушает порт 1540 — через него клиенты получают начальную информацию о кластере. Менеджер кластера (rmngr) работает на порту 1541. Рабочие процессы rphost, которые непосредственно обслуживают сеансы пользователей, занимают порты из диапазона 1560–1591.

Если используется отладка по TCP, дополнительно нужен порт 1550 (и диапазон портов отладки, настраиваемый в свойствах кластера). Для сервера администрирования RAS, через который работает консоль кластера с другой машины или утилита rac, по умолчанию используется порт 1545.

Отдельная группа — порты СУБД. Microsoft SQL Server по умолчанию слушает TCP 1433 (плюс UDP 1434 для Browser, если используются именованные экземпляры), PostgreSQL — 5432. Эти порты открываются на сервере СУБД, и доступ к ним нужен только с сервера 1С, а не с клиентских машин.

Как определить, какие порты реально слушает сервер

Диапазоны по умолчанию можно изменить при установке или в свойствах кластера, поэтому перед настройкой брандмауэра полезно проверить фактическое состояние. На Windows выполните в командной строке от имени администратора команду netstat -ano | findstr LISTENING и найдите процессы ragent, rmngr и rphost по их PID (PID сопоставляется с процессом через Диспетчер задач).

На Linux используйте ss -tlnp | grep -E "ragent|rmngr|rphost" — команда покажет адреса и порты, которые слушают процессы сервера 1С. Если порт отличается от стандартного, именно его нужно указать в правилах брандмауэра.

netstat -ano | findstr LISTENING | findstr "1540 1541 1560"

Также проверьте настройки кластера в консоли администрирования серверов 1С: в свойствах кластера виден порт агента, а в свойствах рабочего сервера — диапазон портов рабочих процессов. Если диапазон сужен (например, 1560–1570), достаточно открыть только его.

Открытие портов в брандмауэре Windows Server

На Windows Server откройте «Брандмауэр Защитника Windows в режиме повышенной безопасности» (команда wf.msc). Перейдите в раздел «Правила для входящих подключений» и выберите «Создать правило». Тип правила — «Для порта», протокол TCP, затем укажите порты: 1540,1541,1545,1560-1591. Действие — «Разрешить подключение», профили — обычно «Доменный» и «Частный» (публичный профиль для сервера 1С использовать не рекомендуется).

Ту же задачу можно выполнить одной командой PowerShell, что удобно при настройке нескольких серверов:

New-NetFirewallRule -DisplayName "1C Server" -Direction Inbound -Protocol TCP -LocalPort 1540,1541,1545,1560-1591 -Action Allow -Profile Domain,Private

Альтернативный подход — создать правило не по портам, а по программе: разрешить входящие подключения для исполняемых файлов ragent.exe, rmngr.exe и rphost.exe из каталога установки 1С. Такое правило переживёт смену портов, но при обновлении платформы путь к файлам может измениться, и правило придётся пересоздавать.

Открытие портов в Linux

На дистрибутивах с firewalld (CentOS, RHEL, Rocky Linux) порты открываются командами firewall-cmd. Укажите зону (обычно public) и не забудьте флаг --permanent, иначе правило исчезнет после перезагрузки:

firewall-cmd --permanent --add-port=1540-1591/tcp && firewall-cmd --reload

В Debian и Ubuntu чаще используется ufw: sudo ufw allow 1540:1591/tcp. Если брандмауэр настроен напрямую через iptables, добавьте правило вида iptables -A INPUT -p tcp --dport 1540:1591 -j ACCEPT и сохраните конфигурацию штатным для вашего дистрибутива способом (iptables-persistent, netfilter-persistent).

Учтите, что на Linux-сервере PostgreSQL по умолчанию слушает только localhost. Чтобы сервер 1С на другой машине мог подключиться, нужно не только открыть порт 5432 в брандмауэре, но и изменить параметр listen_addresses в postgresql.conf и добавить разрешающую строку в pg_hba.conf. Без этого порт будет формально открыт, но СУБД соединение отклонит.

Ограничение доступа по IP и безопасность

Открывать порты сервера 1С «всем» — плохая практика, особенно если сервер имеет внешний адрес. В правиле брандмауэра Windows на вкладке «Область» укажите удалённые IP-адреса или подсети, которым разрешено подключение: например, только локальную сеть офиса 192.168.0.0/24. В Linux аналогично ограничьте источник параметром -s в iptables или через rich rules в firewalld.

Для доступа через интернет правильнее использовать VPN-туннель до офисной сети, а не пробрасывать порты 1540–1591 наружу на роутере. Прямая публикация портов кластера в интернет делает сервер уязвимым для подбора паролей и эксплуатации уязвимостей платформы.

Проверка доступности портов

После создания правил проверьте результат с клиентской машины, а не с самого сервера — локальная проверка не покажет работу брандмауэра. В Windows удобнее всего PowerShell: Test-NetConnection server1c -Port 1540. Значение TcpTestSucceeded: True означает, что порт доступен.

Если Test-NetConnection показывает False, проверяйте по цепочке: запущена ли служба «Агент сервера 1С:Предприятия», слушает ли процесс нужный порт (netstat), активно ли правило брандмауэра и для того ли оно профиля (сервер мог получить профиль «Публичный» вместо «Доменный»), нет ли между клиентом и сервером промежуточного сетевого экрана или антивируса с собственным файрволом.

Типичные ошибки при настройке

Самая частая причина неудачи — правило создано, но для другого сетевого профиля. Сервер, не входящий в домен, часто работает в профиле «Публичный», а администратор создаёт правило для «Доменного». Вторая типичная ситуация — открыты только порты 1540 и 1541, но забыт диапазон рабочих процессов 1560–1591: клиент проходит начальное подключение и «падает» уже при запуске сеанса.

Ещё одна группа проблем — стороннее ПО: антивирусы с сетевым экраном, групповые политики домена, которые переопределяют локальные правила, и аппаратные файрволы между сегментами сети. Если правило в Windows создано корректно, а порт недоступен, временно включите журналирование отброшенных пакетов брандмауэра — в логе pfirewall.log будет видно, режет ли трафик именно Windows.

Частые вопросы