Документация ELMA365 on-premise рассыпана по десяти страницам: порты — в одном разделе, параметры ядра — в другом, реверс-прокси — в третьем. Мы в IT For Prof собрали сетевую настройку в один материал и проверили каждый параметр по скрипту установки версии 2026.2.2.
Проблемы с ELMA365 чаще создают мелочи: не тот параметр sysctl, неверный IP в настройках, пересечение подсетей. Платформа выглядит живой снаружи, но внутри ничего не работает.
Какие порты открывать: всего два обязательных
ELMA365 разворачивается в Docker-контейнере, внутри которого работает кластер Kubernetes — KinD (Kubernetes in Docker). Компоненты — PostgreSQL, MongoDB, RabbitMQ, Valkey, MinIO — общаются между собой внутри кластера. Наружу по умолчанию выставлены только два порта:
- 80 (HTTP) — перенаправление на HTTPS или приём трафика от реверс-прокси
- 443 (HTTPS) — основной доступ к платформе
Порты внутренних компонентов — PostgreSQL 5432, MongoDB 27017, Valkey 6379, RabbitMQ 5672 и 15672, MinIO 9000, OpenSearch 9200 — работают внутри контейнера KinD. Пробрасывать их наружу нужно только для диагностики и мониторинга, и тогда доступ стоит ограничить файрволом до IP администраторов.
Почему KinD умирает после перезагрузки
До установки нужно подготовить ядро системы. Без двух модулей и четырёх параметров sysctl кластер KinD не маршрутизирует трафик между подами.
Загрузите модули overlay и br_netfilter через файл в /etc/modules-load.d/. Затем пропишите в /etc/sysctl.conf параметры net.bridge.bridge-nf-call-iptables, ip6tables и arptables со значением 1, а также net.ipv4.ip_forward = 1. Параметр arptables требует загруженного модуля br_netfilter.
Самая частая ошибка из нашей практики: параметры заданы через sysctl -w, но не прописаны в файле. После перезагрузки ядро возвращает значения по умолчанию, контейнер стартует, а KinD внутри мёртв — поды не видят друг друга. Закрепляйте параметры в /etc/sysctl.conf и применяйте командой sysctl -p.
Четыре режима SSL и два типа сертификатов
ELMA365 поддерживает четыре режима работы с SSL:
- Let's Encrypt — платформа сама получает и обновляет сертификат, если есть доступ в интернет и открыты порты 80/443
- Самоподписанный — для тестовых сред и закрытого контура
- Свой сертификат — купленный или от корпоративного центра; файл должен содержать полную цепочку: сертификат сервера, промежуточный, корневой
- За реверс-прокси — терминация SSL на прокси, ELMA365 работает по HTTP
Не путайте два типа сертификатов. Команда --reload-cert обновляет HTTPS-сертификат, который видит браузер. Команда --renew-certs-k8s обновляет внутренние сертификаты кластера, по которым общаются поды.
Внутренние сертификаты KinD выпускаются ровно на один год. Через год платформа начинает выдавать ошибки TLS handshake timeout, connection reset и EOF. Здесь поможет только --renew-certs-k8s — обновление пользовательского сертификата ситуацию не исправит.
Когда нужен реверс-прокси, а когда нет
С версии 2025.8 реверс-прокси перестал быть обязательным: встроенный менеджер сертификатов сам получает и продлевает Let's Encrypt. Ставить nginx ради SSL-терминации больше не нужно.
Прокси оправдан в четырёх случаях: на одном IP несколько сервисов, нужны кастомные правила маршрутизации или WAF, корпоративная политика требует единой точки терминации SSL, используется сертификат корпоративного центра.
В конфигурации nginx критичны три момента. Параметр proxy_pass — только http: вариант с https между прокси и платформой не документирован. Заголовки Upgrade и Connection «upgrade» обязательны, иначе не работают чаты, уведомления и совместное редактирование. Значение client_max_body_size 0 снимает ограничение на размер файлов — без него пользователи получат ошибку 413 при загрузке крупных вложений.
Как подсети KinD ломают корпоративную сеть
KinD использует три собственные подсети. Pod-сеть 10.244.0.0/16 и Service-сеть 10.96.0.0/16 изолированы внутри Docker и с хоста не видны — их пересечение с корпоративной сетью в типовой установке проблем не вызывает.
Опасен Docker bridge 172.17.0.0/16: эта сеть видна с хоста и попадает в таблицу маршрутизации. Если корпоративная сеть использует диапазон 172.16.0.0/12, хост потеряет к нему маршруты — трафик уйдёт в Docker. Смените адрес моста через параметр bip в /etc/docker/daemon.json и сделайте это до установки: на работающей системе смена подсетей потребует переустановки.
Ещё одна частая ошибка — параметр ELMA365_HOSTALIASES_IP. В нём указывают IP машины с ELMA365, а не шлюза. Внутренний сервис diskjockey обращается к домену платформы для работы с файлами; если задать IP шлюза, тот проксирует запрос обратно и образуется петля.
Шесть ошибок, которые мы встречаем чаще всего
За время сопровождения серверов ELMA365 мы собрали типичные проблемы сетевой настройки:
- Параметры sysctl не закреплены в /etc/sysctl.conf — после ребута KinD теряет маршрутизацию между подами
- Ошибки TLS через год после установки — истекли сертификаты кластера, нужна команда --renew-certs-k8s
- В HOSTALIASES_IP прописан шлюз вместо IP машины ELMA365 — diskjockey не подключается к файлам
- Docker bridge пересекается с корпоративным диапазоном 172.16.0.0/12
- proxy_pass указан на https вместо http
- При обновлении не хватает файловых дескрипторов — проверьте ulimit -n и скорость дисковой подсистемы
Эта статья работает как чек-лист при установке: проверьте два порта, закрепите sysctl, выберите один из четырёх режимов SSL, разведите подсети и задайте верный HOSTALIASES_IP. Если нужна помощь с настройкой сети, SSL или реверс-прокси — команда IT For Prof берёт серверы ELMA365 на сопровождение.