Статья от команды CloudBridge Research.
Тут можно ознакомиться с нашими исследованиями
Если вы когда-нибудь пытались построить стабильный VPN поверх реального Интернета, то знаете: ключевая проблема не в криптографии и даже не в пропускной способности канала. Проблема в том, как протокол ведет себя, когда сеть начинает «качать».
Мы много лет экспериментировали с OpenVPN, WireGuard и разными вариациями UDP-туннелей. В хорошей сети → работают все. В плохой сети → перестают работать почти все. Поэтому когда в экосистеме QUIC появился MASQUE, мы решили проверить: а можно ли собрать VPN, который действительно переносит нестабильные условия?
Оказалось, что можно. Ниже немного опыта и наблюдений, которые накопились в процессе разработки нашего экспериментального masque-vpn.
Почему MASQUE выглядит многообещающе
QUIC долгое время воспринимали как «протокол для браузеров»: быстрый старт, меньше задержек, меньше head-of-line blocking. Но со временем стало понятно, что QUIC — это скорее современный транспорт, который умеет жить в реальном мире: мигрирующие соединения, резкие просадки канала, переезды между Wi-Fi и LTE.
MASQUE вырос как логичное продолжение:
«Если мы уже передаем пол-Интернета по QUIC, почему бы не сделать поверх него нормальный IP-туннель?»
Так появился RFC 9484 (CONNECT-IP). И он оказался гораздо интереснее, чем ожидалось.
Что происходит, когда MASQUE попадает в нестабильную сеть
Мы специально создавали «плохие условия»: RTT скачет от 50 до 150 мс, джиттер до 30 мс, потери 2%. Типичный мобильный профиль.
Результаты:
OpenVPN в таких условиях легко «тонет» из-за TCP-over-TCP.
WireGuard держится лучше, но чувствителен к потере и не любит частые переключения канала.
MASQUE неожиданно стабилен.
Почему так:
QUIC datagrams не создают лавину ретраев.
Потери не приводят к блокировке всего потока.
Управляющий поток живет отдельно и не мешает передаче данных.
При смене канала соединение не рвется, QUIC продолжает «как ни в чем не бывало».
Когда мы включили свой FEC-модуль (мы сделали XOR-вариант и экспериментируем с Reed-Solomon), джиттер внутри туннеля упал почти до нуля. Это очень заметно в RDP, видеозвонках и стриминговых приложениях.
WireGuard все еще быстрее на идеальных каналах, тут спору нет. Но MASQUE оказался «живучее», а для многих задач именно это и важно.
Немного о том, как все устроено внутри
masque-vpn — это реализация CONNECT-IP поверх QUIC с поднятием TUN-интерфейса, обработкой капсул и передачей пакетов через datagrams. Все максимально прозрачно, без «магии».
Несколько любопытных моментов:
Capsules позволяют динамически менять IP и параметры туннеля без переподключения.
QUIC проще переносит потерю связи между разными интерфейсами.
Go удобен для прототипирования, но, конечно, user-space криптография ест CPU.
Сейчас мы больше сосредоточены на корректности и воспроизводимости, а не на экстремальной оптимизации. Но потенциал для оптимизации — огромный (XDP, eBPF, аппаратный offload и т.д.)
Где MASQUE оправдывает себя лучше всего
MASQUE и WireGuard не конкуренты, а инструменты для разных задач.
Есть сценарии, где MASQUE прямо «заходит»:
Мобильные пользователи, переключающие сети на ходу.
Филиалы и удаленные площадки с неоднородными каналами.
Корпоративная удаленка, где важна предсказуемость качества.
Среды, где HTTP/3 проходит стабильнее, чем «чистый UDP».
Приложения, чувствительные к очередям и джиттеру.
Если упростить:
WireGuard про скорость.
MASQUE про устойчивость.
Но и минусы есть, честно и без маркетинга
Было бы странно их не перечислить:
QUIC-туннель тяжелее по CPU, чем kernel-based WireGuard.
Архитектура MASQUE сложнее.
Пока что нужен наш клиент (нельзя просто включить в ОС).
Оптимизации «на железе», еще впереди.
Но если ваша задача — стабильность в непредсказуемой сети, MASQUE выглядит как один из самых интересных вариантов.
Хотите попробовать?
Репозиторий полностью открыт:
https://github.com/twogc/masque-vpn
Есть базовые образы Docker, примеры конфигураций и минимальные клиенты.
Мы будем рады вашим находкам, идеям, вопросам и Pull Request’ам — это исследовательский проект, и чем больше людей его попробует, тем быстрее мы поймем, как этот стек ведет себя «в дикой природе».
Комментарии (0)
tequier0
01.12.2025 17:40Кто использует openvpn tcp over tcp вместо udp, а, главное, зачем? Это какой-то изощренный способ стрельбы в колено?
maxorik Автор
01.12.2025 17:40Со стороны, это действительно так выглядит :) но на практике люди нередко оказываются в ситуациях, где UDP либо режется, либо нестабилен, либо просто запрещён корпоративной политикой. И тогда единственный рабочий вариант, именно TCP.
ki11j0y
01.12.2025 17:40И тут приходят на встречу websocket, wss подключения, внутри можно пускать как wg так и tun или просто socks5. Отличное решение для обхода корпоративных фильтров и не только без ваших vless, ocserv и тд, размести за обратным прокси и настрой правильно шифры.
maxorik Автор
01.12.2025 17:40WebSocket и WebTransport и для ряда задач это действительно удобная схема, но у WSS есть и обратная сторона: он все-таки работает поверх TCP, что значит head-of-line blocking, ретраи, дополнительные очереди и дрожание RTT при плохой сети. Для прокси и легкого транспорта это терпимо, но для IP-туннеля под реальное время, иногда ограничивает.
MASQUE здесь интересен тем, что он дает тот же «видимый» HTTPS-трафик, но при этом сохраняет свойства QUIC: datagram-передачу без перепосылок, быстрое переподключение, нормальную работу под плавающим jitter и возможность migration без разрыва.
По разный случай свой рецепт :)
QRpeach
01.12.2025 17:40В нынешних реалиях либо протокол vless + reality, либо уповать на бога.
GamePad64
01.12.2025 17:40Глянул протокол — он вполне подходит для sni fronting и для проксирования сторонних узлов. Все фишки reality можно поверх него реализовать. Поверх http1.1 и http2 он тоже умеет работать.
Belkogoth
01.12.2025 17:40Таки от задач зависит. Если корпоративный траффик тоннами гонять - там свои приблуды, требующие аппаратных ускорений. Для мелких задач до нескольких десятков мегабит спасает и экзотика. Я уже года два корпоративные и личные микроты подключаю к импортным VPS на RouterOS по SSTP с сертификатами. Просто SSTP, безо всяких костылей и надстроек.Тьфу 3 раза, но коннект стабильный. Заворачиваю туда то, что закрыто отсюда туда (ютубы, онлайн кинотеатры и прочие воцапы), и оттуда сюда (всякие интелы деллы и прочая тонна сайтов производителей разного оборудования, которая "не разговаривает с мальчиками из вон той песочницы")))
Все стабильно работает, коннект не отваливается. Ютубы бегают, ао крайней мере, 4к поток вывозит, и даже не один. Но для запросов выше 15-18 мбит лучше либо микроты на ARM, либо х86 городить.
aborouhin
Очень интересно, но текущие реалии вынуждают задаться вопросом - а как там вообще сейчас дела с QUIC в РФ? Живой? Вроде, блокировали его ковровыми методами.
maxorik Автор
в России ситуация с QUIC местами непростая: где-то работает стабильно, где-то действительно чувствуется ограничение UDP. Поэтому я и делаю эти исследования, хочется понять, как протокол ведёт себя в реальных российских сетях, где он устойчив, а где требует обходных механизмов или fallback. Пока результаты разные, но точно не нулевые, QUIC во многих сетях остаётся рабочим. Если есть свои наблюдения, буду рад услышать/прочитать.
aborouhin
Своих наблюдений особо нет, увы. Реалии вынуждают использовать VPN постоянно для себя и всех сотрудников нашего скромного бизнеса, так что что там без него творится - нет возможности мониторить (только когда на сам VPN покушаются). На ntc.patry тема про QUIC тоже с 2022 года заглохла.
А Вашему продукту могу пожелать всяческих успехов и развития, тема интересная, - но пока не будет клиентов как минимум под Android, iOS и Windows - испытать его в бою не представляется возможным :( Вот эти все сценарии про потери пакетов, переключения между сетями и пр. - они же про смартфоны в первую очередь.
maxorik Автор
Спасибо за поддержку, очень мотивирует продолжать копать дальше :)
rostislav-zp
ntc походу окончательно в офлайн ушел уже к сожалению
aborouhin
Добавьте в hosts на компе или роутере вручную IP 130.255.77.28 для домена ntc.party - и он волшебным образом оживёт :) Там приняли странное решение оставить в публичном DNS только AAA запись для IPv6, а A запись для IPv4 убрать.
haga777
Не помогло
ferlizer
на мобильном интернете невозможно подключиться, приходится генерировать конфигурацию ВАРП с протоколом AmneziaWG.