Открытие портов для сервера 1С:Предприятия в Windows и Linux

Серверу 1С в клиент-серверном режиме нужны входящие TCP-порты 1540 (агент сервера), 1541 (главный менеджер кластера) и диапазон 1560-1591 для рабочих процессов. Если клиент выдаёт «Сервер не найден» или «Не удалось подключиться к серверу », а служба запущена, первым делом проверьте именно эти порты.

Открывать нужно только то, что действительно используется. Порты 1С не должны быть доступны из интернета: пользователям снаружи нужен VPN или публикация через веб-сервер. Ниже: что за что отвечает, как проверить текущее состояние, как открыть порты в Windows Server, в Linux и на роутере, и как не оставить дыр.

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

Порты по умолчанию, если вы ничего не меняли при установке:

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

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

Серверы СУБД (PostgreSQL, MS SQL) открывать для пользователей не нужно: к базе данных ходит только сервер 1С. Если СУБД стоит на отдельной машине, разрешайте порт СУБД только с адреса сервера 1С.

Что проверить до открытия портов

Сначала убедитесь, что сервер вообще слушает нужные порты. Иначе вы откроете порт в брандмауэре, а подключения всё равно не будет: слушать нечему.

Служба запущена

В Windows это служба «Агент сервера 1С:Предприятия 8.3 (x86-64)» в оснастке services.msc. В Linux служба называется srv1cv83:

systemctl status srv1cv83

Порты слушаются

В Windows (PowerShell или командная строка с правами администратора):

netstat -ano | findstr ":1540 :1541"

В Linux:

ss -tlnp | grep -E ':(1540|1541|15[6-9][0-9])'

Рабочие порты из диапазона появляются, только когда запущены рабочие процессы. На свежем сервере без активных сеансов вы можете увидеть только 1540 и 1541. Это нормально.

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

Проверка с клиентского компьютера

В PowerShell на клиенте:

Test-NetConnection -ComputerName имя_сервера -Port 1540

Строка TcpTestSucceeded : True значит, что порт доступен. False при запущенной службе указывает на брандмауэр сервера, роутер или фильтрацию в сети. Проверьте так же порты 1541 и один-два порта из диапазона.

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

Подходит для Windows Server 2016 и новее. Сначала создадим правила через графический интерфейс, затем покажем то же командой.

Через оснастку

1. Откройте wf.msc (Монитор брандмауэра Защитника Windows в режиме повышенной безопасности).
2. Слева выберите «Правила для входящих подключений», справа «Создать правило».
3. Тип правила: «Для порта».
4. Протокол: TCP. Конкретные локальные порты: 1540,1541,1560-1591.
5. Действие: «Разрешить подключение».
6. Профили: отметьте только те, в которых работает сервер. Для сервера в домене это обычно «Доменный».
7. Имя: что-нибудь понятное, например 1C Server 8.3.

Рабочие порты можно вынести в отдельное правило, если хотите видеть их раздельно. Но одно правило проще поддерживать.

Через PowerShell

То же самое одной командой:

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

Чтобы пустить в 1С только свою подсеть, добавьте параметр -RemoteAddress 192.168.1.0/24 (подставьте свою). Это самый дешёвый способ сократить поверхность атаки.

Проверить, что правило создалось:

Get-NetFirewallRule -DisplayName "1C Server 8.3" | Get-NetFirewallPortFilter

Если правило есть, а подключения нет

Бывает, что для программы уже создано блокирующее правило, а блокирующие правила сильнее разрешающих. Откройте список входящих правил, отсортируйте по действию и найдите «Блокировать» для ragent.exe, rmngr.exe или rphost.exe. Либо порты занимает антивирус с собственным сетевым экраном, и тогда исключение нужно добавлять в нём.

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

Выберите инструмент, который уже стоит в вашем дистрибутиве. Два файрвола сразу не держите: они будут конфликтовать.

Ubuntu и Debian: ufw

sudo ufw allow 1540:1541/tcp
sudo ufw allow 1560:1591/tcp
sudo ufw status numbered

Если файрвол выключен, ufw allow правило сохранит, но работать оно начнёт только после включения. Перед sudo ufw enable убедитесь, что порт SSH (22) разрешён, иначе потеряете удалённый доступ к серверу:

sudo ufw allow 22/tcp
sudo ufw enable

Ограничение по подсети:

sudo ufw allow from 192.168.1.0/24 to any port 1540:1541 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 1560:1591 proto tcp

CentOS, RHEL, AlmaLinux, Rocky: firewalld

sudo firewall-cmd --permanent --add-port=1540-1541/tcp
sudo firewall-cmd --permanent --add-port=1560-1591/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

Ключ --permanent записывает правило в конфигурацию, --reload применяет его. Без --permanent правило пропадёт после перезагрузки сервера.

iptables напрямую

sudo iptables -A INPUT -p tcp --dport 1540:1541 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 1560:1591 -j ACCEPT

Порядок важен: -A добавляет правило в конец цепочки. Если выше уже стоит общее правило DROP или REJECT, ваше разрешение никогда не сработает. Тогда вставляйте его в нужную позицию через -I INPUT 5 (номер строки смотрите в iptables -L INPUT --line-numbers).

Разрешаем PostgreSQL, если СУБД на этом же сервере

Если PostgreSQL стоит на той же машине, что и сервер 1С, внешнего порта 5432 открывать не нужно: обмен идёт через локальный интерфейс. Если СУБД вынесена на отдельный сервер, разрешайте порт 5432 на машине с СУБД только с адреса сервера 1С:

sudo ufw allow from 192.168.1.10 to any port 5432 proto tcp

И отдельно проверьте, что PostgreSQL принимает сетевые подключения: в postgresql.conf параметр listen_addresses, в pg_hba.conf строка для адреса сервера 1С.

Как сохранить правила, чтобы они пережили перезагрузку

Здесь чаще всего и ломается рабочая схема: порты открыли, всё заработало, а после планового перезапуска сервера пользователи не могут зайти.

Команду iptables-save без перенаправления в файл правила не сохраняет: она только выводит их на экран.

После сохранения проверьте результат на практике. Перезагрузка сервера прервёт сеансы всех пользователей, поэтому делайте её в нерабочее время и предупредите людей заранее. Если перезагрузка невозможна, хотя бы перезагрузите сам файрвол (firewall-cmd --reload) и убедитесь, что правила на месте.

Настройка роутера для доступа к серверу 1С

Внутри локальной сети роутер ничего не блокирует, и открывать на нём ничего не нужно. Он вступает в игру, когда сотрудники подключаются из другого офиса или из дома, а сервер стоит за NAT.

Что делать на роутере

В веб-интерфейсе роутера найдите раздел проброса портов. Он называется по-разному: «Port Forwarding», «Виртуальные серверы», «NAT». Для каждого порта или диапазона создаётся правило:

• внешний порт: 1540, 1541, 1560-1591;
• внутренний IP: адрес сервера 1С в локальной сети;
• внутренний порт: тот же;
• протокол: TCP.

Адрес сервера в локальной сети сделайте постоянным: либо статический IP на самом сервере, либо резервирование по MAC-адресу в DHCP роутера. Иначе после смены адреса проброс уйдёт «в никуда».

Почему так лучше не делать

Проброс портов 1С на публичный IP открывает сервер всему интернету. Сканеры находят порт 1540 за часы. Лучше другие варианты, в порядке предпочтения:

1. VPN до офиса (WireGuard, OpenVPN, средства роутера). Порты 1С остаются закрытыми снаружи, пользователь входит как в локальной сети.
2. Публикация на веб-сервере по HTTPS: пользователи работают через браузер или тонкий клиент по HTTP, наружу открыт только 443.
3. Терминальный сервер : наружу открыт только RDP, и лучше через шлюз или VPN.

Если проброс всё же необходим, ограничьте допустимые внешние адреса, если роутер это умеет, и держите на сервере актуальные обновления.

Как не открыть лишнего

Открытый порт — это поверхность атаки. Несколько правил, которые закрывают основные риски.

• Ограничивайте источники. Правило «разрешить с подсети офиса» лучше правила «разрешить всем». Для Windows это -RemoteAddress, для ufw allow from, для firewalld rich-правила.
• Не открывайте порты СУБД клиентам. PostgreSQL на 5432 и MS SQL на 1433 нужны только серверу 1С.
• Не оставляйте ras без нужды. Порт 1545 нужен, только если вы запускаете сервер администрирования. Запускаете его только на время работы и слушайте на нужном интерфейсе.
• Сузьте диапазон рабочих процессов. Если на сервере два-три рабочих процесса, нет смысла держать открытыми все 32 порта. Но меняйте диапазон осознанно: после изменения параметров запуска агент нужно перезапустить.
• Следите за журналом. Всплеск неудачных подключений к 1540 с чужих адресов означает, что порт виден снаружи. Закройте его.

Если вы поменяли порты агента и менеджера (например, из-за конфликта с другим сервисом), агент запускают с параметрами -port, -regport и -range. Вот пример значений по умолчанию:

ragent -port 1540 -regport 1541 -range 1560:1591

В брандмауэре тогда нужно открывать ваши значения. Удобнее не менять стандартные порты без реальной причины: так проще и вам, и тому, кто будет поддерживать сервер после вас.

Что делать, если после открытия портов подключения нет

Разберём типичные причины сверху вниз, от самой вероятной.

Клиент видит сервер, но не входит в базу. Открыты 1540 и 1541, а диапазон рабочих процессов забыли. Откройте 1560-1591 или ваш диапазон.

Порт открыт, но Test-NetConnection даёт False. Проверьте, что служба слушает порт именно на сетевом интерфейсе, а не только на 127.0.0.1: в выводе ss -tlnp или netstat -ano смотрите колонку адреса. Если там 127.0.0.1:1540, снаружи сервер недоступен.

С одного компьютера работает, с другого нет. Сравните, в каких подсетях они находятся. Часто правило разрешает только одну подсеть, а второй компьютер в другой.

Работало, перестало после обновления системы. Обновление могло сбросить профиль сети на «Общедоступный» (Windows), а правило создано для «Доменного». Проверьте профиль подключения и профили правила.

В Linux всё разрешено, но не работает. Проверьте, не включён ли SELinux в строгом режиме и не запущен ли одновременно второй файрвол. Для проверки выполните sudo firewall-cmd --state и sudo ufw status: активным должен быть один.

Порт занят другим процессом. В netstat -ano найдите PID, который слушает нужный порт, и сверьте с диспетчером задач. Если это не 1С, переносите чужую службу или меняйте порты агента.

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