Технические детали

Как устроен Qeli

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

Как работает соединение

Установка соединения шаг за шагом

Сервер подтверждает свою подлинность до того, как клиент отправит пароль, — перехватить пароль посреднику не удастся. Порядок шагов важен для безопасности.

1

Знакомство

Клиент ⇄ Сервер

Соединение начинается как обычный заход на сайт по HTTPS — обмен временными ключами.

2

Отпечаток

внутри

Подлинность привязана к хешу всего рукопожатия — подмена ломает соединение.

3

Сервер → клиент

Сервер → Клиент

Сервер доказывает владение ключом, клиент сверяет с закреплённым — до отправки пароля.

4

Вход клиента

Клиент → Сервер

По защищённому каналу — логин и пароль; проверка Argon2id и доступ по профилю.

Передача данных

Клиент ⇄ Сервер

Каждый пакет шифруется и уходит в выбранном транспорте — HTTPS, WebSocket или QUIC.

Транспортные режимы

Один протокол — шесть транспортных режимов

Режим определяет, как трафик туннеля выглядит со стороны сети, и переключается одной настройкой — одинаково на сервере и клиенте. По умолчанию работает reality-tls; остальные — на выбор под задачу или как запасные каналы.

флагманTCP · TLS 1.3

Настоящий TLS 1.3

reality-tls · браузерный TLS 1.3 (rustls)

Главный режим Qeli: клиент шлёт браузерное рукопожатие TLS 1.3 (отпечаток JA4 t13d1516h2_8daaf6152771), а сервер терминирует настоящий TLS 1.3 (rustls) и несёт туннель внутри. Это полноценный TLS-канал — обычное защищённое HTTPS-соединение современного уровня. Работает на всех клиентах (Linux, Android, Windows, macOS) через общий realtls-движок.

в трафике ClientHello (Chrome JA4) → TLS 1.3 (rustls) зашифрованный flight → туннель внутри настоящего TLS
  • Настоящее рукопожатие TLS 1.3 с отпечатком JA4 браузера Chrome
  • Сервер терминирует TLS (rustls), туннель идёт внутри
  • Единый realtls-движок на всех клиентах (Linux, Android, Windows, macOS)
~482 ↑ / 417 ↓ Мбит/с · цена настоящего TLS (двойной AEAD на клиенте)
для доверенных сетей · новоеTCP · базовый

Базовый туннель — plain

plain · голый шифрованный туннель

Сырой обмен X25519 и голые записи [len][nonce][ct] — никакой TLS-обёртки и лишних слоёв. Самый быстрый и дешёвый по CPU режим (≈ как fake-tls по скорости). Нужен там, где дополнительный транспортный слой не требуется: доверенная сеть, внутренний канал. Только TCP.

в трафике обмен X25519 → [len][nonce][ct] · без TLS-обёртки
  • Максимальная скорость, минимум накладных расходов
  • Без дополнительного транспортного слоя — это базовый туннель
~571 ↑ / 714 ↓ Мбит/с · самый дешёвый по CPU
запасной · лёгкийTCP · уровень 1

TLS-совместимый транспорт

fake-tls · TLS-совместимый

Соединение начинается с рукопожатия в формате TLS 1.3: клиент шлёт ClientHello с именем сайта (SNI), обменом ключами X25519 (key_share) и GREASE-значениями. Порядок TLS-расширений рандомизируется. Дальше данные идут в TLS-записях типа Application Data.

в трафике ClientHello · SNI · x25519 · GREASE порядок расширений рандомизирован данные → TLS record 0x17 (application_data)
  • Данные передаются в TLS-записях
  • Порядок TLS-расширений рандомизирован
  • Минимальная структура — почти нет накладных расходов
Транспортный слой почти бесплатен · ~563 ↑ / 697 ↓ Мбит/с
приватный транспортTCP · уровень 2

Дополнительное шифрование (obfs)

obfs · дополнительный криптослой ChaCha20

Весь поток дополнительно шифруется потоковым ключом ChaCha20 на общем секрете (PSK). Начало оформлено как рукопожатие WebSocket Upgrade: клиент шлёт GET … Upgrade: websocket, сервер отвечает 101 Switching Protocols с Sec-WebSocket-Accept. Путь, Host, User-Agent и ключ рандомизированы.

в трафике GET /<rand> HTTP/1.1 · Host/UA/key рандом Upgrade: websocket → 101 Switching Protocols далее: поток ChaCha20 XOR
  • Начало совместимо с WebSocket — печатаемый HTTP-текст
  • Дополнительный слой ChaCha20 поверх основного шифрования
  • Лимит потока — 256 ГиБ на направление, затем безопасный реконнект
Двойное шифрование · ~498 ↑ / 582 ↓ Мбит/с (−12% / −16%)
проксированиеTCP · уровень 3

Разделение порта (reality)

reality · разделение порта

Сервер криптографически опознаёт свой клиент по токену в session_id ClientHello. Неопознанные подключения перенаправляются на указанный хост. Токен представляет собой AEAD-шифротекст (short_id, timestamp), связанный с DH-обменом. В режиме reality-tls поверх прокси-слоя добавляется терминирование настоящего TLS 1.3 (rustls).

в трафике токен в session_id → опознан → туннель нет токена → проксируем на реальный сайт :443
  • Неопознанные подключения перенаправляются на сторонний хост
  • Опознание криптографическое, защита от повторного воспроизведения
  • Доступен режим с настоящим TLS 1.3 (reality-tls)
Один peek на accept · скорость наравне с plain/fake-tls (~577 ↑ / ~721 ↓ Мбит/с)
UDPUDP · уровень 2

UDP в форме QUIC

quic · UDP в формате QUIC v1

Для UDP датаграммы оформляются под заголовок QUIC версии 1. Зашифрованная датаграмма принимает форму QUIC short-header: первый байт — с установленным fixed-битом QUIC, затем 12-байтовый nonce как connection-id, далее защищённые данные. Начальная датаграмма добивается до ≥1200 байт (защита от усиления атак).

в трафике [flag 0x40|x][nonce:12 как conn-id][protected] initial ≥ 1200 байт (анти-амплификация)
  • UDP-транспорт с заголовками QUIC v1
  • Первый байт — в диапазоне QUIC
  • Защита от усиления атак через padding ≥1200 байт
~400 Мбит/с при <0.5% потерь · насыщение ~500
Безопасность

Криптография и честная защита

Современный криптостек: постквантовый обмен ключами (X25519 + ML-KEM-768), эфемерные ключи, шифрование с проверкой целостности и настоящий TLS в режиме REALITY. Вот что едет в каждом пакете.

заголовоктранспорт
nonce12 байт · скрыт
зашифрованные данные + тегChaCha20-Poly1305
паддингслучайный

Так выглядит один пакет. Ключи — X25519 + ML-KEM-768 (постквант) + HKDF-SHA256, шифр — ChaCha20-Poly1305 с проверкой целостности, пароли — Argon2id. В режиме reality-tls всё это едет внутри настоящего TLS 1.3 (внешний слой — AES-128-GCM).

X25519 X25519MLKEM768 · постквант ChaCha20-Poly1305 Argon2id reality-tls · TLS 1.3 (Chrome JA4) Channel-binding Ключ на каждый профиль

Безопасность и надёжность

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

Защита подключения

  • Закрепление ключа сервераклиент пиннит ключ — подменный сервер не пройдёт
  • Привязка к рукопожатиюподмена данных в канале рвёт соединение (анти-MITM)
  • Обязательная проверка ключаклиенты без ключа отклоняются, ключ скрыт от сканеров

Доступ и атаки

  • Раздельный доступпрофили изолированы — чужой профиль недоступен
  • Защита от подбора пароляблокировка «пользователь + адрес», пароли на Argon2id
  • Защита от усиления атаксервер нельзя превратить в DDoS-усилитель

Надёжность связи

  • Автопереподключениесмена Wi-Fi и мобильной сети не рвёт сессию
  • Устойчивый к сбоям DNSинтернет не пропадает после падения программы
  • Скрытый счётчик пакетовнет отпечатка, по которому ловят самодельные VPN
Скорость

Измерено, а не обещано

Замеры на двух одинаковых серверах: по 2 ядра процессора, канал около 1 Гбит/с. Версия 0.7.1 (бета), 12 июня 2026 года.

Скорость по протоколу TCP в разных режимах

отдача (Мбит/с) загрузка (Мбит/с)
plainбазовый
fake-tlsпод HTTPS
realityproxy
obfsприватный
reality-tlsнастоящий TLS

plain, fake-tls и reality (proxy) — самые быстрые (~563–577 ↑ / ~697–721 ↓). Полностью зашифрованный режим (obfs) теряет 12–16% на двойном шифровании. У reality-tls загрузка ниже (~417 ↓) — цена настоящего TLS внутри туннеля (двойной AEAD на клиенте).

Протокол UDP: потери при росте скорости

обычный выравнивание под QUIC

До 300 Мбит/с — практически без потерь (<0.15%). На 400 держит <0.5% потерь, к 500 насыщается (3–4%) — расшифровка не успевает на одном ядре процессора.

~1.3 мс
Дополнительная задержка (без VPN <0.3 мс)
~34%
Загрузка одного ядра процессора на расшифровке
7–8 MB
Память процесса-воркера (RSS)

Узкое место — расшифровка на одном ядре процессора (worker ~34% в среднем, пики ~60%). На более мощном оборудовании скорость будет выше. Для сравнения, без VPN на том же стенде: TCP около 20 Гбит/с, UDP около 1 Гбит/с. 161 unit-тест зелёный, e2e всех режимов подтверждён на лабе.

Сравнение

Qeli рядом с другими решениями

Без маркетинга. Показатели Qeli измерены на нашем тестовом стенде; данные других решений — типовые опубликованные значения на сопоставимом оборудовании (2 ядра процессора, канал около 1 Гбит/с). В сравнение включены и приватные туннели, и обычные VPN — для ориентира.

Чистый WireGuard и OpenVPN — базовые VPN без дополнительного транспортного слоя. Здесь они приведены как ориентир по скорости. Приватный транспорт для WireGuard добавляет отдельный проект — AmneziaWG, он и включён в сравнение наравне с другими туннелями.

Скорость передачи (TCP, 2 ядра)

WireGuardбазовый
AmneziaWG
Hysteria 2QUIC
Qeli
Shadowsocks
OpenVPNбазовый
V2Ray

WireGuard быстрее всех как базовый VPN. Среди приватных туннелей Qeli держит ~575 ↑ / ~715 ↓ Мбит/с стабильно — выше типового V2Ray и наравне с лучшими.

Сравнение возможностей

Возможность WireGuard AmneziaWG OpenVPN Shadowsocks V2Ray Hysteria 2 Qeli
Полноценный VPN (а не прокси)дададапроксипроксипроксида
Скорость★★★★★★★★★★★★★★★★★★★★★★★★★★
Приватный транспортнет★★★нет★★★★★★★★★★★★★★★
Несколько транспортных режимовнетодиннетплагины★★★★частично★★★★ plain / fake-tls / obfs / reality / reality-tls / quic
Настоящий TLSнетнетреальный TLSчерез плагинTLS + REALITYпод HTTP/3да reality-tls · Chrome JA4
Встроенная панель управлениянетприложениенетнетнетнетда
Защита от подбора паролянетнетплагиннетнетнетда
Закрепление ключа сервераключ узлаключ узласертификатпарольдасертификатда
Раздельный доступ по профилямнетнетнетнетчастичнонетда
Несколько профилей в одной службенетнетнетнетданетда
Работа в ядре системыдаданетнетнетнетнет
Независимый аудит безопасности★★★★★★★★★★★★★★★нет
Постквантовая криптографиянетнетнетнетнетнетПостквантовое шифрование клиент отправляет ML-KEM-768 · сервер ожидает

Настройка — единый текстовый формат

Один формат настроек для сервера, клиента и списка пользователей. Настройки клиента — это та же ссылка для подключения и QR-код.

настройки клиента
# минимальный набор настроек
[qeli]
server = vpn.example.com:443
proto  = tcp
mode   = obfs
front  = websocket
obfs   = ОБЩИЙ-СЕКРЕТНЫЙ-КЛЮЧ
user   = alice
pass   = ••••••••
key    = 33f399e6…d532450 # закреплённый ключ сервера
ссылка для подключения
# одна ссылка → QR-код → импорт в клиент
qeli://alice:pass@vpn.example.com:443
  ?proto=tcp
  &mode=obfs
  &front=websocket
  &obfs=ОБЩИЙ-СЕКРЕТНЫЙ-КЛЮЧ
  &sni=www.google.com
  &key=33f399e6…d532450

# создаётся в панели управления или командой:
$ qeli add-client alice
← Вернуться к обзору продукта