MasterHttpRelayVPN-RUST

Порт masterhttprelayvpn на Rust. Оригинальная утилита на Python маскирует HTTPS-трафик через бесплатное развёртывание Google Apps Script, чтобы для цензора он выглядел как обычные обращения к www.google.com. Идея та же, но в другом исполнении: единый статический бинарник, десктопный UI на egui и Android APK, который перехватывает весь системный трафик через VpnService. Оригинальный Python-проект опубликовал 2026-04-20 @masterking32; этот порт на Rust от @therealaleph появился 2026-04-21 и с тех пор обновляется ежедневно.

Главная причина обратить внимание на этот переписанный вариант: Python-клиент требует среду выполнения Python, генерацию сертификатов при первом запуске и пачку pip-зависимостей, которые пользователи из Ирана и России часто не могут скачать из-за заблокированных зеркал пакетов. Бинарник на Rust - это статический исполняемый файл размером 5-10 МБ без каких-либо внешних зависимостей. Он работает на роутерах с 32-битным MIPS и поставляется в виде Android-сборки, которую большинство пользователей могут просто установить без VPS или root-прав на телефоне.

Как это устроено

Архитектура состоит из тех же четырёх частей, что и в Python-оригинале (подробности см. на masterhttprelayvpn), но с несколькими важными отличиями в реализации:

1. Локальный прокси. tokio + rustls. HTTP/CONNECT на 127.0.0.1:8085, SOCKS5 на 127.0.0.1:8086 (в Python-версии для SOCKS5 используется порт 1080 - учитывайте смену порта при переходе).
2. Слой MITM. rcgen генерирует локальный корневой CA при первом запуске. cert_installer.rs добавляет его в системное хранилище доверенных сертификатов ОС в зависимости от платформы (Keychain на macOS, certutil на Linux, CertMgr на Windows, вручную на Android). CA лежит в пользовательском каталоге данных - ~/.local/share/mhrv-rs на Linux, ~/Library/Application Support/mhrv-rs на macOS.
3. Фронтинг-транспорт. tokio-rustls открывает TLS-соединение с edge-IP Google (по умолчанию 216.239.38.120, настраивается) с SNI www.google.com. Внутри h2 мультиплексирует потоки HTTP/2 к script.google.com/macros/s/<DEPLOYMENT_ID>/exec. Тело запроса - это JSON с описанием реального запроса: URL, заголовки, метод, полезная нагрузка. Значение auth_key из конфигурации передаётся как общий секрет, который проверяет Apps Script.
4. Релей. Apps Script выполняет UrlFetchApp.fetch() к целевому ресурсу и возвращает тело ответа. Используется тот же Code.gs, что и в апстриме.

Внешний SNI принадлежит Google, внутренний Host - script.google.com. Оба принадлежат Google, так что это не классический domain-fronting (здесь нет авторитетного прикрытия, прячущего посторонний бэкенд). Google сам маршрутизирует трафик между своими сервисами на основе внутреннего заголовка Host. О том, почему этот конкретный трюк всё ещё работает, когда большинство вариантов фронтинга через CDN уже заблокированы, см. serverless-relay-transport.

Трюк с гибридной маршрутизацией

Деталь, благодаря которой бесплатной квоты Apps Script действительно хватает надолго: запросы к сервисам Google идут в обход Apps Script.

Когда клиент видит запрос к youtube.com, gmail.com или любому другому сервису Google, он туннелирует его напрямую через edge Google с подменой SNI. Внешний SNI остаётся www.google.com (цензор не видит ничего подозрительного), но вызова Apps Script не происходит, UrlFetchApp.fetch() не дергается и квота не расходуется. Затраты Apps Script возникают только при обращении к сторонним ресурсам. Для пользователей, которые проводят большую часть времени в сервисах Google (а это значительная часть целевой аудитории - YouTube, Gmail, Google Docs, сервисы Android Play), бесплатная квота в 20 000 вызовов в день редко становится узким местом.

Логика этой маршрутизации находится в domain_fronter.rs. Список доменов Google зашит на этапе компиляции.

Конфигурация

Пример config.full.example.json из репозитория:

{
  "mode": "full",
  "google_ip": "216.239.38.120",
  "front_domain": "www.google.com",
  "script_id": "YOUR_APPS_SCRIPT_DEPLOYMENT_ID",
  "auth_key": "CHANGE_ME_TO_A_STRONG_SECRET",
  "listen_host": "127.0.0.1",
  "listen_port": 8085,
  "socks5_port": 8086,
  "log_level": "info",
  "verify_ssl": true
}

В комплекте идут ещё два примера: config.google-only.example.json (вообще без Apps Script, только туннелирование через Google-edge для сервисов Google - удобно, если через заблокированное подключение нужен только YouTube) и config.example.json (стандартный релей через Apps Script).

Поле mode выбирает режим маршрутизации: full использует и прямое подключение к Google, и релей через Apps Script, а google-only полностью отключает релей. Также есть опция внешнего SOCKS5 для перенаправления не-HTTP протоколов через сторонний туннель xray/v2ray, сохраняя HTTP/HTTPS через Google-релей.

Поддержка платформ

Готовые бинарники доступны для:

• Linux x86_64 и aarch64 (статические musl-сборки для роутеров и встраиваемых систем)
• macOS x86_64 и aarch64
• Windows x86_64
• Android 7.0+ в виде универсального APK

Сборка под Android - главное отличие от Python-версии. Она использует jni для связи с легковесным Android-приложением-оболочкой, предоставляющим VpnService, и tun2proxy для запуска стека TCP/IP в пространстве пользователя (через smoltcp). Этот стек читает "сырые" пакеты из TUN-дескриптора VpnService и направляет весь TCP/UDP-трафик в локальный SOCKS5. Без компонента tun2proxy VpnService просто создавал бы TUN-устройство, из которого никто не читает, и весь трафик уходил бы в чёрную дыру - судя по трекеру задач в README, на раннем этапе это было реальным багом.

В Cargo.toml есть явные комментарии по поводу неочевидного выбора зависимостей:

• portable-atomic для 64-битных атомиков на 32-битном MIPS/ARMv5 (на роутерах и под OpenWRT нет нативных 64-битных атомарных операций, стандартный AtomicU64 из std Rust там не скомпилируется).
• libc для поднятия RLIMIT_NOFILE, поскольку на роутерах с OpenWRT по умолчанию выставлены низкие лимиты на число файловых дескрипторов, а браузеры быстро исчерпывают их под нагрузкой через прокси.
• eframe со скомпилированными бэкендами glow (OpenGL 2+) и wgpu (DX12/Vulkan/Metal). Бинарник UI по умолчанию выбирает glow, а при MHRV_RENDERER=wgpu переключается на wgpu для старого оборудования на Windows, RDP-сессий и виртуальных машин без поддержки OpenGL 2.0.

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

Два бинарника, две аудитории

mhrv-rs - это headless CLI для серверов, роутеров и автоматизации скриптами. mhrv-rs-ui - десктопное приложение на egui с формой настройки, статистикой в реальном времени, кнопками запуска/остановки и помощником по установке корневого сертификата. ui реализован как feature в Cargo, а не отдельный crate: одно дерево исходников, условная компиляция.

UI на egui примечателен тем, что в оригинале на Python его нет вовсе: пользователям приходилось вручную редактировать JSON и запускать CLI. Для пользователя из Ирана, которому нужен VPN без покупки VPS, десктопное приложение - заметный шаг вперёд по удобству.

Компромиссы по сравнению с оригиналом на Python

Эта версия умеет всё то же самое, что и версия на Python, но:

• Запуск. Бинарник на Rust стартует за десятки миллисекунд. Python запускается пару секунд.
• Память. Версия на Rust стабильно держится в районе 30-50 МБ. Python с httpx/h2 занимает около 120-180 МБ.
• Сложность установки. Rust не требует среды выполнения. Python требует интерпретатор 3.11+ и установленные через pip зависимости - именно на этом спотыкается большинство обращений в поддержку из Ирана.
• Android. Под Rust поставляется полноценное Android-приложение. Версия на Python на Android фактически не работает без акробатики с Termux.
• Отставание по возможностям. Rust - это порт; апстрим-проект на Python быстрее добавляет новые режимы релея. В версии на Python уже есть режимы Cloudflare Worker и Cloud Run, которых в этом порте пока нет (по состоянию на v1.2.11).

Вопросы безопасности

Те же предостережения, что и для оригинала на Python:

• Локальный корневой CA является полноценным центром доверия. Любой, кто получит ca.key из каталога данных, сможет проводить MITM-атаку на все посещаемые HTTPS-сайты. Не делитесь этой директорией и не синхронизируйте её с общими дисками.
• auth_key в конфигурации - единственная защита развёртывания в Apps Script. При его утечке (коммит в публичный репозиторий, скриншот) кто угодно сможет расходовать вашу квоту Google.
• Проекту всего три дня, 257 звёзд, аудит не проводился. Rust гарантирует безопасность работы с памятью, однако в коде TLS и MITM легко спрятать логические ошибки.

Сравнение с VLESS/Xray (как и у версии на Python)

Проект занимает ту же нишу, что и masterhttprelayvpn: сегмент обхода блокировок "без бюджета, с низкой пропускной способностью, на одного пользователя, без VPS". Кластер VLESS (xray-tutorial, 3x-ui, mihomo, xkeen, karing) представляет сегмент "на несколько пользователей, с платным VPS, более высоким качеством и поддержкой любых протоколов". Инструмент ориентирован в основном на Иран; для России он менее полезен, так как фильтрация ТСПУ по CIDR менее агрессивно бьёт по адресам Google-edge, но общая специфика условий отличается (см. russia-vpn-bypass-state-2026-04).

Репозиторий

https://github.com/therealaleph/MasterHttpRelayVPN-RUST - 257 звёзд, MIT, Rust, v1.2.11. Теги: iran, dpi-bypass, domain-fronting. Ссылка на домашнюю страницу в репозитории ведёт на оригинальный проект на Python.

Связанные страницы

• masterhttprelayvpn - оригинальный проект на Python, портом которого является эта утилита
• serverless-relay-transport - общий паттерн использования serverless-сред как точки выхода для обхода блокировок
• domain-fronting - лежащий в основе трюк с TLS
• xray-tutorial, 3x-ui, mihomo, karing - кластер VLESS, бесплатной альтернативой которому выступает этот инструмент
• russia-vpn-bypass-state-2026-04 - почему этот инструмент играет меньшую роль в российских реалиях по сравнению с Ираном