SOCKS-прокси — это точка входа. Ты поднимаешь его в стране, откуда хочешь «выходить». Для прокси не нужен резидентский адрес, никто не спрашивает прописку. Я, к примеру, для тестов разворачивал в Azure и Google Cloud — это занимает пару минут.
Дальше магия простая:
Трафик идёт через этот прокси, и Warp видит, что ты «пришёл» из страны, где стоит датацентр.
Warp не банит датацентровые адреса — наоборот, спокойно принимает их.
Потом Warp выпускает тебя в интернет уже со своего IP.
Фишка в том, что у Warp свои подсети, и многие сервисы их считают «нормальными» резидентскими адресами. То есть сайт думает: ага, пользователь из такой-то страны, и IP похож на домашний.
По сути, схема двух шагов:
Прокси в нужной стране → показываешь Warp, что ты там.
Warp выпускает наружу через свои IP → сайты считают, что это реальный «местный» юзер.
Немного переписал этот абзац, надеюсь стало лучше. Ключевой момент в том, что с помощью SOCKS-прокси можно подключаться к инфраструктуре WARP в нужной стране. Поскольку сам по себе WARP не предоставляет возможности смены региона, его трафик обычно классифицируется сервисами как резидентский. Именно это и позволяет обходить региональные ограничения без характерных проблем, с которыми сталкиваются обычные VPN.
Я настроил пару таких прокси (один в UK, другой в US) для экспериментов, креды можно взять здесь.
Посмотрим, чем завершится эта история. На мой взгляд, это тянет на баг в I/O Manager: если поток заблокирован на синхронной операции ввода-вывода, то любой ранее инициированный им асинхронный I/O фактически лишается шансов на завершение или отмену.
Само приложение никуда не ходит, исходники доступны, можете пересобрать если чего опасаетесь. Да, оно просит разрешения открыть порт для прокси, так как соединения редиректятся на локальный прозрачный прокси и только потом на удаленный. Соединения про которые вы пишете скорее всего связаны с проверкой цифровой подписи приложения.
Спасибо большое за добрые слова! Рад, что программа помогает. В новой версии немного поработал над сетевой частью — если будет возможность, посмотрите, пожалуйста, как сейчас обстоят дела с пингом. Я сам немного потестировал, но очень хотелось бы услышать новости с полей :)
Да, смысл именно в этом. Если бы реализация обфускации была внешней по отношению к протоколу Wireguard все было бы несколько проще. В частности, мне не пришлось бы впиливать дополнительные параметры непосредственно в BoringTun. Если в подходе Amnezia и есть смысл, то только маркетинговый.
Идея заключается в том, чтобы применять обфускацию поверх уже зашифрованных пакетов, а не внедрять её напрямую в реализацию протокола. В таком подходе обфускатор можно было бы вынести в отдельный компонент — например, в UDP-прокси. В случае с Amnezia это, к сожалению, невозможно.
Напомнило о стародавних временах, когда система антиплагиата благополучно сдавалась после замены одной кириллической буквы «л» на другую. Визуально — ни малейшей разницы, а в Unicode это разные символы: обычная «л» и заковыристая из расширенного диапазона. Алгоритм был не в курсе, зато диплом — уникальный.
Да, есть подозрение, что сработал абзац про Ростелеком и WireGuard. Всё-таки обидно, когда на систему блокировки уходит столько ресурсов, а её можно обойти парой псевдослучайных пакетов. ☺️
Создайте файл /usr/local/bin/send-noise.sh со следующим содержимым:
#!/bin/bash
# Адрес и порт WireGuard-сервера
ENDPOINT_IP="1.2.3.4"
ENDPOINT_PORT="51820"
# Отправить 5 случайных пакетов по UDP
for i in {1..5}; do
head -c 100 /dev/urandom | nc -u -w1 "$ENDPOINT_IP" "$ENDPOINT_PORT"
sleep 0.2
done
exit 0
Сделайте скрипт исполняемым:
chmod +x /usr/local/bin/send-noise.sh
2. Настройка wg0.conf
Откройте /etc/wireguard/wg0.conf и добавьте строчку PreUp:
Важно:ENDPOINT_IP и ENDPOINT_PORT в скрипте должны соответствовать Endpoint из [Peer].
3. Подключение
sudo wg-quick up wg0
Перед началом хендшейка WireGuard отправит 5 псевдослучайных UDP-пакетов на сервер, что может помочь обойти фильтрацию или имитировать предварительный трафик.
Сочувствую. Конечно, при наличии неограниченных ресурсов со стороны DPI можно реализовать практически любой уровень контроля над трафиком — вплоть до полноценного DLP на уровне всей страны. Всё упирается исключительно в объём доступных технических и человеческих ресурсов.
На проводных сетях с мусорными пакетами перед handshake к тому же завернутый в SOCKS пока в основном работает.
SOCKS-прокси — это точка входа. Ты поднимаешь его в стране, откуда хочешь «выходить». Для прокси не нужен резидентский адрес, никто не спрашивает прописку. Я, к примеру, для тестов разворачивал в Azure и Google Cloud — это занимает пару минут.
Дальше магия простая:
Трафик идёт через этот прокси, и Warp видит, что ты «пришёл» из страны, где стоит датацентр.
Warp не банит датацентровые адреса — наоборот, спокойно принимает их.
Потом Warp выпускает тебя в интернет уже со своего IP.
Фишка в том, что у Warp свои подсети, и многие сервисы их считают «нормальными» резидентскими адресами. То есть сайт думает: ага, пользователь из такой-то страны, и IP похож на домашний.
По сути, схема двух шагов:
Прокси в нужной стране → показываешь Warp, что ты там.
Warp выпускает наружу через свои IP → сайты считают, что это реальный «местный» юзер.
Немного переписал этот абзац, надеюсь стало лучше. Ключевой момент в том, что с помощью SOCKS-прокси можно подключаться к инфраструктуре WARP в нужной стране. Поскольку сам по себе WARP не предоставляет возможности смены региона, его трафик обычно классифицируется сервисами как резидентский. Именно это и позволяет обходить региональные ограничения без характерных проблем, с которыми сталкиваются обычные VPN.
Я настроил пару таких прокси (один в UK, другой в US) для экспериментов, креды можно взять здесь.
Посмотрим, чем завершится эта история. На мой взгляд, это тянет на баг в I/O Manager: если поток заблокирован на синхронной операции ввода-вывода, то любой ранее инициированный им асинхронный I/O фактически лишается шансов на завершение или отмену.
Да, этому API больше 20 лет...
Microsoft Premier Support
RIPE Atlas полезный инструмент. А probe я завел на роутере в гостевую сеть без доступа к домашней.
Спасибо за отзыв! Рад, что софт помог. С GUI согласен — подумаю, что тут можно сделать.
Если бы драйвер что-то такое и делал, поверьте, вы бы этого не заметили. К тому же реверснуть драйвер несложно, он очень небольшой.
Само приложение никуда не ходит, исходники доступны, можете пересобрать если чего опасаетесь. Да, оно просит разрешения открыть порт для прокси, так как соединения редиректятся на локальный прозрачный прокси и только потом на удаленный. Соединения про которые вы пишете скорее всего связаны с проверкой цифровой подписи приложения.
Под Windows?
Спасибо большое за добрые слова! Рад, что программа помогает. В новой версии немного поработал над сетевой частью — если будет возможность, посмотрите, пожалуйста, как сейчас обстоят дела с пингом. Я сам немного потестировал, но очень хотелось бы услышать новости с полей :)
Да, смысл именно в этом. Если бы реализация обфускации была внешней по отношению к протоколу Wireguard все было бы несколько проще. В частности, мне не пришлось бы впиливать дополнительные параметры непосредственно в BoringTun. Если в подходе Amnezia и есть смысл, то только маркетинговый.
Идея заключается в том, чтобы применять обфускацию поверх уже зашифрованных пакетов, а не внедрять её напрямую в реализацию протокола. В таком подходе обфускатор можно было бы вынести в отдельный компонент — например, в UDP-прокси. В случае с Amnezia это, к сожалению, невозможно.
Напомнило о стародавних временах, когда система антиплагиата благополучно сдавалась после замены одной кириллической буквы «л» на другую. Визуально — ни малейшей разницы, а в Unicode это разные символы: обычная «л» и заковыристая из расширенного диапазона. Алгоритм был не в курсе, зато диплом — уникальный.
Да, есть подозрение, что сработал абзац про Ростелеком и WireGuard. Всё-таки обидно, когда на систему блокировки уходит столько ресурсов, а её можно обойти парой псевдослучайных пакетов. ☺️
Думаю под Линуксом можно использовать
PreUp-скрипт в конфигурацииwg-quick1. Скрипт
send-noise.shСоздайте файл
/usr/local/bin/send-noise.shсо следующим содержимым:Сделайте скрипт исполняемым:
2. Настройка
wg0.confОткройте
/etc/wireguard/wg0.confи добавьте строчкуPreUp:Важно:
ENDPOINT_IPиENDPOINT_PORTв скрипте должны соответствоватьEndpointиз[Peer].3. Подключение
Перед началом хендшейка WireGuard отправит 5 псевдослучайных UDP-пакетов на сервер, что может помочь обойти фильтрацию или имитировать предварительный трафик.
Не тестировал, но выглядит правдоподобно.
Сочувствую. Конечно, при наличии неограниченных ресурсов со стороны DPI можно реализовать практически любой уровень контроля над трафиком — вплоть до полноценного DLP на уровне всей страны. Всё упирается исключительно в объём доступных технических и человеческих ресурсов.
Лыжи под мышку — и в сторону заката ☺️
Судя по личным наблюдениям и отчетам пользователей, в подавляющем большинстве случаев этого пока оказывается достаточно.