🥚➡️🍏🍎 Usque — это реимплементация с открытым исходным кодом режима MASQUE из клиента Cloudflare WARP. Он использует протокол Connnect-IP (RFC 9484) и поставляется с множеством режимов работы, включая нативный туннель (в настоящее время только Linux), прокси SOCKS5 и HTTP-прокси.
export ve="1.4.2"; export arch="$(dpkg-architecture -q DEB_BUILD_ARCH)"; curl -OL https://github.com/Diniboy1123/usque/releases/download/v"${ve}"/usque_"${ve}"_linux_"${arch}".zip && echo "${ve}" && unzip ./usque_"${ve}"_linux_"${arch}".zip -d ./usque && sudo cp ./usque/usque /usr/local/bin && rm -f ./usque_"${ve}"_linux_"${arch}".zip
🥚➡️🍏🍎
Usque — это открытая реализация клиента Cloudflare WARP в режиме MASQUE. Он использует протокол Connect-IP (RFC 9484) и предоставляет множество режимов работы, включая нативный туннель, SOCKS5 и HTTP-прокси, а также более быстрые L4-прокси-варианты только для TCP.
Вы можете скачать последний релиз со страницы релизов. В настоящее время предоставляются бинарные файлы для Android (arm64), Linux (armv5, armv6, armv7, arm64, amd64), Windows (arm64, amd64, 386) и Darwin (arm64, amd64). Однако протестирован был только бинарный файл для Linux amd64. Если у вас другая платформа, вы можете собрать из исходного кода.
Распакуйте архив, и вы найдете бинарный файл с именем usque в корневой директории. Вы можете переместить этот файл в директорию, указанную в вашей переменной PATH, чтобы сделать его доступным из любого места.
Поскольку инструмент написан на Go, сборка должна быть довольно простой.
CGO_ENABLED=0 go build -ldflags="-s -w" .
Это создаст бинарный файл usque в текущей директории.
Если вы хотите выполнить кросс-компиляцию, установите переменные окружения GOOS и GOARCH соответствующим образом. Например, чтобы собрать для Windows в системе Linux:
GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build -ldflags="-s -w" .
Вы можете развернуть инструмент с помощью Docker. В репозитории предоставлен Dockerfile. Чтобы собрать образ, выполните:
docker build -t usque:latest .
Пример использования (создает SOCKS-прокси и открывает его на порту 1080):
docker run -it --rm -p 1080:1080 usque:latest socks
$ ./usque --help
Неофициальный CLI Cloudflare Warp, который использует протокол MASQUE и предоставляет туннель в виде различных сервисов.
Использование:
usque [команда]
Доступные команды:
completion Генерирует скрипт автодополнения для указанной оболочки
enroll Регистрирует приватный ключ MASQUE и переключает режим
help Справка по любой команде
http-proxy Предоставляет Warp в виде HTTP-прокси с поддержкой CONNECT
l4-http-proxy Предоставляет Warp в виде L4 TCP-только HTTP-прокси с поддержкой CONNECT
l4-socks Предоставляет Warp в виде L4 TCP-только SOCKS5-прокси
nativetun Предоставляет Warp в виде нативного TUN-устройства
portfw Перенаправляет порты через туннель MASQUE
register Регистрирует новый клиент и подключает ключ устройства
socks Предоставляет Warp в виде SOCKS5-прокси
version Выводит номер версии usque
Флаги:
-c, --config string файл конфигурации (по умолчанию config.json) (default "config.json")
-h, --help справка по usque
Используйте "usque [команда] --help" для получения дополнительной информации о команде.
Прежде чем что-либо делать, вам необходимо зарегистрироваться.
Существует удобная (хоть и не очень функциональная) подкоманда register, которая создает новый аккаунт Warp, готовый к использованию. Она также берет на себя регистрацию устройства и подключение ключа MASQUE. Вызовите это один раз, и оно создаст рабочую конфигурацию для дальнейшего использования в модулях.
Простой пример:
$ ./usque register
[!TIP] Если вы хотите указать имя устройства, вы можете сделать это, указав
-n <имя-устройства>.[!TIP] Если вы хотите зарегистрироваться с ZeroTrust, вам необходимо получить токен команды и сделать это, указав
--jwt <токен-команды>. 1. Посетитеhttps://<домен-команды>/warpи пройдите процесс аутентификации. 2. Получите токен команды из исходного кода страницы успеха или выполните следующую команду в консоли браузера:console.log(document.querySelector("meta[http-equiv='refresh']").content.split("=")[2]).
Если вы не получили ошибку о превышении лимита запросов или любую другую ошибку, вы должны увидеть сообщение Successful registration и рабочую конфигурацию. В случае определенных проблем, таких как ограничение частоты запросов, вам может потребоваться подождать немного и повторить попытку.
Хотя команда регистрации также обрабатывает подключение устройства ключа, в некоторых случаях вы можете захотеть повторно подключить старый ключ, найденный в конфиге. Это полезно при миграции с одного устройства на другое, когда сервер все еще имеет зарегистрированный старый клиентский ключ. Или если ваш аккаунт имел включенную WireGuard, и вы хотите переключиться на MASQUE.
[!NOTE] Эта команда обновляет вашу конфигурацию данными, загруженными с серверов Cloudflare, поэтому убедитесь, что у вас есть резервные копии.
[!TIP] При использовании ZeroTrust эта команда может обновить конфигурацию с вновь назначенными IPv4 и IPv6 адресами. Это полезно, потому что IPv6, похоже, не работает там, если IPv6 в конфиге не обновлен. Личный WARP, похоже, не подвержен этому.
$ ./usque enroll
Нативный туннель — хороший выбор, когда вам нужен настоящий сетевой интерфейс. Это также один из более быстрых режимов работы.
Он требует наличия устройства TUN в системе. Это означает, что ваше ядро должно поддерживать загрузку модуля tun.ko. Также требуется iproute2. Хотя трафик всё еще обрабатывается в пространстве пользователя, он напрямую инжектируется в сетевой стек ядра, поэтому вы увидите настоящий сетевой интерфейс и сможете туннелировать любой IP-трафик (уровня 3), который поддерживает WARP. Поскольку создается настоящий сетевой интерфейс и также предпринимается попытка установить IP-адреса, с наибольшей вероятностью потребуются права root.
Для работы требуется файл wintun.dll в той же директории, что и исполняемый файл usque.exe. Затем инструмент самостоятельно поднимет интерфейс и установит IP-адреса. Обычно это также требует административных привилегий.
Чтобы запустить нативный туннель, выполните:
$ sudo ./usque nativetun
Если не указано иное, вы должны увидеть, что в Linux появляется интерфейс tun0 (или tun1, tun2 и т.д.). В Windows интерфейс обычно называется usque. Если вы не отключали IPv4 и IPv6 внутри туннеля с помощью флагов CLI (в Linux), вы также должны увидеть, что интерфейсу уже назначены IPv4 и IPv6 адреса. Этого должно быть достаточно для работы приложений, которые могут маршрутизировать трафик через определенный сетевой интерфейс. Например, ping:
$ ping -I tun0 1.1
Или curl:
$ curl --interface tun0 https://cloudflare.com/cdn-cgi/trace
Должно работать. Однако инструмент не настраивает никаких маршрутов. Если вам это нужно, вам придется сделать это вручную. Например, чтобы маршрутизировать весь трафик через туннель, вам необходимо убедиться, что адрес, используемый для туннельной коммуникации, маршрутизируется через ваш обычный сетевой интерфейс. Для этого откройте config.json и проверьте адрес конечной точки. Если вы планируете подключаться к конечной точке Cloudflare по IPv4, вы, скорее всего, увидите следующее:
"endpoint_v4": "162.159.198.1"
Запомните это для следующих шагов.
Предполагая, что ваш обычный сетевой интерфейс — eth0, а адрес вашего шлюза — 192.168.1.1, вы можете добавить маршрут так:
$ sudo ip route add 162.159.198.1/32 via 192.168.1.1 dev eth0
После этого вы можете добавить маршрут по умолчанию для интерфейса tun0 как для IPv4, так и для IPv6:
$ sudo ip route add default dev tun0 && sudo ip -6 route add default dev tun0
Сначала определите индекс интерфейса для вашего обычного сетевого адаптера, выполнив команду:
route print
Ищите правильный номер индекса в разделе Interface List.
Перед добавлением маршрутов по умолчанию определите шлюз для вашего туннельного интерфейса, выполнив команду:
ipconfig
Найдите адаптер с именем usque (или как бы ни назывался ваш туннельный интерфейс) и запишите его адрес шлюза.
Предположим:
162.159.198.1192.168.1.112usque (замените на фактическое имя или индекс вашего туннельного интерфейса)Выполните следующие команды в повышенной командной строке (от имени администратора):
route add 162.159.198.1 mask 255.255.255.255 192.168.1.1 metric 1 if 12
Затем добавьте маршруты по умолчанию, чтобы весь трафик шел через туннель:
route add 0.0.0.0 mask 0.0.0.0 [TUNNEL_GATEWAY] metric 1 if [TUN_INTERFACE_INDEX]
route add ::/0 [TUNNEL_GATEWAY] metric 1 if [TUN_INTERFACE_INDEX]
[!NOTE] Замените
[TUNNEL_GATEWAY]и[TUN_INTERFACE_INDEX]на фактические значения для вашего туннельного адаптера. Вы можете получить их, проверивipconfigиroute print.[!CAUTION] Всегда будьте осторожны с маршрутами по умолчанию, особенно если вы запускаете это на сервере без графического интерфейса. Очень легко потерять доступ к текущей сессии. Я рекомендую сетевые пространства имён в Linux как более безопасную песочницу для экспериментов или дополнительную виртуальную машину с физическим доступом или последовательной консолью. В Windows вы можете сначала задать определенные маршруты, такие как
8.8.8.8/32, чтобы убедиться, что туннель работает, прежде чем добавлять маршрут по умолчанию.
[!TIP] Если вас устраивает использование QUIC (UDP) для подключения к WARP, и вам не нужна поддержка UDP для вашего SOCKS-прокси, режим L4 более эффективен.
Если вы просто хотите представить туннель как быстро развертываемый прокси, и ваш клиент поддерживает SOCKS5, этот режим для вас. Он поддерживает и IPv4, и IPv6. Даже TCP и UDP! Он также является кроссплатформенным и не требует никаких специальных модулей ядра или привилегий root. Однако он эмулирует целый сетевой стек в пространстве пользователя, поэтому может потреблять много ресурсов.
Чтобы запустить прокси SOCKS5, вы можете выполнить:
$ ./usque socks
По умолчанию это запустит SOCKS5-прокси на 0.0.0.0:1080 без аутентификации. Вы можете привязаться к конкретному адресу и порту, указав -b и -p соответственно. Вы также можете включить аутентификацию, указав -u и -w для имени пользователя и пароля. Например:
$ ./usque socks -b 127.0.0.1 -p 8080 -u myuser -w mypass
Запустит SOCKS5-прокси, доступный только по адресу 127.0.0.1:8080 с именем пользователя myuser и паролем mypass.
Проверьте прокси с помощью curl:
curl -x socks5://myuser:mypass@localhost:8080 https://cloudflare.com/cdn-cgi/trace
[!NOTE] Поскольку прокси эмулирует собственный сетевой стек, можно в целом утверждать, что пользователи не смогут получить доступ к внутренним IP-адресам и сервисам, к которым имеет доступ хост, используя прокси. Однако внутренняя сеть WARP доступна им без фильтрации. Если у вас включены ZeroTrust и Gateway, пользователи вашего прокси могут иметь возможность связываться друг с другом, поскольку ручная фильтрация не применяется. Внутри туннеля они смогут подключаться к любому TCP- или UDP-сервису.
[!CAUTION] Локальный трафик SOCKS5 не шифруется, поскольку SOCKS5 не поддерживает шифрование. Вероятно, вам не следует транспортировать государственные секреты с одного устройства на другое через общественный Wi-Fi, на котором запущен
usque.[!NOTE] В настоящее время поддерживается только один
user:pass.
[!TIP] Если вас устраивает использование QUIC (UDP) для подключения к WARP, режим L4 более эффективен.
Еще один простой режим работы для "быстрого запуска" — это режим HTTP-прокси. Почти все клиенты поддерживают HTTP-прокси. Обычный незашифрованный HTTP-трафик, отправленный в этот прокси, будет просто перенаправлен в сеть WARP. Для HTTPS и любого другого TCP-трафика прокси предоставляет метод HTTP CONNECT. Этот режим является кроссплатформенным и не требует никаких специальных модулей ядра или привилегий root. Однако он эмулирует целый сетевой стек в пространстве пользователя, поэтому может потреблять много ресурсов.
Чтобы запустить HTTP-прокси, вы можете выполнить:
$ ./usque http-proxy
По умолчанию это запустит HTTP-прокси на 0.0.0.0:8000 без аутентификации. Вы можете привязаться к конкретному адресу и порту, указав -b и -p соответственно. Вы также можете включить аутентификацию, указав -u и -w для имени пользователя и пароля. Например:
$ ./usque http-proxy -b 127.0.0.1 -p 8080 -u myuser -w mypass
Запустит HTTP-прокси, доступный только по адресу 127.0.0.1:8080 с именем пользователя myuser и паролем mypass.
Проверьте прокси с помощью curl:
curl -x http://myuser:mypass@localhost:8080 https://cloudflare.com/cdn-cgi/trace
[!NOTE] Поскольку прокси эмулирует собственный сетевой стек, можно в целом утверждать, что пользователи не смогут получить доступ к внутренним IP-адресам и сервисам, к которым имеет доступ хост, используя прокси. Однако внутренняя сеть WARP доступна им без фильтрации. Если у вас включены ZeroTrust и Gateway, пользователи вашего прокси могут иметь возможность связываться друг с другом, поскольку ручная фильтрация не применяется. Внутри туннеля они смогут подключаться к любому TCP-сервису.
[!CAUTION] Локальный HTTP трафик не шифруется, поскольку HTTP не поддерживает шифрование, а HTTPS не реализован. Добавить его, вероятно, несложно, но мне пока это не понадобилось. Вероятно, вам не следует транспортировать государственные секреты с одного устройства на другое через общественный Wi-Fi, на котором запущен
usque.[!NOTE] В настоящее время поддерживается только один
user:pass.
Если ваши клиенты работают только с TCP-прокси, режимы L4 являются более легкой опцией. Они используют прямые HTTP/3 CONNECT-потоки, пропускают обработку UDP/датаграмм и избегают дополнительного пользовательского сетевого стека, необходимого для полных режимов прокси SOCKS5 и HTTP. Они кроссплатформенные и не требуют повышенных привилегий.
Используйте l4-http-proxy, когда вам нужен HTTP-прокси с поддержкой CONNECT, или l4-socks, когда вам нужна совместимость с SOCKS5:
$ ./usque l4-http-proxy
$ ./usque l4-socks
Они поддерживают те же флаги привязки, порта, аутентификации, DNS и хуков, что и другие режимы прокси. Для рабочих нагрузок, использующих только TCP, эти режимы обычно должны превосходить полный стек прокси.
Подробнее в вики.
Хотя большинство других режимов каким-либо образом представляют туннель, этот режим предназначен для более сложных случаев использования. Думайте о нем немного как об SSH-перенаправлении. Он позволяет либо перенаправлять определенный порт с хоста в сеть WARP, либо из сети WARP на хост.
Зачем это нужно, можете спросить вы? Для обычного WARP эта функция бесполезна. Фактически, команда registration инструмента даже не может правильно это настроить. Однако с некоторой ручной конфигурацией и при условии, что у вас есть сеть ZeroTrust, вы можете настроить взаимодействие между устройствами WARP к WARP. Каждое устройство будет иметь уникальный внутренний IPv4 и IPv6 адрес, и они смогут связываться друг с другом таким образом. Однако это не работает «из коробки», поэтому следуйте официальному руководству для настройки. Как только у вас это заработает, вы сможете использовать эту функцию для перенаправления портов в сеть WARP и из нее.
[!TIP] Для правильной работы этого режима очень важно иметь актуальные IP-адреса в конфигурации. Запуск процесса регистрации перед запуском перенаправления должен установить правильные IP-адреса.
Этот режим кроссплатформенный и не требует каких-либо специальных модулей ядра или привилегий root. Однако он эмулирует весь пользовательский сетевой стек, поэтому может потреблять много ресурсов.
Что касается настройки. Допустим, у вас в конфигурации есть:
"ipv4": "100.96.0.3"
Что означает, что внутренний IPv4-адрес вашего устройства — 100.96.0.3. Вы запускаете веб-сервер на хост-машине на порту 8080. Затем есть другое устройство с внутренним IPv4-адресом 100.96.0.2, которое также предоставляет веб-сервер на порту 8081. Вы хотите перенаправить порт хоста 8080 в сеть WARP, а порт сети WARP 8081 на хост. Для настройки этого вы можете запустить:
$ ./usque portfw -R 100.96.0.3:8080:localhost:8080 -L localhost:8081:100.96.0.2:8081
[!TIP] Синтаксис не совсем такой, как в SSH. Я рекомендую указывать синтаксис, как в примере, предпочтительно с IP-адресами, а не хостами.
[!TIP] Поддерживается любое количество портов. Вы можете объединить много портов, указав флаг и соответствующий аргумент один за другим.
Все режимы туннелей могут вызывать внешний исполняемый файл после каждого успешного подключения туннеля и после каждого разрыва соединения туннеля. Это полезно для повторного применения маршрутов, правил межсетевого экрана или уведомлений без их жесткого кодирования в инструменте.
--on-connect <путь>: выполняется после каждого успешного подключения (включая переподключения).--on-disconnect <путь>: выполняется после каждого разрыва соединения туннеля.Оба флага принимают путь к единственному исполняемому файлу. Путь выполняется напрямую, поэтому оболочка не запускается, и аргументы не передаются. Если вам нужна одна команда, такая как ip route add ..., оберните её в небольшой скрипт оболочки.
Хуки выполняются в фоновом режиме без ожидания результата, поэтому зависший хук не может остановить туннель. Их stdout и stderr захватываются построчно и пересылаются в стандартный журнал с префиксом hook[connect] / hook[disconnect].
Дочерний процесс хука наследует окружение родителя (поэтому PATH, HOME и т.д. работают нормально), а также следующие переменные USQUE_*:
USQUE_EVENT: connect или disconnect.USQUE_MODE: nativetun, socks, http-proxy, l4-socks, l4-http-proxy или portfw.USQUE_IFACE: имя интерфейса tun (устанавливается только в режиме nativetun).USQUE_IPV4: внутренний IPv4 из конфигурации.USQUE_IPV6: внутренний IPv6 из конфигурации.USQUE_ENDPOINT: адрес MASQUE-конечной точки, который использует туннель.$ sudo ./usque nativetun \
--on-connect /etc/usque/up.sh \
--on-disconnect /etc/usque/down.sh
# /etc/usque/up.sh
#!/bin/sh
set -e
ip route replace 162.159.198.1/32 via 192.168.1.1 dev eth0
ip route del default || true
ip route replace default dev "$USQUE_IFACE"
ip -6 route replace default dev "$USQUE_IFACE"
echo "nameserver 1.1.1.1" > /etc/resolv.conf
В Windows вы можете указать --on-connect / --on-disconnect на .bat, .cmd или .exe. Переменные окружения доступны как %USQUE_IFACE%, %USQUE_IPV4% и т.д. Запускайте usque в повышенном приложении «Командная строка», чтобы хук унаследовал необходимые привилегии для изменения маршрутов.
> usque.exe nativetun ^
--on-connect C:\usque\up.bat ^
--on-disconnect C:\usque\down.bat
@rem C:\usque\up.bat
@echo off
netsh interface ipv4 delete route 0.0.0.0/0 "%USQUE_IFACE%" >nul 2>&1
netsh interface ipv4 add route 0.0.0.0/0 "%USQUE_IFACE%" 0.0.0.0
netsh interface ipv6 delete route ::/0 "%USQUE_IFACE%" >nul 2>&1
netsh interface ipv6 add route ::/0 "%USQUE_IFACE%" ::
Если вы предпочитаете PowerShell, укажите сам хук на небольшой файл-заглушку .bat, который вызывает powershell.exe -NoProfile -ExecutionPolicy Bypass -File up.ps1. Запускатель хуков не принимает дополнительных аргументов, поэтому, насколько мне известно, обертка — самый простой способ обратиться к .ps1.
[!TIP] Поскольку
on-connectсрабатывает при каждом переподключении, делайте ваши скрипты идемпотентными. Предпочитайтеip route replace/netsh ... delete+addпростомуadd, проверяйте перед добавлением для правил межсетевого экрана и так далее.[!NOTE] Хуки не запускаются при начальном запуске процесса перед первым подключением, ни при окончательном завершении процесса. Они строго срабатывают в ответ на события жизненного цикла туннеля.
Хотя usque изначально был разработан с акцентом на QUIC и HTTP/3, Cloudflare с тех пор внедрила поддержку fallback на TCP в своих официальных клиентах. usque теперь поддерживает этот метод соединения через --http2.
Для полных подробностей и устранения неполадок см. страницу вики: Поддержка HTTP/2.
Для подключения через TCP/HTTP/2 используйте флаг CLI --http2.
Поскольку конечные точки не могут быть надежно извлечены из API, вы можете управлять соединениями HTTP/2 с помощью:
endpoint_h2_v4: IPv4-адрес для режима HTTP/2.endpoint_h2_v6: IPv6-адрес для режима HTTP/2.Поведение по умолчанию:
endpoint_h2_v4 не установлен, usque использует 162.159.198.2.endpoint_h2_v6 намеренно пуст по умолчанию и должен быть настроен вручную, когда вы хотите HTTP/2 по IPv6.Для простоты инструмент использует файл конфигурации в формате JSON. Файл по умолчанию — config.json в текущей директории. Вы можете указать другой файл с помощью флага -c. Это будет действовать для всех подкоманд. Без файла конфигурации будет работать только подкоманда register.
Пример конфигурации:
{
"private_key": "M...скрыто...==",
"endpoint_v4": "162.159.198.1",
"endpoint_v6": "2606:4700:103::",
"endpoint_h2_v4": "162.159.198.2",
"endpoint_h2_v6": "",
"endpoint_pub_key": "-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEIaU7MToJm9NKp8YfGxR6r+/h4mcG\n7SxI8tsW8OR1A5tv/zCzVbCRRh2t87/kxnP6lAy0lkr7qYwu+ox+k3dr6w==\n-----END PUBLIC KEY-----\n",
"license": "A...скрыто...Z",
"id": "00000000-0000-0000-0000-000000000000",
"access_token": "00000000-0000-0000-0000-000000000000",
"ipv4": "172.16.0.2",
"ipv6": "2606:redacted:1"
}
private_key: Закрытый ключ ECDSA на кривой NIST P-256, закодированный в Base64 в формате ASN.1 DER. Конфиденциально. Используется для аутентификации устройства.endpoint_v4: IPv4-адрес конечной точки Cloudflare WARP. Публичный. Используется для подключения к сети WARP.endpoint_v6: IPv6-адрес конечной точки Cloudflare WARP. Публичный. Используется для подключения к сети WARP.endpoint_h2_v4: IPv4-адрес, используемый флагом --http2. По умолчанию, если пусто, принимает значение 162.159.198.2. Публичный.endpoint_h2_v6: IPv6-адрес, используемый флагом --http2. По умолчанию пуст, должен быть установлен вручную для работы HTTP/2 по IPv6. Публичный.endpoint_pub_key: Открытый ключ ECDSA на кривой NIST P-256, закодированный в Base64 в формате PEM. Публичный. Используется для того, чтобы убедиться, что мы действительно общаемся с конечной точкой Cloudflare WARP, а не подвергаемся MITM-атаке (Man-in-the-middle).license: Лицензия, возвращённая сервером для нашего аккаунта. Конфиденциально. С её помощью можно связать несколько устройств с одним аккаунтом.id: ID устройства, выданный нам сервером. Публичный. Используется для идентификации устройства и выполнения API-вызовов.access_token: Токен доступа, выданный нам сервером при регистрации/входе. Конфиденциально. Используется для API-вызовов.ipv4: Внутренний IPv4-адрес, назначенный устройству сетью Cloudflare WARP. Публичный. Присваивается интерфейсу устройства и также используется для связи между устройствами в режиме пересылки портов.ipv6: Внутренний IPv6-адрес, назначенный устройству сетью Cloudflare WARP. Публичный. Присваивается интерфейсу устройства и также используется для связи между устройствами в режиме пересылки портов.На мой взгляд, ZeroTrust — это корпоративная версия WARP от Cloudflare. Подробное объяснение этого выходит за рамки данного README.
Хотя инструмент не сможет войти в ZeroTrust (для этого требуется SSO), практика показывает, что можно настроить соединение, если очень хочется. Для этого нужно выполнить ./usque register --jwt <jwt> или вручную собрать файл конфигурации. Если вы выберете собирать конфигурацию вручную, я рекомендую использовать команду register, чтобы получить персональную конфигурацию WARP. Не изменяйте все поля, кроме access_token и id. Что касается того, как их получить, будьте изобретательны. Например, оба этих значения можно извлечь из /var/lib/cloudflare-warp/reg.json, если используется официальный клиент WARP на Linux. Или существующие ID устройств перечислены в панели управления ZeroTrust. Как только они будут получены, вы можете использовать команду enroll, чтобы обновить конфигурацию новыми данными. Вы увидите, что поле license пустое. Это нормально. ZeroTrust не использует лицензии (насколько мне известно).
Связь warp-to-warp поддерживается всеми режимами этого инструмента, если она правильно настроена. Прокси и туннели могут обращаться к сервисам, доступным на других устройствах, а пересылка портов может использоваться для перенаправления портов в сеть WARP и из неё.
[!TIP] Эти туннели, похоже, используют более оптимально маршрутизированную сеть
warp=plus. Однако, как только включается прокси (что необходимо для связи warp-to-warp), соединение понижается доwarp=on. Это приводит к снижению производительности (хотя обычно всё равно довольно щедрой).[!TIP] По умолчанию Cloudflare логирует большинство запросов. Вы можете отключить это, чтобы сохранить неопределённую веру в чуть большую приватность. 👀
[!WARNING] После внесения изменений необходимо переподключиться, чтобы они вступили в силу.
[!NOTE] Вам следует, вероятно, установить SNI в значение
zt-masque.cloudflareclient.com, указав флаг-s zt-masque.cloudflareclient.comпри использовании любого режима, включающего туннельное соединение. Значение по умолчаниюconsumer-masque.cloudflareclient.comтакже работает, но не рекомендуется.
Проект всё ещё находится на ранних стадиях разработки (я рад, что вообще заставил его работать), и производительность не была приоритетом. На самом деле я даже не слишком знаком с Go. Официальный клиент (по крайней мере, на Linux и Android) реализован на Rust с использованием отличного проекта quiche. В отличие от него, этот инструмент написан на Go и использует хорошо поддерживаемую библиотеку quic-go, которая предоставляет широкую поддержку протокола QUIC. Однако она поддерживает только алгоритм управления перегрузкой reno, и это не самая производительная реализация, особенно для сетей с высокой задержкой.
Многие другие функции, такие как happy eyeballs, также отсутствуют.
Так да, производительность может быть не самой лучшей. Однако мне удалось получить 833.60 Мбит/с на скачивание и 772.88 Мбит/с на загрузку при соединении 1 Гбит/с с Warp+ с первого раза, используя режим SOCKS5-прокси с Firefox и speedtest.net. Тест был проведён на конфигурации с AMD Ryzen 7 5700U, 16 ГБ оперативной памяти под управлением Arch Linux. Это достаточно хорошо для меня. Я уверен, что есть пространство для улучшения. Но имейте в виду, что это всё происходит в пользовательском пространстве; в режиме SOCKS даже эмулируется собственный сетевой стек. Использование CPU составляло около 26%.
Я слышал, что производительность на Windows хуже. У меня нет машины с Windows для тестирования. Если она есть у вас, пожалуйста, поделитесь своим опытом.
quic-go выдаст предупреждение, если эта величина слишком мала для вашей машины. Но размер буфера UDP по умолчанию в Linux довольно мал. Вы можете увеличить его, выполнив:
$ sudo sysctl -w net.core.rmem_max=7500000
$ sudo sysctl -w net.core.wmem_max=7500000
Обратитесь к документации quic-go для получения более подробного объяснения.
По умолчанию все режимы, кроме родного режима туннеля, используют Quad9 для разрешения DNS-трафика. Хотя это кажется странным выбором для клиента Cloudflare, я предпочитаю их 1.1.1.1 из-за их заявлений о приватности. Я считаю это приемлемым по умолчанию. Однако 1.1.1.1 обычно имеет лучшую производительность. Вы можете свободно изменить DNS-сервер, используемый инструментом, указав флаг -d.
Например:
$ ./usque socks -d 1.1.1.1 -d 1.0.0.1 -d 2606:4700:4700::1111 -d 2606:4700:4700::1001
Нативные туннели не настраивают DNS. Будет использоваться то, что установлено в вашей системе. Маршрутизация DNS-пакетов в туннель или куда-то ещё также полностью зависит от вас.
На данный момент это в первую очередь CLI-инструмент. Однако предпринимались усилия по документированию и выделению определённых функций, которые можно использовать для создания собственных приложений. Я не рекомендую этого делать на данном этапе, так как реализация довольно нестабильна и API может измениться. Я также не проделал отличную работу по абстракции, поскольку моей основной целью было заставить всё работать, а второй — сделать код легко читаемым. Поэтому вместо прямого использования в качестве библиотеки люди могут разветвить проект и добавить дополнительный функционал по своему усмотрению. Я открыт для PR, которые делают код более модульным и удобным для использования как библиотеку.
В качестве отправной точки вы можете обратиться к пакету api/). Для примеров посмотрите пакет cmd/).
H3_NO_ERROR. Подобное поведение ранее наблюдалось в их хорошо изученной реализации WireGuard, где слишком долго открытые соединения с незначительной сетевой активностью отключались. Официальные клиенты просто переподключаются в таком случае, поэтому я реализовал аналогичное поведение. Таким образом, если вы увидите отключения, не беспокойтесь, это, скорее всего, просто удалённый конец. Инструмент автоматически переподключится, как только вы сгенерируете исходящий трафик.-l).reno, используемым в quic-go. Это не самый производительный алгоритм, особенно в условиях высокой задержки. Нам придётся ждать поддержки других алгоритмов контроля перегрузки и посмотреть, как они сравнятся. Например, есть открытая проблема по BBR.TUN. Хотя оно существует на Android, без root-доступа его трудно использовать в текущем виде. Поддержка Windows была бы возможна, но у меня нет опыта с Windows API в части назначения IP-адресов сетевым интерфейсам. Поддержка BSD и macOS неясна. Все эти платформы в настоящее время не поддерживаются, поскольку у меня нет возможности их тестировать, и я не готов делиться непроверенным кодом. PR приветствуются.Едва ли можно отличить трафик MASQUE от другого трафика HTTP/3. Однако QUIC требует TLS v1.3, поэтому мы отправляем ClientHello с client-masque.cloudflareclient.com в поле SNI. Некоторые файрволы могут блокировать это. Вы можете изменить SNI, указав флаг -s на любой домен (судя по моему опыту), и соединение по-прежнему будет работать. Пожалуйста, учтите, что это определённо не предполагаемый случай использования Cloudflare (просто приятный побочный эффект). И перед любыми попытками обхода убедитесь, что вы не нарушаете никаких законов. Лично я вижу в этом только явную пользу для маскировки факта нашего подключения к Warp от перехватчиков (MiTMers).
Это зависит от ваших потребностей. 😊 WireGuard — отличный протокол, и его современная/быстрая криптография, а также возможность использования в режиме ядра — это замечательные вещи. Если он работает для вас, я не считаю, что вам следует переходить.
MASQUE работает в пространстве пользователей, как и QUIC, лежащий в его основе протокол, что делает реализацию более медленной. Хотя он также имеет определённые преимущества, такие как полноценная поддержка TLS (WireGuard поставляется с фиксированным набором шифров), настраиваемый контроль перегрузки, более продвинутые параметры тонкой настройки, он также и более сложен.
В конечном счёте, если вы довольны WireGuard, я не вижу причины для перехода. Если вы довольны Warp, но хотите использовать его на платформе, которая не имеет официальной поддержки, этот инструмент может быть для вас.
Этот документ был бы большим и слишком ужасным для среднего читателя, если бы я включил все детали о протоколе и исследовании, которое я провёл. Если вы из тех немногих людей, кого заинтересуют некоторые подробности, пожалуйста, обратитесь к файлу RESEARCH.md). Он обобщает проведённое мной исследование и найденные детали протокола в формате, похожем на запись в блоге. В будущем я планирую написать также чёткий и лаконичный документ по протоколу, который будет ссылаться здесь. В настоящее время там включён только HTTP/3.
В основном потому, что я хотел поэкспериментировать с крутыми новыми технологиями, и MASQUE привлёк моё внимание. Я был шокирован, увидев, что существует не так много реализаций с открытым исходным кодом, на самом деле я практически не видел практических применений connect-ip с открытым исходным кодом. Я хотел это изменить и немного "продвинуть".
Во-вторых, я часто полагаюсь на WARP для сайтов, проксированных через Cloudflare, поскольку пиринг между моим провайдером и обычными защищёнными Cloudflare сайтами не самый лучший. С WARP+ я получаю лучшие маршруты и более высокие скорости. Однако официальный клиент использует реализацию WireGuard, работающую в пространстве пользователей, поэтому я использовал wgcf вместо этого для запуска в режиме ядра. Он стал себя вести нестабильно в последнее время; по какой-то причине мне приходится переподключаться несколько раз каждый раз, когда я хочу его использовать. Он начинал работать после нескольких попыток, но это было раздражающе. В репозитории wgcf есть несколько открытых проблем, связанных с этим, например эта и эта. WireGuard также был заблокирован в поездном WiFi, а MASQUE — нет.
Затем я перешёл на официальный клиент и MASQUE, которые работали гораздо стабильнее. Однако всё приложение довольно тяжёлое (260 MiB сжатых для Android на момент написания этого текста). Cloudflare One, корпоративная версия, намного легче...
Но в любом случае, я обнаружил, что приложение потребляет слишком много памяти, и это даже не самое худшее.
Я понял это, спокойно сидя в поезде, бродя по интернету с включённым Warp. Периодически он вылетал и отключал всю VPN-профиль, оставляя мой трафик открытым для локальной WiFi сети. Это было довольно неприятно и стало последней каплей, которая заставила меня начать этот проект.
Хотя это пока не решает проблему переподключения, это запланировано. И с прыжком к open-source, я надеюсь, что сообщество поможет мне сделать этот инструмент лучше и надёжнее.
Потому что реализация от Cloudflare не совсем соответствует RFC 9484 и не будет работать без прямого monkey-patching библиотеки. Найдите мою уродливую, но надеюсь, работающую версию здесь.
Очевидно, я не планировал называть его warp, cloudflare или что-то подобное, чтобы уменьшить конфликты или чтобы пользователи не стучались в неправильную дверь за поддержкой из-за моих неудачных попыток реализации.
Поскольку лежащая в основе технология — MASQUE, я хотел придумать что-то короткое, запоминающееся и уникальное, но всё же связанное с базовой технологией. У меня было весёлые 4 года латыни в школе, поэтому я решил, что идеальное название будет usque. Если я доверяю своей ржавой памяти, это означает "весь путь" или "насквозь". Я подумал, что это хорошо подходит, потому что это инструмент, который прокладывает туннель насквозь к сети Cloudflare. Мы также проделываем долгий путь, пока это не станет стабильным. Вы понимаете... 😊 Это также (надеюсь) достаточно уникально, чтобы не конфликтовать с другими проектами.
Приветствуется участие. На самом деле я университетский студент с очень ограниченным временем и ресурсами. Пока инструмент в основном реализует мои потребности и идеи, но я хотел бы видеть, как он растёт и становится стабильнее со множеством захватывающих функций в будущем. Если у вас есть какие-либо идеи, предложения, отчёты об ошибках или даже вклад в код, не стесняйтесь открывать issue или pull request. Я постараюсь ответить вам.
Этот инструмент не существовал бы без следующих замечательных проектов. Пожалуйста, поставьте им все звёзды, если вам нравится этот проект!
RFC 9484~~ (это уже не так, см.)) Весь наш IP-туннель зависит от этого. Мы сильно полагаемся на мою форк-версию этого проекта.connect-udp и совместимых с RFC 9298 MASQUE-серверов, это был отличный отправной пункт при изучении темы.iproute2. Используется для нативного режима туннеля в Linux.connect-ip-go.netstack очень проста в использовании.Особая благодарность @monkeywave, одному из контрибьюторов friTap, который помог мне расшифровать последний кусочек информации, необходимый для работы этого инструмента. На самом деле, если бы не он, я бы, вероятно, бросил этот проект. Он помог мне и терпеливо провёл меня через процесс извлечения TLS-секретов из официального клиента. Стоит прочитать обсуждение этой проблемы, если вы заинтересованы. Один из лучших опытов в сообществе open-source. Спасибо!
Ещё одна благодарность @marten-seemann за поддержание всей экосистемы quic-go. Я также открывал несколько issue там и всегда получал полезный ответ. Спасибо!
Пожалуйста, не используйте этот инструмент во вред. В конечном счёте вы вредите Cloudflare, что, вероятно, несправедливо, учитывая, что вы получаете всё это бесплатно. Во-вторых, вы, скорее всего, приведёте к санкционированию этого инструмента и испортите всё для всех.
Инструмент имитирует определённые свойства официальных клиентов, это сделано в основном для обеспечения стабильности и совместимости. Я никогда не намеревался делать этот инструмент неотличимым от официальных клиентов. Это значит, что если они захотят обнаружить этот инструмент, они смогут. Я не несу ответственности за любые последствия, которые могут возникнуть в результате использования этого инструмента. Это абсолютно ваша собственная ответственность. Я не несу ответственности за любой ущерб, который может быть нанесён вашей системе или сети. Этот инструмент предоставляется «как есть», без каких-либо гарантий. Используйте на свой страх и риск.
Хотя инструмент создан с учётом соображений безопасности, я не эксперт по безопасности и не IT-специалист. Я просто энтузиаст, и это лишь любительский проект. Снова: используйте на свой страх и риск. Однако отчёты о проблемах безопасности приветствуются. Свободно откройте issue с вашими контактными данными, и я свяжусь с вами, чтобы вы могли поделиться своими находками В ЧАСТНОМ ПОРЯДКЕ. После того как пройдёт достаточно времени для исправления проблемы, я укажу вас в списке изменений, и находки смогут стать общедоступными. Я ценю любую помощь в улучшении безопасности этого инструмента.
Этот инструмент никоим образом не связан с Cloudflare. Инструмент не был ни одобрен, ни рассмотрен Cloudflare. Это независимый исследовательский проект. Cloudflare Warp, Warp+, 1.1.1.1™, Cloudflare Access™, Cloudflare Gateway™ и Cloudflare One™ являются зарегистрированными товарными знаками Cloudflare, Inc. Если вы сотрудник Cloudflare и считаете, что этот проект каким-либо образом вреден, пожалуйста, откройте issue, и я приложу все усилия, чтобы связаться с вами и решить проблему.
WireGuard™ является зарегистрированным товарным знаком Jason A. Donenfeld.