При организации удаленного доступа к серверу 1С:Предприятие системные администраторы часто сталкиваются с необходимостью изолировать внутреннюю сеть сервера от сети клиентов. Одним из наиболее эффективных способов является использование Linux-шлюза с настройкой iptables (NAT). Однако классический проброс портов, который отлично работает для RDP или веб-серверов, в случае с 1С часто спотыкается об ошибку descr=11001 (0x00002AF9). В рамках данной статьи мы разберем, почему возникает эта ошибка и как правильно настроить сетевые правила для стабильной работы тонких и толстых клиентов. Для диагностики пропускной способности и стабильности канала связи можно использовать утилиту для тестирования сетевого интерфейса 1С.
Прежде чем приступать к настройке, проанализируем природу ошибки. Код 11001 в ОС Windows расшифровывается как WSAHOST_NOT_FOUND. Это означает, что клиентское приложение (в нашем случае — платформа 1С) не смогло разрешить сетевое имя сервера в IP-адрес. Особенность протокола 1С заключается в том, что даже если в строке подключения вы указываете IP-адрес, после установки первичного соединения менеджер кластера передает клиенту список рабочих процессов с их сетевыми именами (hostname) — для контроля его работы есть утилита администрирования кластера 1С и сеансов. Клиент пытается подключиться к этим именам, не находит их в своей локальной сети и выдает ошибку.
Рассмотрим сценарий, где у нас есть компьютер на базе Debian, разделяющий две сети. Сеть клиента — 10.0.0.0/24, сеть сервера 1С — 10.20.20.0/24. IP-адрес шлюза в клиентской сети — 10.0.0.71, в серверной — 10.20.20.71. IP сервера 1С — 10.20.20.70.
Для корректной работы нам необходимо пробросить основной диапазон портов 1С. Разберем правила iptables, которые необходимо применить на шлюзе:
# Проброс входящих пакетов на сервер 1С (DNAT)
iptables -t nat -A PREROUTING -p tcp -d 10.0.0.71 -m multiport --dport 135,475,1540,1541,1560:1591 -j DNAT --to-destination 10.20.20.70
# Подмена адреса источника, чтобы сервер отвечал через шлюз (SNAT)
iptables -t nat -A POSTROUTING -p tcp --dst 10.20.20.0/24 -j SNAT --to 10.20.20.71
Проанализируем используемые порты:
Как мы уже выяснили, просто пробросить порты недостаточно, так как 1С внутри протокола требует обращения по имени. Поскольку мы не хотим смешивать DNS-зоны разных сетей, воспользуемся самым простым и надежным способом — редактированием файла hosts на клиентских машинах.
Выясним сетевое имя (имя компьютера) сервера 1С. Допустим, оно 1c_srw-comp. На клиентском компьютере в файл C:\Windows\System32\drivers\etc\hosts необходимо добавить запись:
10.0.0.71 1c_srw-comp
Важный момент: мы указываем IP-адрес шлюза (внешний для клиента), но привязываем его к внутреннему имени сервера 1С. Теперь, когда клиент 1С получит от менеджера кластера команду "подключиться к рабочему процессу на сервере 1c_srw-comp", он обратится к IP 10.0.0.71, который шлюз успешно перенаправит на реальный сервер 10.20.20.70.
Проверим настройки брандмауэра на стороне Windows Server 2019, где установлена 1С. Несмотря на то, что локальные пользователи подключаются успешно, запросы, приходящие через NAT, могут блокироваться, если правила разрешают подключения только из локальной подсети.
Рекомендуем создать входящее правило для TCP-портов 1540, 1541, 1560-1591 и в поле "Удаленный адрес" разрешить доступ для IP-адреса шлюза (в нашем примере 10.20.20.71). Поскольку мы использовали SNAT на шлюзе, все запросы для сервера 1С будут выглядеть так, будто они исходят от самого шлюза.
Работа 1С через NAT может быть чувствительна к разрывам сессий. Рассмотрим настройку параметров Keep-Alive, чтобы шлюз не закрывал "молчаливые" соединения. На Linux-шлюзе можно подправить параметры ядра через sysctl:
sysctl -w net.ipv4.tcp_keepalive_time=600
sysctl -w net.ipv4.tcp_keepalive_intvl=60
sysctl -w net.ipv4.tcp_keepalive_probes=20
Также проанализируем ситуацию с MTU. Если пакеты 1С (например, при передаче большой конфигурации) будут фрагментироваться, это может привести к зависаниям. Попробуем принудительно ограничить размер MSS в iptables:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460
Для успешного проброса 1С без использования VPN или веб-сервера необходимо выполнить три ключевых условия:
Такой подход позволяет сохранить чистоту сетевой топологии: клиенты видят только один IP-адрес шлюза, а сервер 1С "общается" только с одним доверенным узлом в своей сети, при этом полноценно используя мощь толстого или тонкого клиента. Для последующего удаленного управления кластером в такой конфигурации пригодится кроссплатформенная консоль администрирования серверов 1С.