Свой сервер Matrix

Свой сервер Matrix поднимают, чтобы переписка больше не хранилась у компании — и с этой задачей он справляется в точности так, как обещано. Удивление приходит позже, когда вы понимаете, что именно установили: homeserver — это не приватная коробка, которая просто умеет в чат. Это узел репликации в публичной сети, а федерация ведёт себя куда больше как протокол публикации, чем ожидает большинство новых администраторов.

Всё это не довод против собственного сервера — это довод в пользу того, чтобы разворачивать его осознанно. Приватность, которую вы получаете, реальна, но конкретна: контроль переходит к вам, аккаунт больше никто со стороны не закроет, а юридические вопросы попадают под юрисдикцию, которую выбрали вы, а не компания. Приватность, которую вы не получаете, столь же конкретна, и почти вся она умещается в разрыве между «сообщения зашифрованы» и «никто не может понять, кто с кем разговаривает». Это руководство разбирает обе половины, а затем — эксплуатационные детали, от которых зависит, останется ли сервер здоровым спустя год.

Что на самом деле меняет свой сервер

Начните с разделения угроз: на одни homeserver отвечает полностью, на другие — частично, а на третьи не отвечает вовсе. Таблица ниже — честная версия питча, и её стоит прочитать до того, как вы выберете железо, а не после.

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

Федерация — это протокол репликации в одежде протокола для чата

Вот механика, которая объясняет большинство сюрпризов. Когда ваш пользователь вступает в комнату, размещённую на другом сервере, ваш сервер не запрашивает сообщения по требованию, как почтовый клиент. Он входит в комнату как участник распределённого графа событий, а затем забирает и сохраняет копию событий комнаты, её состава участников и достаточно истории состояния, чтобы проверять всё, что произойдёт дальше. С этого момента ваша машина хранит реплику, и то же самое делает каждый другой участвующий сервер.

Последствия идут в обе стороны, и ни одно из них не очевидно. Данные, которые генерируют ваши пользователи — отображаемое имя, аватар, вход и выход из комнаты, метки времени, реакции — копируются на каждый сервер с участником в этой комнате и остаются в его базе данных независимо от того, что вы потом удалите у себя. Redaction — это просьба к другим серверам, а не команда. В федерации из независимо управляемых серверов не существует «отменить отправку», и ожидать этого — самое частое заблуждение насчёт протокола.

В обратную сторону: вступление в большие публичные комнаты означает импорт чужой истории на ваш диск. Именно поэтому у совершенно нового homeserver с тремя пользователями база данных может занимать десятки гигабайт — не потому что эти трое много написали, а потому что они вступили в комнаты на пятьдесят тысяч участников с годами накопленного состояния. Осознанный выбор комнат — это в той же мере вопрос ёмкости хранилища, что и вопрос приватности.

Что защищает шифрование, а что остаётся открытым

Matrix шифрует содержимое сообщений с помощью Megolm, и в приватных комнатах это включено по умолчанию. Это защищает то, что людей волнует больше всего, и работает по-настоящему: ваш сервер хранит шифротекст, который не может прочитать сам, а это реальное и полезное свойство, если сервер — это арендованное железо. С «конвертом» вокруг сообщения всё иначе, и разрыв здесь шире, чем признаёт большинство кратких описаний.

Практический вывод: шифрование защищает что, а федерация публикует кто, когда и как часто. Для большинства сообществ такой размен вполне приемлем, и честность здесь — как раз главное. Но если в вашей модели угроз чувствителен именно социальный граф, федеративный протокол структурно не той формы, и никакой параметр конфигурации этого не изменит.

Synapse, Dendrite или Conduit — что запускать на практике

На практике имеют значение три реализации, и выбор между ними — в основном вопрос ресурсов, а не философии.

• Synapse — эталонный сервер, написан на Python, и единственный, где все функции работают с первого дня. Он же самый прожорливый: память растёт вместе с числом и размером комнат, в которые вступают ваши пользователи, а загруженному серверу рано или поздно понадобится разделение на worker-процессы. Выбирайте его, если вам нужны spaces, инструменты модерации, мосты и admin API, работающие в точности так, как описано в документации.
• Dendrite — переписанная версия на Go. Заметно легче Synapse и вполне пригодна для небольшого сервера, но ценой некоторого отставания по функциям. Разумный средний вариант, если Synapse кажется избыточно тяжёлым для реального числа ваших пользователей.
• Conduit и его активно развиваемый форк conduwuit написаны на Rust и поставляются одним бинарником со встроенной базой данных. Они без нареканий тянут семейный или небольшой коммьюнити-сервер на самом младшем из наших тарифов. Плата за это — меньшая экосистема: часть админ-инструментов и некоторые мосты рассчитаны только на Synapse.

Для первого сервера на горстку пользователей софт семейства Conduit на небольшом VPS — самый безболезненный путь к тому, что работает и остаётся дешёвым. Если же вы рассчитываете на рост — публичное сообщество, компания, проект с мостами — начинайте сразу с Synapse и пропустите миграцию: переход между реализациями позже — это экспорт и пересборка с нуля, а не правка конфига.

Настройка делегирования, в которой ошибаются все

Matrix разделяет имя в ваших user ID и машину, которая фактически обслуживает трафик, и перепутать их местами — самая распространённая необратимая ошибка при самостоятельном хостинге. Ваш server_name — это домен, который стоит после двоеточия в каждом user ID на вашем сервере. Он становится частью вашей идентичности в федерации в момент подписи первого события, и его нельзя изменить задним числом без отказа от всех аккаунтов и комнат на этой машине.

Почти всегда нужна такая схема: server_name — это ваш голый домен, а софт при этом работает на поддомене. Связать их можно делегированием, одним из двух способов. Простой — статический JSON-файл по адресу /.well-known/matrix/server на голом домене, указывающий реальный хост и порт. Альтернатива — DNS-запись _matrix._tcp, указывающая туда же. Отдайте также клиентский файл по адресу /.well-known/matrix/client, чтобы приложения находили homeserver по одному только адресу.

Честный расчёт размера

В обычном режиме Matrix упирается не в CPU, а в память и поведение базы данных. Опубликованные цифры для Synapse — полезный нижний порог: около 2 ГБ RAM на старте, порядка 4 ГБ при десяти-пятидесяти активных пользователях и 8 ГБ и больше свыше сотни. Серверы семейства Conduit укладываются намного ниже. Эти цифры не показывают, что потребление зависит от комнат, в которых состоят пользователи, а не от числа зарегистрированных аккаунтов — пять пользователей в сотне больших публичных комнат обойдутся куда дороже, чем пятьдесят пользователей в горстке приватных.

Отсюда два практических правила. Разместите базу данных на быстром хранилище и оставьте запас для роста: паттерн записи здесь небольшой и постоянный, а не всплесками. И считайте размер не под сегодняшнее число пользователей, а под комнаты, в которые они вступят за первый месяц — сюрприз обычно кроется именно там. Наш стартовый тариф спокойно тянет небольшой Conduit или Dendrite, а инстанс Synapse для реального сообщества стоит брать от среднего тарифа и выше — страница про хостинг чатов перечисляет, какой тариф мы рекомендуем под каждый из этих сценариев.

Аптайм здесь важнее, чем для большинства нагрузок: упавший чат-сервер не просто недоступен — он молча пропускает события, которые другие серверы какое-то время будут пытаться доставить повторно, а затем перестанут предлагать вовсе. Федерация прощает минуты простоя и не прощает дни.

Медиахранилище — это диск-бомба замедленного действия

Любое изображение, видео или файл, прошедшие через комнату, где состоят ваши пользователи, могут осесть в кэше на вашем диске — включая удалённые медиафайлы, которые ваши же пользователи ни разу не открывали. Политика хранения в Synapse по умолчанию держит их бессрочно. Результат предсказуем, но всё равно застаёт врасплох: база данных стабильна, а каталог с медиа тихо растёт, пока не заполнит весь раздел, — и тогда симптомом становится не «диск заполнен», а «сервер странно себя ведёт».

Настройте политику хранения удалённых медиа с первого дня, а не после первого простоя. Synapse выносит настройки хранения в homeserver.yaml, плюс есть admin-эндпоинты для очистки старой истории и кэшированных файлов; synapse-compress-state неожиданно много освобождает в таблицах состояния на старом сервере. Следите и за базой данных, и за путём к медиа, и настройте алерт на свободное место, а не на падение сервиса — второй симптом приходит через дни после первого.

Один параметр заслуживает осознанного решения, а не значения по умолчанию. Превью ссылок заставляют ваш сервер запрашивать любую ссылку, опубликованную в комнате, а значит, IP-адрес вашего сервера обращается к третьей стороне в тот же момент, когда кто-то вставил ссылку — в том числе ссылку, подобранную специально, чтобы посмотреть, кто клюнет. Если ваш homeserver стоит за фронтом и его реальный адрес имеет значение, взвесьте это внимательно; наше руководство про сокрытие адреса исходного сервера разбирает утечки этого класса подробнее.

Регистрация, спам и репутация, которую вы наследуете

Открытая регистрация на публичном homeserver — это приглашение, только не то, которое вам нужно. Автоматические регистрации превращают небольшой сервер в источник спама за считаные дни, и последствие не остаётся локальным: другие homeserver добавляют ваш домен в списки контроля доступа, и как только ваше имя оказывается в достаточном их числе, ваши легитимные пользователи перестают участвовать в комнатах на других серверах. Восстановить сожжённую репутацию домена куда сложнее, чем не допустить этого, — ровно как с доставляемостью почты.

Разумные настройки по умолчанию просты. Держите enable_registration выключенным для приватного сервера и выдавайте аккаунты сами. Если хотите оставить дверь открытой — поставьте фильтр: registration_requires_token превращает регистрацию в систему по приглашениям без какого-либо стороннего сервиса, а капча помогает против самой грубой части проблемы. Для комнат, которыми вы администрируете, боты модерации семейства Mjolnir и Draupnir позволяют применять бан-листы и ACL сразу на всё сообщество, а не по одной комнате за раз.

Стоит знать и обратное: наши диапазоны адресов не значатся в блок-листах Matrix ACL, которые циркулируют между homeserver, так что новый сервер стартует с чистой репутацией. А что происходит с этой репутацией дальше, определяет то, как вы ведёте регистрацию, а не то, где стоит машина.

Мосты и метаданные, которыми за них платят

Мосты — честная причина, по которой многие остаются на Matrix: один клиент для комнат, живущих в других сетях. Но они же меняют положение вашего сервера с точки зрения безопасности, и это легко упустить из виду. Мост хранит учётные данные для внешнего аккаунта и на границе, где встречаются два протокола, неизбежно обрабатывает сообщения в форме, которую может конвертировать, — а значит, процесс моста видит открытый текст трафика, зашифрованного end-to-end по обе стороны от него.

Это не повод отказываться от мостов. Это повод отнестись к хосту моста как к чувствительной инфраструктуре: если его скомпрометируют, это раскроет все аккаунты, от имени которых он работает. Каждый мост примерно удваивает потребление памяти небольшого сервера, так что закладывайте это в расчёт ёмкости, и подойдите к выбору места для него так же вдумчиво, как к самому homeserver — рассуждения из нашего руководства по выбору юрисдикции применимы здесь даже с большей силой, ведь речь о машине, которая держит учётные данные сразу нескольких сетей.

Поддержание жизни: ключи, бэкапы и обновления

У сервера Matrix есть один файл, потеря которого невосполнима, и это не связано с объёмом данных. Ключ подписи — signing.key в Synapse — это то, чем ваш сервер доказывает, что события, заявленные как исходящие от вашего домена, действительно от него исходят. Потеряете его — и уже не сможете правдоподобно быть собой: другие серверы отклонят события, подписанные посторонним, завладевшим вашим именем. Резервируйте его отдельно от всего остального и храните эту копию за пределами машины.

Обновления — рутина, но не опция. Релизы homeserver несут миграции схемы, и пропуск сразу многих версий превращает пятиминутное обновление в дело на полдня. Читайте release notes перед прыжком через версии, обновляйтесь достаточно регулярно, чтобы каждый шаг оставался небольшим, и выполните базовую гигиену хоста из чек-листа на первый час — чат-сервер это долгоживущий сервис, смотрящий в интернет, с базой данных на борту, и он заслуживает такого же отношения, как и любой другой.

Где живёт сервер — всё ещё решающий фактор

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

Это и есть практический довод выбирать локацию осознанно, а не только по задержке. Мы работаем в семи юрисдикциях, и компромиссы между ними разобраны в руководстве по выбору юрисдикции и на странице локаций. Вторая половина того же вопроса — кем провайдер вас знает: аккаунт без привязанной личности не может выдать документы, которые никогда не собирал, и именно поэтому хостинг без KYC и свой сервер коммуникаций так часто всплывают в одном разговоре. Ни то ни другое не защитит от суда, которому уже известно ваше имя, и наше руководство по OpSec прямо говорит о том, где проходит эта граница.

Коротко

Если унести с этой страницы всего шесть мыслей, вот они:

• Выберите server_name до установки чего бы то ни было — это единственное решение, которое нельзя пересмотреть.
• Делегируйте через /.well-known/matrix/server или SRV-запись и поддерживайте валидный TLS на обоих именах.
• Считайте размер под комнаты, в которые вступят пользователи, а не под их количество.
• Настройте хранение медиа с первого дня и осознанно решите вопрос с превью ссылок, а не оставляйте значение по умолчанию.
• Держите регистрацию закрытой или под токеном — восстановить сожжённую репутацию домена дорого.
• Резервируйте signing.key отдельно и никогда не откатывайте базу данных за спиной у остальной федерации.

Сделайте это — и сервер будет ничем не примечателен, а именно таким и должен быть чат-сервер. На что вы меняете эти усилия, стоит понимать трезво: не невидимость и не протокол, скрывающий, кто с кем говорит, а переписку, содержимое которой принадлежит вам, аккаунт, который не закроет никто посторонний, и машину под юрисдикцией, которую вы выбрали осознанно. Разместите homeserver там, где выбрали сами, — и пусть федерация приходит туда сама.