При развёртывании ELMA365 on-premise администратор сталкивается с рассыпанной по десяти страницам документацией: порты — в одном разделе, sysctl — в другом, реверс-прокси — в третьем. Мы собрали всё в одну статью: таблица портов, четыре режима SSL, конфигурация реверс-прокси, подводные камни из практики. Для Битрикс24 мы делали аналогичный разбор — теперь очередь ELMA365.

Все данные проверены по скрипту установки v2026.2.2 и официальной документации. Если нужна помощь с настройкой — мы оказываем сопровождение сервера ELMA365.

ELMA365 on-premise развёртывается в Docker-контейнере, внутри которого работает кластер Kubernetes (KinD — Kubernetes in Docker). Компоненты общаются друг с другом внутри кластера. Наружу по умолчанию выставлены только порты 80 и 443.

Компоненты платформы:

MongoDB версий 5.0 и выше требует инструкций AVX на процессоре. На старом оборудовании (до ~2011 года, до архитектуры Sandy Bridge) или в виртуальной машине без проброса AVX MongoDB не запустится — процесс падает с ошибкой Illegal instruction (core dumped). В виртуализации проблема решается сменой типа CPU с kvm64 на host (или минимум SandyBridge) в настройках гипервизора. Проверить поддержку AVX: grep flags /proc/cpuinfo | grep avx.

Бэкап платформы выполняется командой --dump (не --backup) и покрывает PostgreSQL, MongoDB и S3-хранилище. Valkey и RabbitMQ не бэкапятся — их данные восстановимы. При запуске --dump платформа останавливается автоматически, отдельно вызывать --stop не нужно. На время процедуры ELMA365 недоступна для пользователей.

Ниже — полная таблица: какие ELMA365 порты нужны платформе, для чего, и какие открывать на межсетевом экране.

Внешние порты (обязательные)

В скрипте установки эти порты задаются переменной:

PORTS="-p 80:80 -p 443:443"

По умолчанию ELMA365 слушает на всех интерфейсах. Если реверс-прокси установлен на той же машине, порты можно переназначить на localhost:

PORTS="-p 127.0.0.1:801:80 -p 127.0.0.1:4431:443"

Если реверс-прокси стоит на отдельном сервере — порты менять не нужно.

Порты внутренних компонентов (опциональный проброс)

В ELMA365 on-premise эти порты работают внутри контейнера KinD. По умолчанию они не проброшены наружу. Пробрасывать их нужно только для подключения средств диагностики и мониторинга.

Чтобы пробросить порт, достаточно указать параметр в конфигурации. Например, для доступа к PostgreSQL извне:

ELMA365_PORT_FORWARD_PSQL=true

При пробросе портов ограничьте доступ файрволом — только IP-адреса администраторов и систем мониторинга.

sysctl: подготовка ОС

До установки ELMA365 настройте модули ядра и sysctl. Без них KinD-кластер не маршрутизирует трафик между подами.

Загрузите модули ядра (файл /etc/modules-load.d/containerd.conf):

overlay
br_netfilter

Примените параметры sysctl. Добавьте в /etc/sysctl.conf:

net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-arptables = 1
net.ipv4.ip_forward                 = 1

Примените без перезагрузки: sysctl -p. Параметр net.bridge.bridge-nf-call-arptables = 1 требует загруженного модуля br_netfilter. Если модуль не загружен после перезагрузки — ELMA365 не стартует.

Из нашего опыта: если параметры заданы через sysctl -w, но не прописаны в /etc/sysctl.conf — после перезагрузки сервера контейнер ELMA365 стартует, но KinD внутри мёртв. Поды не видят друг друга, платформа выглядит «живой» снаружи, но ничего не работает. Без ip_forward и bridge-nf-call трафик между подами не ходит.

Четыре режима SSL-сертификатов

ELMA365 сервер поддерживает четыре режима SSL:

При использовании своего сертификата файл должен содержать полную цепочку (fullchain): сертификат сервера, затем промежуточный сертификат, затем корневой.

Два типа сертификатов — не путайте:

1. --reload-cert — обновляет HTTPS-сертификат ELMA365 (тот, что видит браузер).
2. --renew-certs-k8s — обновляет внутренние сертификаты K8s-кластера (те, по которым общаются поды).

Внутренние сертификаты KinD-кластера выпускаются ровно на один год с момента установки. Через год платформа начинает выдавать TLS handshake timeout, connection reset, EOF. Команда --reload-cert здесь не поможет — нужна именно --renew-certs-k8s.

С версии 2025.8 в ELMA365 появился ELMA365_CERTMANAGER — встроенный менеджер сертификатов. Реверс-прокси больше не обязателен для ELMA365 on-premise. Платформа сама получает и продлевает сертификат Let’s Encrypt — ставить реверс-прокси ради SSL-терминации не нужно.

Реверс-прокси нужен, когда:

• На одном IP работают несколько сервисов (ELMA365 + сайт + почта)
• Нужны кастомные правила маршрутизации или WAF
• Корпоративная политика требует единую точку терминации SSL
• Используется сертификат от корпоративного удостоверяющего центра

В качестве реверс-прокси подойдёт nginx, Caddy, HAProxy, Traefik или любой другой сервер с поддержкой WebSocket. Ниже — пример конфигурации nginx из официальной документации (проверена по скрипту v2026.2.2):

server {
    listen 80;
    server_name elma365.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name elma365.example.com;

    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    client_max_body_size 0;

    location / {
        proxy_pass http://ELMA365_IP:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

На что обратить внимание:

• proxy_pass — только HTTP. Официальная документация использует proxy_pass http://.... Вариант с HTTPS между реверс-прокси и ELMA365 не документирован — не рекомендуем его применять.
• WebSocket обязателен — без заголовков Upgrade и Connection "upgrade" не будут работать чаты, уведомления и совместное редактирование.
• client_max_body_size 0 — без ограничения размера загружаемых файлов. Если задать конкретное значение, пользователи получат ошибку 413 при загрузке крупных вложений.

В конфигурации ELMA365 включите:

# Если реверс-прокси на той же машине:
PORTS="-p 127.0.0.1:801:80 -p 127.0.0.1:4431:443"
ELMA365_PROXY_WITH_SSL=true

После настройки рекомендуем проверить конфигурацию Nginx линтером — это поможет выявить ошибки до запуска в продакшен.

HOSTALIASES_IP: частая ошибка при настройке

ELMA365_HOSTALIASES_IP нужен, когда DNS не резолвит домен изнутри K8s-кластера. Внутренний сервис diskjockey обращается к домену ELMA365 для работы с файлами. Если DNS не отвечает или возвращает внешний IP — diskjockey не подключится.

Значение ELMA365_HOSTALIASES_IP — IP-адрес машины с ELMA365, а не шлюза (gateway). Внутри KinD-кластера маршрутизацией управляет Traefik, а не внешний реверс-прокси. Частая ошибка: администратор ставит IP шлюза, diskjockey обращается к нему, тот проксирует обратно — петля.

Внутренние подсети KinD

ELMA365 docker использует KinD (Kubernetes in Docker) с собственными подсетями:

Pod- и Service-подсети — overlay-сети внутри Docker-контейнера. С хоста они не видны, маршруты к ним не создаются. Наружу выставлены только порты 80 и 443. Пересечение этих диапазонов с корпоративной сетью в типовой установке проблем не вызывает. Параметры ELMA365_PODSUBNET_CLUSTER_K8S и ELMA365_SVCSUBNET_CLUSTER_K8S полезны при отладке, когда нужно пробрасывать маршруты внутрь контейнера.

Docker bridge (172.17.0.0/16) — другое дело. Эта сеть видна с хоста и попадает в таблицу маршрутизации. Если корпоративная сеть использует диапазон 172.16.0.0/12 (частый случай), хост потеряет маршруты к ресурсам в этом диапазоне — трафик пойдёт в Docker вместо корпоративной сети. Измените адрес моста в /etc/docker/daemon.json:

{
  "bip": "192.168.128.1/24"
}

После изменения перезапустите Docker: systemctl restart docker. Менять подсети нужно до установки ELMA365 — на работающей системе смена подсетей потребует переустановки.

ELMA365_DOCKER_MTU нужен при работе через VPN-туннель. Docker по умолчанию использует MTU 1500, а WireGuard или IPSec уменьшают MTU на 60–80 байт. Без коррекции — фрагментация пакетов и просадка скорости.

Работа в закрытом контуре

Государственные структуры, объекты КИИ, организации под требованиями ФСТЭК — работают в изолированной сети. ELMA365 поддерживает офлайн-установку через флаг --offline: все образы загружаются из приватного Docker-реестра, SSL — через собственный сертификат или самоподписанный.

Let’s Encrypt в закрытом контуре недоступен. Обновления доставляются через промежуточный сервер. Для диагностики — команда --diag: собирает логи и состояние компонентов в один архив.

Сотрудники подключаются через VPN? Проверьте маршруты от VPN-клиентов до сервера ELMA365. Подробнее — в нашем кейсе по wg-portal.

Два порта, четыре параметра sysctl — минимальные сетевые требования ELMA365 on-premise. Проблемы возникают не из-за сложности, а из-за мелочей. За время сопровождения серверов ELMA365 мы собрали типичные ошибки.

1. Контейнер запускается, но платформа не работает после перезагрузки. Причина: sysctl-параметры заданы через sysctl -w, но не прописаны в /etc/sysctl.conf. После ребута ядро возвращает значения по умолчанию, KinD теряет маршрутизацию между подами. Решение: прописать параметры в /etc/sysctl.conf и применить: sysctl -p.

2. Ошибки TLS handshake timeout и EOF через год после установки. Причина: внутренние сертификаты KinD-кластера выпускаются ровно на один год с момента установки. Решение: ./elma365-docker.sh --renew-certs-k8s. Это не то же самое, что --reload-cert — последний обновляет пользовательский HTTPS-сертификат.

3. HOSTALIASES_IP указан неверно. Администратор прописывает IP шлюза (gateway) вместо IP машины ELMA365. Результат: diskjockey не может подключиться к платформе, пользователи получают ошибки при работе с файлами.

4. Docker bridge пересекается с корпоративной сетью. Если корпоративная сеть использует 172.16.0.0/12, а Docker bridge — 172.17.0.0/16, хост перестаёт видеть ресурсы в этом диапазоне. Решение: изменить bip в /etc/docker/daemon.json до установки.

5. proxy_pass на HTTPS. proxy_pass https://... между реверс-прокси и ELMA365 не документирован. Используйте proxy_pass http://... — SSL-терминация на реверс-прокси, ELMA365 за ним работает по HTTP.

6. Медленное обновление или зависание при обновлении. ELMA365 обновляется строго последовательно. При обновлении KinD открывает значительно больше файловых дескрипторов, чем стандартный лимит системы. Если обновление зависает или падает — проверьте скорость дисковой подсистемы и лимиты файловых дескрипторов (ulimit -n). Увеличьте лимит в /etc/security/limits.conf или через systemd-юнит Docker.

Для стабильной работы ELMA365 on-premise проверьте:

• Открыть порты 80 и 443, остальное — только для диагностики
• Настроить sysctl до установки и закрепить параметры в /etc/sysctl.conf (включая bridge-nf-call-arptables)
• Выбрать один из четырёх режимов SSL — с версии 2025.8 для большинства случаев подойдёт Let’s Encrypt без реверс-прокси
• Проверить, что Docker bridge (172.17.0.0/16) не пересекается с корпоративной сетью
• Использовать ELMA365_HOSTALIASES_IP с IP машины ELMA365, а не шлюза
• Помнить про два типа сертификатов: HTTPS (--reload-cert) и K8s (--renew-certs-k8s, срок действия — 1 год)
• При обновлении — проверить лимиты файловых дескрипторов и скорость диска

«На наших проектах внедрения мы регулярно сталкиваемся с ситуациями, когда заказчик разворачивает ELMA365, а потом месяцами ловит странные ошибки из-за неправильно сконфигурированной инфраструктуры: не те параметры sysctl, неверный IP в HOSTALIASES, пересечение подсетей. Рекомендуем использовать эту статью как чек-лист при установке и настройке платформы.»

— Виталий Трофимов, основатель Троффконс, сертифицированный партнёр ELMA365

Следующая статья — мониторинг ELMA365: Prometheus, Grafana и Zabbix, два уровня наблюдения за платформой.

Нужна помощь с настройкой сети, SSL или реверс-прокси? Сопровождение сервера ELMA365 — от 5 часов в месяц.

Ответы на частые вопросы по сетевым требованиям и настройке ELMA365 on-premise.