Mystic — наш собственный VPN-протокол: чем он отличается и почему код закрыт на три года

Мы делаем Mystic — собственный VPN-протокол и переиспользуемое ядро на Rust для наших VPN-продуктов. 21 октября 2026 года мы закончили спецификацию: требования, формат протокола, архитектуру, модель угроз и план тестирования. Следующий шаг — реализация.

Это анонс экспериментального протокола, а не готового продукта. Замеров пока нет, и мы сознательно не делаем заявлений о скорости или доступности, которые не измерили. Ниже рассказываем, зачем нам свой протокол, как он устроен, чем отличается от существующих, почему мы будем использовать его в своих продуктах и почему исходный код останется закрытым как минимум три года.

Зачем нам свой протокол

Сейчас наши VPN-приложения работают на чужих движках. Это хорошие движки, но каждый создавался под свои условия: одни — быстрые UDP-туннели, другие передают трафик поверх TLS или QUIC, третьи — прокси, а не полноценные сетевые туннели. Продукту, который должен работать в очень разных сетях, приходится совмещать несколько таких движков, и у каждого своя конфигурация, свой жизненный цикл и свои отказы.

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

Что такое Mystic

Mystic — полноценный L3-туннель: он передаёт IPv4- и IPv6-трафик всего устройства, а DNS идёт внутри туннеля. Если туннель падает, клиент блокирует прямой выход в сеть, включая IPv6 и DNS, а не пропускает трафик мимо него.

Главные решения в устройстве:

• ✦Стандартная криптография. Рукопожатие — Noise IK из того же фреймворка Noise, на котором построен WireGuard. Транспорты используют обычные TLS 1.3 и QUIC. Своих шифров мы не изобретаем.
• ✦Три настоящих транспорта. Обычный UDP для скорости, HTTP/3 поверх QUIC и HTTP/2 поверх TLS 1.3. Это полноценные реализации протоколов, а не имитация их заголовков.
• ✦Одна логическая сессия. Когда путь деградирует, соединение переходит на другой транспорт. Сессия и IP-адрес пользователя внутри туннеля остаются прежними, а у каждого пути свои ключи.
• ✦Адаптивные режимы. По умолчанию работает лёгкий режим, цель которого — скорость, близкая к WireGuard. Режимы с маскировкой включаются, когда сеть становится хуже.
• ✦Маскировка по реальным записям. В более сильных режимах размеры пакетов и паузы между ними следуют статистическим профилям, записанным с реального трафика. Профили подписаны, и принимаются только проверенные.
• ✦Жёсткий бюджет на лишний трафик. Выравнивание и фоновый трафик могут добавить не больше 10% к полезным байтам в каждом направлении за сессию. Фоновый трафик идёт только внутри аутентифицированного туннеля и никогда не отправляется сторонним сервисам.
• ✦Контроль у оператора. Каждая нода хранит свой список пользователей. Отключение или удаление пользователя спроектировано так, чтобы останавливать все его соединения на всех транспортах в течение секунды, а временная недоступность бэкенда не отключает тех, у кого доступ уже есть.
• ✦Переносимое ядро. Ядро на Rust не зависит от TUN-устройств, базы данных, HTTP API и системных вызовов Linux. Один и тот же код должен работать сейчас на Linux, а позже — внутри приложений для iOS и Android.

Чем Mystic отличается от существующих протоколов

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

Мы будем сравнивать Mystic с этими протоколами на одном железе, с зафиксированными версиями и настройками. Методику планируем публиковать вместе с результатами — включая случаи, где Mystic проигрывает.

Что мы обещаем и чего не обещаем

Для первой закрытой беты мы поставили измеримые цели:

• ✦в лёгком режиме — не меньше 80% пропускной способности WireGuard в пользовательском пространстве на той же машине;
• ✦не больше 5 мс добавленной задержки на 95-м перцентиле;
• ✦не больше 10% лишнего трафика на выравнивание и фоновый трафик;
• ✦отзыв доступа в течение одной секунды.

Это цели приёмки, а не результаты. Если прототип их не достигнет, мы оставим в приложениях существующие протоколы и не будем переводить пользователей на Mystic.

Не менее важно, чего Mystic не обещает. Он не «необнаружим»: настоящие TLS и QUIC и аккуратная маскировка усложняют анализ трафика, но не делают его невозможным, и этот риск мы будем измерять на данных, на которых система не настраивалась. Он не поможет, если IP-адрес сервера заблокирован на всех транспортах. И это не инструмент анонимности: как и в любом одноузловом VPN, нода видит ваш трафик на выходе из туннеля. Что мы можем обещать — минимум логов: нода не записывает адреса назначения и содержимое трафика, в метриках нет меток отдельных пользователей, а рабочие логи хранятся семь дней.

Почему мы будем использовать его в своих продуктах

• ✦Одно ядро для всех приложений. Мы перестаём поддерживать отдельные интеграции чужих движков и получаем один жизненный цикл сессии на Linux, iOS и Android.
• ✦Свой формат протокола и SDK. Мы сами решаем, когда и как меняется протокол, и не ждём чужого роадмапа.
• ✦Управляемая стоимость. Лишний трафик всегда в известном бюджете, поэтому мощности серверов и расходы можно планировать.
• ✦Интеграция без переписывания. Mystic подключается к нашему существующему бэкенду через API управления. Биллинг и аккаунты остаются там, где были.
• ✦Быстрый контроль доступа. Отзыв доступа и смена ключей — часть протокола, а не надстройка.

Переход будет постепенным и по выбору. Первые пользователи получат Mystic только после независимой проверки безопасности, а существующие протоколы останутся в наших приложениях как альтернатива.

Почему код закрыт минимум на три года

Мы не будем публиковать исходный код Mystic как минимум три года, то есть не раньше октября 2029-го. Откроем ли мы его после этого, будет зависеть от зрелости протокола.

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

• ✦Формат протокола будет меняться. Первая версия экспериментальная, и независимая проверка может потребовать изменений. Опубликовать её сейчас — значит пригласить сторонние реализации формата, который мы собираемся ломать.
• ✦Сначала проверка, потом чужие проекты. Мы не хотим, чтобы другие строили свои продукты на протоколе, который ещё не прошёл внешний криптографический аудит и реальные замеры.
• ✦Фокус. Мы небольшая студия. Поддержка открытого протокола — это issues, совместимость и работа с сообществом, а сейчас это время нужно продукту.
• ✦Он сделан в первую очередь для наших продуктов. Ядро, API и инструменты оператора спроектированы вокруг нашего бэкенда и наших приложений.

Пока что мы планируем рассказывать здесь о ходе работы и делиться результатами замеров, когда они появятся.

Что дальше

План состоит из пяти этапов. Первый — воспроизводимая сборка и контракты. Второй — зашифрованный UDP-туннель с защитой от повторов. Третий добавляет HTTP/3 и HTTP/2, перенос сессии и мгновенный отзыв доступа. Четвёртый приносит записанные профили трафика и бюджеты. Пятый — замеры, фаззинг, восстановление после сбоев и независимая проверка безопасности, по итогам которых решается вопрос о закрытой бете. Наша оценка — 12–16 инженерных недель плюс внешний аудит. Дату релиза мы не называем: часть работы — исследование, а аудит может изменить протокол.

Первый релиз — Linux-сервер и консольный клиент. Приложения для iOS и Android на том же ядре выйдут отдельным релизом.