Не шучу, правда довели. Одни уходят, другие замедляют. И у меня начала мелькать шальная мысль: а что, если взять и поднять свой корпоративный чат?
Но я это делаю вообще в первый раз, поэтому сразу появилась гора вопросов: а с чего начать, как это спроектировать, сколько нужно серверов, нужен ли VPN, как не оставить дыру в безопасности и не собрать систему, которую потом я сам же запарюсь поддерживать?
Я Марк Ковалев, технический специалист по ИБ. И сегодня я отвечу на все эти вопросы себе и вам, а также расскажу, как поднял корпоративный мессенджер в облаке с нуля. Сильно не ругайтесь, я знаю, что решение может быть не самым оптимальным — поэтому жду советы в комментах, чтобы его докрутить и сделать круче.
Что не так с телегой под VPN?
Даже если бы телегу не замедляли, с ней все равно много проблем. Расскажу про них поподробнее.
У нас небольшая команда разработки, до 15 человек. Два года мы жили в телеге, и раньше все было нормально: и быстро, и привычно. Но все это время команда росла и процессы тоже менялись. И я, и остальные стали замечать недостатки, которые полезли со всех сторон.
Боль №1: треды
В телеге ответ на сообщение — это цитирование в общий поток, а не ветка обсуждения. Когда в одном рабочем канале одновременно идут разговоры о баге в проде, пиаре на ревью и об организации корпоратива, навигация превращается в пытку. Да, есть топики в супергруппах, но, боже мой, как же это неудобно! Вы уже мучились в попытке выйти из супергруппы и скрыть меню всех подгрупп? Ну вот и я о том же, ненавижу супергруппы. Mattermost и Slack, к слову, решили эту задачу пять лет назад. А телега до сих пор нет.
Боль №2: пуши по CI/CD
Мы написали бота, который отправлял результаты билдов и деплоев в отдельный чат. Но гранулярности ноль: нельзя подписаться на уведомления от конкретного пайплайна или отфильтровать по проекту. Все валится в одну ленту, и через неделю люди просто мьютят чат. А иногда и раньше. Бот превращается в помойку, в которую никто не смотрит.
Боль №3: поиск по истории
Попробуйте найти обсуждение архитектурного решения полугодовой давности в телеграм-чате на 15 человек с несколькими тысячами сообщений в месяц. Телега в общем поиске ищет по подстроке, без фильтрации по автору, дате или каналу (внутри канала можно поискать по автору или дате, но не всегда выдает верные результаты). Вы получите 200 результатов и будете листать вручную. Но в процессе все может залагать — и придется листать заново.
Боль №4: права доступа
Точнее, их отсутствие. В Telegram нельзя дать стажеру доступ только к каналам его проекта. Он либо в чате, либо нет. Нет ролей — только косметические лейблы ролей/должностей, нет per-channel permissions, нет гостевых аккаунтов с ограниченным доступом.
Боль №5: конфиденциальность
Корпоративная переписка, внутренние API-ключи, проброшенные в сообщениях (да, так не надо, но так бывает), обсуждение инцидентов и постмортемов — все это живет на серверах публичного мессенджера. Серверная часть телеги — проприетарный код, условия доступа к данным определяет третья сторона. Для нас это перестало быть приемлемым.
По итогу наше решение: self-hosted-чат на собственной инфраструктуре, доступный исключительно через VPN. Ниже — то, как мы выбирали платформу, почему остановились на Matrix, и полная инструкция по развертыванию.
А кандидаты кто?
Мы рассматривали три платформы: Mattermost, Rocket.Chat и Matrix + Element. У каждой свои сильные стороны и своя галька в тапочке, которая к 2026 году стала мешаться еще сильнее, чем еще пару лет назад.
Mattermost: был фаворитом, пока не вышла v11
Mattermost долго был золотым стандартом self-hosted-чата для разработчиков. Интерфейс, скопированный со Slack, каналы, треды, вебхуки, интеграции с GitLab и Jenkins из коробки. Простой деплой тоже был плюсом: один docker-контейнер с PostgreSQL. Документация качественная, сообщество активное. Для небольшой команды это идеальный кандидат.
Все изменилось в октябре 2025 года с выходом v11.0. Mattermost радикально перекроил бесплатные предложения. Теперь при запуске enterprise-бинарника без лицензии вы получаете Entry Edition, которая накладывает лимит в 10 000 сообщений — не на канал, а на весь сервер суммарно. Старые сообщения остаются в базе данных, но полностью пропадают из интерфейса и поиска. Для команды, генерирующей 200–300 сообщений в день, это примерно полтора месяца до стены. Помимо этого, звонки ограничены 40 минутами, пуш-уведомления — 10 000 в месяц, доски — 1 000 карточками, плейбуки — пятью запусками в месяц.
Реакция сообщества была, мягко говоря, бурной. На Hacker News тред набрал 314 очков и более 250 комментариев. Пользователи сравнивали ретроактивное скрытие истории с ransomware. Администратор школы с 2 000 пользователей и 470 000 сообщений подал в GitHub issue #34271, после того как потерял доступ ко всей истории до сентября 2025 года.
В ответ на ситуацию появился форк Mostlymatter от французской некоммерческой организации Framasoft. Это drop-in-замена бинарника, убирающая лимиты на пользователей и сообщения. System76 перевела на него чат сообщества Pop!_OS в феврале 2026-го, YunoHost переключил свой официальный пакет. Для команд, которым нужен UX «Маттермоста» без искусственных ограничений, Mostlymatter — вполне рабочий вариант. Но зависимость от энтузиазма стороннего создателя, пусть и уважаемого, — не лучшая основа для долгосрочного планирования, на мой взгляд… Но тут сами решайте.
Еще один путь — остаться на v10.11 ESR, которая поддерживается до 15 августа 2026-го. Это покупает время, но не решает проблему.
Rocket.Chat: смерть от тысячи порезов
Rocket.Chat — вполне зрелый продукт с богатым интерфейсом: каналами, тредами, аудио- и видеозвонками, омниканальной поддержкой клиентов, маркетплейсом приложений. На нем сидят крупные игроки, в том числе некоторые юниты «Сбера». Но Community Edition обложена ограничениями, которые по отдельности кажутся терпимыми, а все вместе делают продукт непригодным для серьезного использования.
Главный лимит — 10 000 пуш-уведомлений в месяц через официальный шлюз. Эта квота была введена еще в 2020 году, и на форумах модераторы подтверждали в 2024 году, что пересматривать ее никто не планирует.
Обходной путь для пуш-уведомлений формально существует, но он дорогой. Официальная документация предлагает форкнуть мобильное приложение Rocket.Chat, создать собственные Firebase- и APNs-ключи, собрать white-label-приложение, опубликовать его в App Store и Google Play. Apple Developer Account стоит 99 долларов в год, плюс вы берете на себя постоянную поддержку сборки при каждом обновлении SDK. Для небольшой команды это какая-то жесть, а не решение.
Есть и бесплатный тариф Starter (до 50 пользователей, расширен с 25 в v7.0), который снимает лимит на пуши и добавляет премиум-функции. Но там нужна регистрация в Rocket.Chat Cloud и привязка сервера, что для self-hosted-сценария, мотивированного контролем над данными, выглядит как противоречие.
Matrix + Element: открытый протокол без лимитов
Matrix — открытый федеративный протокол для коммуникаций.
Synapse — эталонная серверная реализация на Python.
Element — основной клиент, доступный как веб-приложение, десктопное приложение (Electron) и мобильные приложения на iOS и Android.
Принципиальное отличие от «Маттермоста» и Rocket.Chat — в отсутствии лимитов на сообщения, пользователей, пуш-уведомления или функции. Протокол открыт (Apache 2.0), сервер — под Apache 2.0, клиент — тоже.
Федерация — ключевая особенность Matrix, но для внутреннего командного чата она не нужна. Если сервер доступен только через VPN и вы не планируете общаться с пользователями на других matrix-серверах, ее лучше отключить.
Это делается одной строкой в homeserver.yaml:
federation_domain_whitelist: []` // пустой список = федерация ни с кем
Убирает фоновый трафик key-fetching и presence и уменьшает поверхность атаки.
Слабые стороны тоже есть. Развертывание заметно сложнее: Synapse + PostgreSQL + Element Web + Caddy + CoreDNS — это 5–8 контейнеров против 2–3 у «Маттермоста», да и начальная настройка занимает 2–4 часа вместо получаса. UX-онбординг тяжелее: верификация cross-signing при первом входе с нового устройства сбивает с толку нетехнических коллег, а потеря ключа восстановления равна потере зашифрованной истории навсегда.
Наш выбор
Да, по моему описанию было несложно понять, что мы выбрали Matrix + Element. Причина: это единственная платформа, где вендор не может задним числом ввести лимит на историю сообщений или количество пуш-уведомлений. Сложность развертывания для нас — это одноразовая цена. А вот лицензионные сюрпризы — штука повторяющаяся.
Важно! Если вашей команде не нужна федерация, а нужен максимально простой деплой с привычным Slack-like UX, присмотритесь к Mostlymatter. Он поднимается за час на том же стеке.
Архитектура решения
Итоговый стек развернут на одном виртуальном сервере в Сloud.ru.
Конфигурация:
2 vCPU / 4 GB RAM (тип standard из линейки Evolution Compute), Debian 13, 40 GB.
Визуал решения вот такой:
Единственный порт, который открыт наружу, — UDP 51820 для WireGuard. Все остальные сервисы слушают только на VPN-интерфейсе (10.8.0.1). Веб UI wg-easy защищен паролем с двухфакторкой и доступен только через VPN. Caddy выступает в роли внутреннего удостоверяющего центра (CA) и генерирует и автоматически обновляет TLS-сертификаты для всех сервисов через директиву tls internal. Никаких внешних зависимостей, никаких публичных DNS-записей.
CoreDNS резолвит имена вида chat.team.internal и element.team.internal в VPN-адрес сервера. WireGuard-клиенты получают адрес DNS-сервера автоматически при подключении. Единственная ручная операция — один раз установить корневой сертификат Caddy на устройства участников команды.
Медиафайлы и вложения хранятся не на локальном диске, а в Evolution Object Storage — S3-совместимом хранилище. Оно работает со стандартным AWS SDK (boto3, aws-cli, rclone) через эндпойнт https://s3.cloud.ru, регион ru-1a, авторизация AWS Signature v4. Так я решил проблему роста диска VPS и упростил бэкапирование.
Развертывание
Шаг 1: подготовка VPS
В консоли Evolution создаем виртуальную машину. Если у вас совсем нет опыта или просто неохота разбираться, можно попросить их внутреннего ИИ-помощника сделать это за вас.
Выбираем конфигурацию, которую описывал раньше: 2 vCPU / 4 GB RAM. Диск 40 GB SSD, операционная система Debian 12 (потом обновим до 13-й). Публичный IP делаем прямой на машину, без NATa.
На платформе есть free tier (2 vCPU, 4 GB, 30 GB), но без публичного IP. Добавление интернет-доступа стоит примерно 146 руб/мес. Но под мою задачу нужен полноценный публичный IP для WireGuard endpoint, поэтому free tier подходит только для тестирования. Новые аккаунты, кстати, получают 4 000 бонусных рублей на 60 дней, их тоже заюзал.
Добавляем свой SSH-ключ, подключаемся:
ssh user1@<PUBLIC_IP> sudo apt update && sudo apt upgrade -y
Меняем bookworm на trixie и обновляемся до Debian 13:
sudo vi /etc/apt/sources.list sudo apt update && sudo apt dist-upgrade -y
Меняем порт SSH на нестандартный, чтобы ботам хоть чуть-чуть сложнее было ддосить машину:
sudo vi /etc/ssh/sshd_config --- Port 3422 --- sudo systemctl restart ssh
На этом моменте мы сможем заметить, что новые SSH-подключения на новый порт не идут. Это потому, что порты по дефолту закрыты.
Идем в группы безопасности, находим ту, в которой сидит интерфейс машины, меняем SSH-правило. И заодно добавляем проброс порта для WireGuard-трафика:
Далее доустанавливаем докер, добавляем своего пользователя в группу, все стандартно.
# Добавляем GPG-ключ для Docker: sudo apt update sudo apt install ca-certificates curl sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc sudo chmod a+r /etc/apt/keyrings/docker.asc # Добавляем репозиторий: sudo tee /etc/apt/sources.list.d/docker.sources <<EOF Types: deb URIs: https://download.docker.com/linux/debian Suites: $(. /etc/os-release && echo "$VERSION_CODENAME") Components: stable Signed-By: /etc/apt/keyrings/docker.asc EOF sudo apt update sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin sudo adduser user1 docker
Шаг 2: S3-хранилище для медиафайлов
В консоли Evolution создаем бакет в Evolution Object Storage. Имя — matrix-media; регион — ru-central-1; класс хранения — стандартный:
Этот бакет для Synapse, для хранения загруженных медиафайлов (изображения, файлы, аватарки). Локальный диск VPS при этом используется только для метаданных и кеширования.
Для его подключения еще нужны будут ключи доступа. Чтобы их сделать, заходим в «Настройки пользователя» → «Ключи доступа» → «Создать ключ». Делаем описание, задаем время жизни. Обязательно копируем Key Secret (пароль): после закрытия окошка его не получить. Также запоминаем Key ID (логин).
Шаг 3: WireGuard через wg-easy
У wg-easy v15 была полная переработка проекта в мае 2025-го: сменилась лицензия на AGPL-3.0. Главное изменение: почти все переменные окружения вроде WG_HOST, WG_DEFAULT_ADDRESS, WG_DEFAULT_DNS, PASSWORD_HASH удалены. И конфигурация теперь происходит через интерактивный мастер настройки при первом запуске, а параметры хранятся в SQLite-базе внутри контейнера. Из переменных окружения остались только PORT (TCP-порт Web UI, по умолчанию 51821), HOST (bind-адрес, по умолчанию 0.0.0.0), INSECURE (разрешить HTTP без TLS, по умолчанию false) и DISABLE_IPV6.
mkdir -p ~/wireguard && cd ~/wireguard vi ./docker_compose.yml
volumes: etc_wireguard: services: wg-easy: image: ghcr.io/wg-easy/wg-easy:15 container_name: wg-easy network_mode: host environment: # Без reverse proxy внутри VPN, разрешаем plain HTTP - INSECURE=true # Выключаем IPv6 - DISABLE_IPV6=true volumes: - etc_wireguard:/etc/wireguard - /lib/modules:/lib/modules:ro restart: unless-stopped cap_add: - NET_ADMIN - SYS_MODULE devices: - /dev/net/tun:/dev/net/tun
Важно! /lib/modules:/lib/modules:ro — новое обязательное требование на v15 для доступа к модулям ядра. Без него контейнер не стартанет. А именованный том etc_wireguard вместо bind mount — это рекомендация из официальной доки.
Также используем хостовую сеть, чтобы интерфейс wg0 с адресом 10.8.0.1 был недоступен для бинда сервисов без лишних изворотов с роутингом.
Добавляем конфиг sysctl для форвардинга:
sudo tee /etc/sysctl.d/90-wireguard.conf << 'EOF' net.ipv4.ip_forward=1 net.ipv4.conf.all.src_valid_mark=1 EOF
Дальше:
docker compose up -d
Делаем SSH-туннель, чтобы безопасно подключиться к незащищенной веб-морде:
ssh -L 51821:127.0.0.1:51821 -p 3422 -N user1@<PUBLIC_IP>
Заходим в http://127.0.0.1:51821. При первом запуске wg-easy показывает мастер настройки, в котором задаем:
Учетную запись администратора.
Host — публичный IP сервера.
Port — 51820 (по умолчанию).
Дальше в настройках задаем:
Разрешенные IP‑адреса. 10.8.0.0/24 (только VPN-трафик, не весь интернет клиента).
DNS. Указываем IP нашего будущего CoreDNS — 10.8.0.1.
Устройство. Указываем сетевой интерфейс машины, у меня enp3s0.
Также меняем хуки в настройках. По сути, убираем NAT. Через VPN доступа в обычную сеть нет, он только для доступа к внутренним ресурсам и, может быть, к коллегам.
PostUp:
iptables -A FORWARD -i wg0 -o wg0 -j ACCEPT
PostDown:
iptables -D FORWARD -i wg0 -o wg0 -j ACCEPT
Создаем конфигурации и тестим. Теперь веб-интерфейс доступен также через VPN: http://10.8.0.1:51821.
Важно! Для автоматизации (Ansible, скрипты) в v15 есть INIT-переменные: INIT_ENABLED=true, INIT_USERNAME, INIT_PASSWORD, INIT_HOST, INIT_PORT, INIT_DNS и т. д. Они отрабатывают только при первом запуске и игнорируются при последующих. После первичной настройки рекомендуется убрать их из docker-compose, чтобы пароль не светился в конфиге.
Шаг 4: внутренний DNS на CoreDNS
Нам нужно, чтобы имена вроде chat.team.internal резолвились в VPN-адрес сервера (10.8.0.1) для клиентов внутри VPN. Это берет на себя CoreDNS.
Важно! Не используйте TLD .local, так как он зарезервирован для mDNS и конфликтует с Bonjour на macOS и iOS. Хорошие варианты: .internal (зарезервирован IANA для приватного использования) или home.arpa.
Качаем и устанавливаем свежую версию:
cd /tmp wget https://github.com/coredns/coredns/releases/download/v1.14.2/coredns_1.14.2_linux_amd64.tgz tar xzf coredns_1.14.2_linux_amd64.tgz sudo mv coredns /usr/local/bin/ sudo chmod +x /usr/local/bin/coredns coredns --version
Создаем директорию для конфигов:
sudo mkdir -p /etc/coredns
Файл зоны db.team.internal — стандартный формат BIND zone file:
sudo tee /etc/coredns/db.team.internal << 'EOF' ; $ORIGIN задает суффикс по умолчанию для неполных имен в этом файле $ORIGIN team.internal. ; SOA (Start of Authority) обязательная запись для любой DNS-зоны ; Формат: primary-ns admin-email (serial refresh retry expire minimum-ttl) ; admin-email: точка вместо @, т. е. admin.team.internal = admin@team.internal @ IN SOA ns.team.internal. admin.team.internal. ( 2025010101 ; serial — увеличивайте при каждом изменении зоны 3600 ; refresh — как часто secondary DNS проверяет обновления (нам неважно) 600 ; retry — интервал повтора при неудаче 86400 ; expire — через сколько secondary перестает отдавать зону 60 ; minimum TTL — время жизни negative-кеша ) ; NS указывает authoritative nameserver для зоны @ IN NS ns.team.internal. ; A-записи: имя = IPv4-адрес внутри VPN ; Все сервисы живут на одном VPS, поэтому все указывают на 10.8.0.1 ns IN A 10.8.0.1 chat IN A 10.8.0.1 ; Synapse homeserver element IN A 10.8.0.1 ; Element Web frontend wg IN A 10.8.0.1 ; wg-easy Web UI EOF
Конфиг CoreDNS Corefile — каждый блок в { } описывает зону и набор плагинов для нее:
sudo tee /etc/coredns/Corefile << 'EOF' # Зона team.internal — наши внутренние сервисы # CoreDNS будет отвечать на запросы к *.team.internal . { # привязываемся на WireGuard-сервер bind 10.8.0.1 # Зона team.internal — наши внутренние сервисы # file — плагин, загружающий зону из файла в формате BIND file /etc/coredns/db.team.internal team.internal # forward — проксирует запросы к upstream DNS-серверам # Здесь используем Google (8.8.8.8) и Cloudflare (1.1.1.1) # Можно заменить на любые другие, например Яндекс (77.88.8.8) forward . 8.8.8.8 1.1.1.1 # cache — кеширует ответы от upstream на 30 секунд # Уменьшает задержку и нагрузку на upstream при повторных запросах cache 30 # log — логирует все DNS-запросы к этой зоне в stdout # Полезно для отладки; в продакшене можно убрать log # Return errors for failed queries instead of silently dropping # Возвращать ошибки, а не втихую дропать errors } EOF
Создаем systemd-сервис:
sudo tee /etc/systemd/system/coredns.service << 'EOF' [Unit] Description=CoreDNS DNS Server Documentation=https://coredns.io After=network-online.target # Запускаемся после докера, чтобы подняться после wg-easy и интерфейс wg0 уже был на месте After=docker.service Wants=network-online.target [Service] Type=simple ExecStart=/usr/local/bin/coredns -conf /etc/coredns/Corefile Restart=on-failure RestartSec=5 # Разрешение на привязку к порту 53 AmbientCapabilities=CAP_NET_BIND_SERVICE # Запускаем отдельным юзером User=coredns Group=coredns [Install] WantedBy=multi-user.target EOF
Добавляем юзера и запускаем сервис:
sudo useradd -r -s /usr/sbin/nologin -d /nonexistent coredns sudo systemctl daemon-reload sudo systemctl enable --now coredns sudo systemctl status coredns
Шаг 5: Synapse + PostgreSQL + Element Web
Создаем рабочую директорию и генерируем начальный конфиг Synapse:
mkdir -p ~/matrix && cd ~/matrix docker run -it --rm \ -v ./data:/data \ -e SYNAPSE_SERVER_NAME=chat.team.internal \ -e SYNAPSE_REPORT_STATS=no \ matrixdotorg/synapse generate
Редактируем data/homeserver.yaml. Ключевые секции, которые нужно изменить:
server_name: "chat.team.internal" database: name: psycopg2 args: user: synapse password: "СМЕНИТЬ_НА_НАДЕЖНЫЙ_ПАРОЛЬ" database: synapse host: postgres cp_min: 5 cp_max: 10 media_storage_providers: - module: s3_storage_provider.S3StorageProviderBackend store_local: true store_remote: true store_synchronous: true config: bucket: matrix-media endpoint_url: https://s3.cloud.ru region_name: ru-central-1 access_key_id: "Key ID" secret_access_key: "Key Secret" # Отключаем открытую регистрацию. Пользователей создаем вручную # или позже включим регистрацию по токену. enable_registration: false # Отключаем федерацию — сервер только для нашей команды federation_domain_whitelist: [] listeners: - port: 8008 type: http tls: false x_forwarded: true resources: - names: [client] compress: false # global_factor < 1.0 уменьшает размер всех кешей пропорционально. # Для 15 пользователей 0.5 более чем достаточно, экономит около 200–300 MB RAM. caches: global_factor: 0.5 # Дальше идут настройки секретных ключей и прочего, что сгенерилось автоматом, мы это не трогаем
Для S3 storage provider нужен пакет synapse-s3-storage-provider, которого нет в базовом образе. Собираем свой:
cat > Dockerfile.synapse << 'EOF' FROM matrixdotorg/synapse:latest RUN pip install --no-cache-dir synapse-s3-storage-provider EOF
Позже стоит добавить крон джобу для подчистки данных, которые ушли в S3, чтобы не засорять VPS:
docker exec synapse s3_media_upload update /data 30d
Конфиг Element Web (в element-config.json):
"default_server_config": { "m.homeserver": { "base_url": "https://chat.team.internal", "server_name": "chat.team.internal" } }, "disable_guests": true, "disable_3pid_login": true, "brand": "Team Chat", "default_theme": "light", "room_directory": { "servers": ["chat.team.internal"] } }
Конфиг для TURN-сервера, чтобы нормально работали звонки:
mkdir -p ~/matrix/coturn # Генерим секрет openssl rand -hex 32 cat > ~/matrix/coturn/turnserver.conf << 'EOF' # Слушаем на VPN-интерфейсе listening-ip=10.8.0.1 # Порт TURN listening-port=3478 # Диапазон портов для media relay min-port=49152 max-port=49200 # Авторизация -- static secret, разделяемый с Synapse use-auth-secret static-auth-secret=<сгенеренный секрет> # Realm -- любое имя, обычно совпадает с доменом realm=chat.team.internal # Логирование log-file=stdout no-cli EOF
Докинем в homeserver.yaml:
turn_uris: - "turn:10.8.0.1:3478?transport=udp" - "turn:10.8.0.1:3478?transport=tcp" turn_shared_secret: <тот же секрет> turn_user_lifetime: 86400000 turn_allow_guests: false
docker-compose.yml для всего стека Matrix:
services: postgres: image: postgres container_name: matrix-postgres environment: POSTGRES_USER: synapse POSTGRES_PASSWORD: changeme POSTGRES_DB: synapse POSTGRES_INITDB_ARGS: "--encoding=UTF8 --lc-collate=C --lc-ctype=C" volumes: - postgres-data:/var/lib/postgresql restart: unless-stopped synapse: build: context: . dockerfile: Dockerfile.synapse container_name: synapse depends_on: - postgres volumes: - ./data:/data restart: unless-stopped element-web: image: vectorim/element-web container_name: element-web volumes: - ./element-config.json:/app/config.json:ro restart: unless-stopped coturn: image: coturn/coturn:alpine container_name: coturn network_mode: host volumes: - ./coturn/turnserver.conf:/etc/coturn/turnserver.conf:ro restart: unless-stopped volumes: postgres-data:
Шаг 6: Caddy с внутренним CA
Наши сервисы живут за VPN и не доступны из интернета, поэтому получить сертификат от Let's Encrypt через стандартный HTTP-01 challenge невозможно. Можно было бы использовать DNS-01 challenge (создавать TXT-записи через API DNS-провайдера), но это добавляет внешнюю зависимость и заметно усложняет настройку. Пока обойдемся без этого.
Проще так: Caddy умеет работать как собственный удостоверяющий центр (CA). Директива tls internal заставляет Caddy сгенерировать корневой сертификат (срок жизни — 10 лет), промежуточный сертификат и leaf-сертификаты для каждого сайта автоматически, без внешних запросов. Обновление leaf-сертификатов происходит прозрачно само. Единственное, нужно один раз установить корневой сертификат Caddy на устройства участников команды.
Caddyfile:
{ # Все сайты по умолчанию используют внутренний CA local_certs # Опционально: задаем имя CA (видно в системном хранилище сертификатов) pki { ca local { name "Team Internal CA" root_cn "Team Internal Root CA" } } } # Synapse API chat.team.internal { reverse_proxy synapse:8008 } # Element Web element.team.internal { reverse_proxy element-web:80 }
Добавляем Caddy в docker-compose стека Matrix (стандартный образ, без кастомной сборки, tls internal работает из коробки):
caddy: image: caddy:2-alpine container_name: caddy ports: # Слушаем только на VPN-интерфейсе - "10.8.0.1:443:443" - "10.8.0.1:80:80" volumes: - ./Caddyfile:/etc/caddy/Caddyfile:ro - caddy-data:/data - caddy-config:/config restart: unless-stopped volumes: caddy-data: caddy-config:
Порты привязаны к 10.8.0.1, из интернета к ним доступа нет. Кастомная сборка Caddy не нужна: tls internal — встроенная функция.
После первого запуска Caddy извлекаем корневой сертификат CA:
docker compose cp caddy:/data/caddy/pki/authorities/local/root.crt ./team-root-ca.crt
Этот файл team-root-ca.crt нужно один раз установить на каждое устройство в команде. Сертификат действует 10 лет, так что повторная установка не потребуется. Шутить про Третью мировую не буду, сами дошутите.
# Linux (Ubuntu/Debian) sudo cp team-root-ca.crt /usr/local/share/ca-certificates/team-root-ca.crt sudo update-ca-certificates # macOS sudo security add-trusted-cert -d -r trustRoot \ -k /Library/Keychains/System.keychain team-root-ca.crt # Windows (PowerShell от имени администратора) Import-Certificate -FilePath team-root-ca.crt -CertStoreLocation Cert:\LocalMachine\Root
На iOS: отправляем файл через AirDrop или скачиваем через VPN, устанавливаем профиль в «Настройки» → «Основные» → «VPN и управление устройством», затем включаем доверие в «Настройки» → «Основные» → «Об этом устройстве» → «Доверие сертификатам».
На Android: «Настройки» → «Безопасность» → «Установить сертификат» → «Сертификат ЦС». Система покажет предупреждение: «Сеть может отслеживаться». Это ок при установке любого стороннего CA.
Для небольшой команды это одноразовая операция, которую удобно описать в той же инструкции, что и подключение к VPN. Я добавил team-root-ca.crt в общую matrix-комнату с закрепленным сообщением.
Шаг 7: первый запуск и создание пользователей
cd ~/matrix docker compose up -d # Ждем инициализации (~ 30 сек.), затем создаем администратора docker exec -it synapse register_new_matrix_user \ -c /data/homeserver.yaml \ -u admin -a \ http://localhost:8008
Программа спросит пароль интерактивно.
Подключаемся к VPN и наконец заходим на https://element.team.internal. И радуемся, что работает!
Входим как admin. Создаем Space для команды, а внутри него — комнаты по проектам.
Для приглашения остальных участников включаем регистрацию по токену:
# homeserver.yaml enable_registration: true registration_requires_token: true
Перезапускаем Synapse:
docker compose restart synapse
В настройках находим и запоминаем токен доступа:
Делаем запрос на регистрационный токен:
curl -X POST https://chat.team.internal/_synapse/admin/v1/registration_tokens/new \ -H "Authorization: Bearer ВАШ_ACCESS_TOKEN" \ -H 'Content-Type: application/json' \ -d '{"uses_allowed": 5, "expiry_time": null}'
И получаем что-то типа этого:
{"token":"uyRtuFpu.B~EVaVk","uses_allowed":5,"pending":0,"completed":0,"expiry_time":null}
С этим токеном уже можно зарегистрироваться:
Приглашение от админа — и мы в чате!
С этим аккаунтом уже можно и с телефона зайти. Не закрывайте при этом сессию на ПК, потому что там будет занятный квест с подтверждением устройства: мы же все-таки хотели безопасности.
Я тут себе подчеркнул: надо будет изучить возможность добавления аккаунта на мобильные устройства через QR-код, чтобы было удобнее.
Шаг 8: подключение команды
Инструкция для участника занимает 5 минут:
1. Установить WireGuard-клиент (Windows, macOS, Linux, iOS, Android — все поддерживаются).
2. Импортировать конфигурацию через QR-код из wg-easy.
3. Подключиться к VPN.
4. Открыть https://element.team.internal в браузере.
5. Зарегистрироваться по токену.
6. Сохранить security key (ключ восстановления шифрования). Это критически важно, так как без него зашифрованные сообщения будут утеряны навсегда при потере всех активных сессий.
На мобильных устройствах: Element X (iOS/Android), после подключения к VPN указать homeserver URL. На Android пуш-уведомления работают через ntfy (UnifiedPush), полностью без google-зависимости. На iOS пуши проще оставить через стандартный matrix.org Sygnal relay. Содержимое сообщений при этом не передается — показывается только факт нового сообщения.
Модель авторизации
Немножко подробнее расскажу про концепт. В моем стеке нет единого центра авторизации. Доступ контролируется на двух независимых уровнях, и о каждом нужно помнить отдельно.
Первый уровень — WireGuard. Доступ к VPN определяется наличием конфигурационного файла с приватным ключом. Никаких логинов и паролей. Кто владеет .conf-файлом, тот в сети. Это одновременно и плюс (простота, нет кредов для фишинга), и минус (потерянный ноутбук с WireGuard-конфигом = у кого-то другого доступ к внутренней сети до момента отзыва ключа).
Второй уровень — Matrix/Synapse. У каждого пользователя есть аккаунт с паролем. Даже попав в VPN, без валидного аккаунта в Synapse прочитать переписку или отправить сообщение нельзя. E2EE добавляет третий слой: даже администратор сервера не может читать зашифрованные сообщения без ключей сессии.
SSO я сознательно не внедрял ПОКА ЧТО. Synapse поддерживает OpenID Connect, и можно было бы развернуть Authentik или Keycloak для единой точки авторизации. Но для 15 человек это ту мач: еще один сервис для поддержки, еще одна потенциальная точка отказа. При масштабировании до 50 человек и более это решение я, конечно, пересмотрю.
Чек-лист при уходе сотрудника
А что, если человечек ушел из команды? Тут составил универсальный чек-лист офбординга:
1. Удалить клиента в wg-easy (Admin Panel → «Удалить пользователя»). Эффект мгновенный, ключ сразу перестает приниматься сервером.
2. Деактивировать аккаунт в Synapse через Admin API:
curl -X POST https://chat.team.internal/_synapse/admin/v1/deactivate/@user:chat.team.internal -H "Authorization: Bearer $ADMIN_TOKEN" -d '{"erase": false}'
Параметр erase: false сохраняет историю сообщений в комнатах, а erase: true заменяет имя и аватар на заглушки.
3. Если есть подозрение на компрометацию устройства, меняем Shared Secret в homeserver.yaml (если использовался для регистрации) и пересоздаем registration tokens.
Этот чек-лист у нас оформлен как закрепленное сообщение в приватной комнате админов. Действий всего на две минуты. Не идеально, но для команды нашего размера ок.
Заключение: что дальше
Резюмирую, что поднять корпоративный мессенджер в облаке реально и без сверхсложной инфраструктуры. Особенно если уже есть готовый сетап с понятной документацией.
Мессенджер есть куда масштабировать: хотелось бы докинуть позже мониторинг, централизованные логи, отдельные бэкапы и, в конце концов, внедрить ИИ-агента под пуши CI/CD. Не все из этого пока что до конца понимаю, как реализовать эффективнее, особенно в рамках того, что хочу разворачиваться на той же платформе. Есть вопросы по продуктам, которые, надеюсь, смогу разобрать на конфе GoCloud. Может, даже допилю что-то в рамках практической лабораторной работы, поспрашиваю специалистов от платформы и других коллег.
Хочу написать вторую часть с доработками, так что, если интересно, дайте знать в комментах. Критики, вопросов, советов — всего этого тоже жду. Может, кто-то уже поднимал для своей команды мессенджер? Делитесь опытом.
