Закрываем сетевые порты сервера 1С и ограничиваем доступ извне

Закрыть порты 1С — значит оставить сервер открытым только для своих клиентов и закрыть всё остальное на брандмауэре. Практически это два действия: разрешить входящие подключения к портам кластера (1540, 1541 и диапазону рабочих процессов) только из доверенной подсети и заблокировать прямой доступ к ним из интернета. Защита держится на правилах фаервола, а не на том, что «порт никто не знает».

Сервер 1С в клиент-серверном варианте слушает несколько портов, и у каждого своя роль. Если открыть лишнее — к кластеру дотянется кто угодно; если закрыть лишнее — перестанут подключаться собственные пользователи. Ниже — что именно слушает сервер, как сузить диапазон, как настроить брандмауэр Windows и как убедиться, что снаружи ничего лишнего не торчит.

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

Клиент при подключении сначала обращается к агенту сервера на порт 1540, получает от него адрес менеджера кластера, соединяется с менеджером на 1541, а после авторизации работает уже с рабочим процессом из выделенного диапазона. Поэтому для толстого клиента мало открыть один порт — нужны все три звена.

Логика закрытия простая:

• 🔒 1433/1434 СУБД — доступны только серверу 1С, снаружи закрыты всегда.
• 🔒 1540, 1541, 1545 и диапазон 1560–1591 — открыты только для локальной сети или VPN.
• 🌐 443 веб-публикации — единственный порт, который допустимо выставить наружу, и только по HTTPS.

Порты кластера 1541 и 1560–1591 нельзя публиковать в интернет напрямую ни при каких условиях. Через них толстый клиент получает полный доступ к серверу, и открытый наружу диапазон — это приглашение к перебору паролей и атакам на платформу.

Отдельно держите в уме сетевую лицензию. Если лицензии раздаёт менеджер лицензий Sentinel HASP, он слушает порт 1947 (TCP и UDP), и клиенты обращаются к нему за получением лицензии. Слишком жёсткое правило фаервола, перекрывающее этот порт внутри сети, оставит пользователей без лицензии даже при полностью рабочем кластере. Наружу 1947 не открывают — он нужен только в пределах локальной сети.

Как сузить диапазон портов рабочих процессов

По умолчанию рабочие процессы занимают широкий диапазон 1560–1591 — 32 порта. На практике процессов обычно 1–3, и держать открытыми все 32 порта незачем. Диапазон задаётся в свойствах рабочего сервера, а не всего кластера.

1. Откройте консоль администрирования серверов (оснастка MMC) или подключитесь утилитой rac.
2. Разверните кластер → Рабочие серверы → откройте свойства нужного сервера.
3. В поле Диапазон портов укажите узкий интервал, например 1560:1569.
4. Сохраните и перезапустите службу агента сервера, чтобы изменения вступили в силу.

После сужения диапазона правило брандмауэра должно разрешать ровно этот интервал, а не прежние 1560–1591. Рассинхрон между настройкой сервера и правилом фаервола — частая причина проблем с подключением (см. раздел об ошибках).

Если кластер развёрнут на нескольких рабочих серверах, диапазон портов задаётся у каждого сервера отдельно и может отличаться. Тогда и правила фаервола настраиваются на каждой машине под её собственный интервал. Для центрального сервера остаются порты агента и менеджера (1540, 1541), дополнительные рабочие серверы слушают только свои диапазоны рабочих процессов.

Настройка брандмауэра Windows: правила для входящих подключений

Брандмауэр Защитника Windows по умолчанию блокирует входящие подключения, для которых нет разрешающего правила. Задача — создать точечные правила «разрешить» для портов 1С и ограничить их область доверенной подсетью.

Через графическую оснастку:

1. Запустите wf.msc — Брандмауэр Защитника Windows в режиме повышенной безопасности.
2. Правила для входящих подключений → Создать правило → тип Для порта.
3. Протокол TCP, перечислите порты: 1540,1541,1545,1560-1569.
4. Действие — Разрешить подключение.
5. На вкладке Область (Scope) в разделе «Удалённые IP-адреса» укажите доверенную подсеть, например 192.168.1.0/24. Это ключевой шаг: без ограничения области порт будет открыт для всех.

То же правило одной командой PowerShell:

New-NetFirewallRule -DisplayName "1C Server cluster" `
  -Direction Inbound -Protocol TCP `
  -LocalPort 1540,1541,1545,1560-1569 `
  -RemoteAddress 192.168.1.0/24 -Action Allow

Или через netsh:

netsh advfirewall firewall add rule name="1C cluster" dir=in action=allow ^
  protocol=TCP localport=1540,1541,1545,1560-1569 remoteip=192.168.1.0/24

Порт СУБД закрывают отдельно. Если MS SQL стоит на том же сервере, что и 1С, доступ к 1433 нужен только с адреса самого сервера 1С (а при установке на одной машине — вообще только через localhost). Правило для 1433 ограничивайте адресом сервера приложений, наружу его не выпускайте.

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

Удалённый доступ без открытых портов: VPN и веб-публикация

Самый частый повод «пробросить порты наружу» — удалённые сотрудники. Делать этого не нужно: есть два безопасных способа дать доступ, не открывая кластер в интернет.

VPN — клиент сначала поднимает туннель до корпоративной сети, а внутри неё уже подключается к серверу 1С по обычным портам. Снаружи виден только порт VPN-сервиса, порты кластера остаются за периметром. Это универсальный вариант: работает и для толстого клиента, и для консоли администрирования.

Веб-публикация — база публикуется на веб-сервере (Apache или IIS), пользователи заходят тонким или веб-клиентом по https://. Наружу открыт единственный порт 443, порты 1540–1591 остаются закрытыми. Обязательно настройте TLS-сертификат: публиковать 1С по чистому HTTP на 80 нельзя — логины и данные пойдут открытым текстом.

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

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

Посмотреть слушающие порты и процессы:

netstat -ano | findstr LISTENING

Колонка с PID покажет процесс; сопоставить его с ragent, rmngr, rphost или ras можно командой tasklist /svc /FI "PID eq <номер>". То же в PowerShell, сразу с именем процесса:

Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess |
  Sort-Object LocalPort

Если порт слушается на адресе 0.0.0.0, он принимает подключения со всех интерфейсов — именно такие порты и должны быть прикрыты правилом области. Порт, слушающий только 127.0.0.1, снаружи недоступен и дополнительной блокировки не требует.

Активные правила брандмауэра удобно смотреть так:

Get-NetFirewallRule -Direction Inbound -Enabled True |
  Where-Object DisplayName -like "*1C*"

Чтобы увидеть, какие подключения реально отбрасываются, включите журнал брандмауэра (в свойствах профиля → «Ведение журнала» → записывать пропущенные пакеты). Лог пишется в %systemroot%\system32\LogFiles\Firewall\pfirewall.log — по нему видно, с каких адресов идут отвергнутые попытки достучаться до портов кластера.

Проверить доступность порта снаружи, с машины вне офисной сети, можно командой Test-NetConnection -ComputerName <адрес> -Port 1541. Ответ TcpTestSucceeded : False для портов кластера — это то, что нужно: снаружи они закрыты.

Что ломается после закрытия портов и как это чинить

Типичная картина: правила навесили, а база перестала открываться. Почти всегда причина — не в том, что порт «не тот», а в том, что закрыли на одно звено больше, чем нужно. Сопоставьте симптом с причиной.

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

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