GooseRelayVPN

GooseRelayVPN - третий проект в небольшом, но любопытном семействе "Apps Script как реле для обхода блокировок", после masterhttprelayvpn (оригинал на Python) и masterhttprelayvpn-rust (порт на Rust). Автор Kianmhz прямо ссылается на оригинал: "This project was inspired by the idea in the main repository: MasterHttpRelayVPN".

Главное отличие - в архитектуре. Если инструменты линейки MasterHttpRelay проксируют HTTPS-трафик запросов и ответов через Apps Script с локальным MITM CA, то GooseRelay туннелирует сырой TCP сквозным образом с AES-256-GCM, для чего требуется небольшой выходной VPS-сервер. Google видит только непрозрачные зашифрованные байты; ключ AES никогда не попадает к Google. Ценой отказа от свойства "серверы не нужны", присущего MasterHttpRelay, становится возможность передавать SSH, IMAP, произвольные бинарные протоколы - всё, что способен обернуть SOCKS5.

Архитектура

Browser/App
  -> SOCKS5 (127.0.0.1:1080)
  -> AES-256-GCM raw-TCP frames
  -> HTTPS to Google edge IP (SNI=www.google.com, Host=script.google.com)
  -> Apps Script doPost() (~30-line dumb forwarder, never sees plaintext)
  -> Your VPS :8443/tunnel (decrypts, demuxes by session_id, dials target)
  <- Same path in reverse via long-polling

Пять компонентов:

1. Локальный SOCKS5-слушатель (goose-client) на машине пользователя, порт 1080
2. Кодировщик фреймов AES-256-GCM, оборачивающий каждый байт TCP перед отправкой
3. HTTPS-соединение с domain fronting к edge-IP Google (по умолчанию 216.239.38.120) с SNI=www.google.com, Host=script.google.com - см. domain-fronting
4. Веб-приложение Google Apps Script (Code.gs, ~30 строк) - простой пересыльщик, отправляющий зашифрованный пакет на VPS через POST
5. Выходной сервер на VPS (goose-server) на Linux-машине за $4/мес - расшифровывает, мультиплексирует по ID сессии и выполняет фактический net.Dial

Два бинарника на Go: goose-client (запускается для работы) и goose-server (настраивается один раз на VPS, systemd или NSSM). Apps Script развёртывается через "Deploy as web app, anyone can access", а полученный ID развёртывания вставляется в конфиг клиента.

Формат протокола

• Фрейм: session_id (16) || seq (u64 BE) || flags (u8) || target_len (u8) || target || payload_len (u32 BE) || payload
• Пакетная упаковка: nonce (12) || AES-GCM(u16 frame_count || [u32 frame_len || frame_bytes]…) - один nonce + тег на всё тело HTTP, а не на каждый фрейм
• Тело HTTP: base64(nonce || ciphertext+tag) (base64, чтобы данные не повреждались при текстовой передаче через ContentService в Apps Script)

Аутентификацией служит сам тег AES-GCM - никаких общих паролей или сертификатов. Фреймы, на которых Open() завершается ошибкой, молча отбрасываются. 64-символьный hex-ключ tunnel_key выступает единственным якорем доверия и должен побайтово совпадать на клиенте и сервере.

Масштабирование через несколько развёртываний

На каждое развёртывание Apps Script действует лимит ~20 000 вызовов в день. Клиент поддерживает список ID развёртываний:

"script_keys": ["FIRST_ID", "SECOND_ID", "THIRD_ID"]

Запросы распределяются по развёртываниям методом round-robin. При сбоях работает чёрный список с экспоненциальной задержкой (3с, 6с, 12с, ... до ~48с). Переключение при сбое происходит внутри того же опроса, поэтому временная ошибка квоты не приводит к потере трафика. В README не рекомендуется использовать больше 3-4 ID развёртываний: каждый добавляет 3 параллельных воркера опроса, и дальнейшее увеличение лишь создаёт лишнюю нагрузку без прироста скорости.

Затраты на настройку

• Разовые: VPS на Linux за $4/мес, 64-символьный AES-ключ из scripts/gen-key.sh, два бинарника на Go, один проект Apps Script + создание развёртывания (Deploy -> New deployment) с типом "Web app" и доступом "Anyone"
• Постоянные: запуск ./goose-client и перенаправление браузера на SOCKS5 127.0.0.1:1080

На этапе Apps Script есть привычная для Google ловушка: любое изменение в Code.gs требует создания нового развёртывания (Deploy -> New deployment, простого сохранения недостаточно), а новый ID развёртывания нужно скопировать в конфиг клиента.

Сравнение компромиссов

Сквозной AES - это существенное улучшение безопасности по сравнению с MasterHttpRelay: логи запросов у Google открыты, а риски нарушения условий использования Google и санкций против Ирана для авторов оригинала вполне реальны. В GooseRelay в логах Google остаётся только зашифрованный текст AES; наружу утекают лишь число запросов, размеры тел и тайминги. Достаточно мотивированный противник всё ещё может восстановить данные, но это качественно отличается от логирования открытых адресов назначения.

Необходимость VPS - ощутимая плата. Вся привлекательность MasterHttpRelay заключалась в принципе "бесплатно, без серверов". GooseRelay от него отказывается, поскольку заявленная цель проекта - туннелирование сырого TCP (SSH, IMAP и чего угодно ещё), для чего фундаментально необходим настоящий net.Dial где-то на сервере.

Watchlist

Проект добавлен в watchlist - один автор (kianmhz), свежий репозиторий, узкая ориентация на персоязычный рынок. Повторная проверка 2026-07-29: сторонние контрибьюторы, клиенты под Android/iOS (пока только CLI), аудит обёртки AES, доказательства устойчивости модели угроз против иранского аналога ТСПУ (см. tspu о российском аналоге).

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

• masterhttprelayvpn - оригинальный проект на Python, указанный как источник вдохновения
• masterhttprelayvpn-rust - порт на Rust с UI на egui и поддержкой Android VpnService
• serverless-relay-transport - более широкий паттерн, частью которого является проект
• domain-fronting - базовая техника обхода блокировок
• xray-tutorial, 3x-ui, mihomo, xkeen - семейство решений на базе VLESS (альтернатива при наличии собственного домена и отсутствии необходимости маскироваться за Google)

Репозиторий: https://github.com/Kianmhz/GooseRelayVPN