Пошла волна новостей о том, что провайдеры получили прямую задачу внедрять систему «Белых списков» на wifi. Официальная версия — «безопасность» и доступность социально значимых ресурсов. Но все мы прекарсно все понимаем: это не столько про удобство, сколько про возможность 24/7 фильтровать вообще всё, что проходит через ваш домашний Wi-Fi.

Народ уже вовсю обсуждает последствия: во-первых, общая скорость домашнего интернета гарантированно просядет, ведь оборудованию провайдера придется не просто пропускать трафик, а постоянно сверяться с «белыми списками». Во-вторых, возникает куча вопросов к конкуренции: если яндекс или какой-нибудь гос-сервис будет в «белом списке», а условный мелкий бизнес или зарубежный сервис — нет, то они просто исчезнут для пользователя. Есть и смешные, но грустные теории — типа того, что при включении этой системы мы даже личный кабинет провайдера не сможем открыть, чтобы просто оплатить интернет.

Техническая реальность: как УМНЫЙ DPI «грызет» наши соединения

На фоне всей этой движухи с «списками» пользователи начали замечать, что привычные инструменты (типа VLESS+Reality или XHTTP) стали отваливаться буквально на ровном месте.

Причем это не всегда банальная блокировка по IP:Port. Вот пример из практики: на сервере стоит сайт на Nginx, висящий на том же порту, что и прокси. Сайт открывается без проблем, а вот прокси — нет. Если запустить tcpdump и сравнить ClientHello на входе и на выходе, вскрывается интересная картина: пакеты прилетают уже «покоцанными». Поля IP TOS меняются с 0x00 на 0x28, внутри перетасованы Cipher Suites, Client Random и размеры полей. Естественно, REALITY видит этот мусор, выдает ошибку failed to read client hello и рвет коннект.

Многие уверены, что дело не в самих протоколах, а в «утечке» вашего inbound IPv4. Сервисы-шпионы просто сливают IP куда надо, он попадает в реестры, и прилетает бан на всех узлах УМНОГО DPI. Есть рабочая схема: разделять inbound и outbound. Старый, «зашкваренный» IP оставляем для исходящих (outbound) по умолчанию, а для входящих соединений (inbound) берем новый, «чистый» белый IPv4. Люди пишут, что после такой рокировки обрывы внезапно пропадают.

Но с ''списками'' всё станет куда веселее. Сейчас народ пытается использовать VPS (например, в Сберклауде — там виртуалка бесплатная, платишь только 149р за белый IP), но даже они при включенных ''списках'' часто не пингуются. Подсети типа 82.202.156.27/23 улетают в утиль сразу. Провайдеры, видимо, начали просто резать целые пулы адресов, которые им не нравятся. В общем, коммерциализация блокировок вводит новые правила игры, и теперь нам придется искать способы мимикрировать под что-то «легитимное», возможно, даже вешать на свой VPS полноценные сайты, чтобы хоть как-то пройти эти «фильтры».

Почему «ванильный» VLESS стал проблемным и при чем тут TURN-сервера?

Если с блокировкой по IP еще можно как-то бороться (смена провайдера, покупка новых IP, переезд на другие подсети), то с протоколами всё стало куда хуже. В последнее время стало понятно, что классические методы, которыми мы привыкли «пробивать» стену, начинают захлебываться.

Почему UDP — это теперь боль?

Многие пытаются использовать прокси, которые заворачивают трафик в DTLS (по сути — UDP). Логика ясна: UDP быстрый, не требует постоянного подтверждения доставки пакетов, как TCP. Но вот незадача: «ванильный» VLESS через такую проксю работать нормально не будет. Почему? Потому что сама прокси слушает UDP-сокет и может проксировать только протоколы, заточенные под UDP.

Если вы попробуете пропатчить конфиг, чтобы заставить ее слушать TCP-сокет, результат будет печальный — работать всё будет как «говно». Почему? Потому что вы начинаете терминировать TCP-подключение, выдирать данные из потока и упаковывать их в DTLS. А DTLS по UDP не дает гарантий доставки. Ни клиент, ни сервер VLESS к такому раскладу не готовы (в отличие от той же Hysteria2 или mKCP, где свои механизмы ретрансмиссий). Чтобы это работало стабильно, нужно пилить полноценный TUN-интерфейс, который будет сырые TCP-пакеты паковать в DTLS. Но на выходе мы получим что-то вроде кривого, бледного WireGuard, который еще и работать будет через раз.

А что там с TURN?

Тут в чатах всплыла интересная тема про TURN-сервера. Люди спрашивают: «А можно ли сделать так, чтобы несколько потоков шли через разные TURN-сервера по разным ссылкам, чтобы хоть как-то поднять общую скорость?».

Спойлер: прямо «из коробки» это реализовать довольно сложно. Народ пробует разные конфигурации, но натыкается на проблемы. Например, кто-то жалуется, что не может завести звонки или передачу данных, а потом выясняется, что виноват вовсе не протокол, а банальный AdGuard, который по своей логике блокирует WebRTC (а он критически важен для подобных коннектов). Или файрвол на новом сервере просто не пускает пакеты через интерфейс wg0.

В итоге мы имеем такую картину:
1. Проксирование UDP — это всё еще «костыли». Стабильного решения, которое работало бы как обычный TCP, пока не видно.

2. WebRTC и TURN — тема перспективная, но капризная. Один кривой конфиг файрвола, или «умный» блокировщик рекламы в браузере — и вся ваша хитрая схема рассыпается в прах.

3. Общий вывод: методы становятся всё сложнее. Если раньше хватало простого VLESS+Reality, то сейчас нужно настраивать целые сети из прокси, бороться с MTU, прокидывать TUN-интерфейсы и следить, чтобы клиентский софт не резал трафик раньше времени.

Сейчас получается так: чем больше «наворотов» ты добавляешь в конфиг, тем выше шанс, что алгоритмы провайдера вычислят твой трафик как «аномальный». Мы находимся в ситуации гонки вооружений: они внедряют Списки и фильтры, мы — пытаемся замаскировать свой трафик под обычный серфинг, но при этом сами же усложняем его настолько, что он начинает выделяться на фоне обычного HTTPS-трафика.

Как выжить, когда каждый IP под прицелом?

Итак, мы выяснили: просто поднять «ванильный» прокси на купленном VPS — это путь к быстрому бану. Провайдеры (особенно в Москве) сейчас активно анализируют не только протоколы, но и сам «профиль» вашего IP. Если на сервере «голый» адрес, который ни на что не отвечает, кроме вашего прокси-порта, для системы УМНОГО DPI это идеальный маркер «подозрительного узла».

Почему VPS «из коробки» не работают?

Народ сейчас массово тестит облака (типа того же SberCloud и аналогов), но ситуация везде плюс-минус одинаковая. Покупаешь VPS, платишь за белый IP, а он уже «мертвый» — не пингуется, соединения сбрасываются. Почему так? *

Триггер активности: Если ваш IP «светится» в каких-то публичных базах или, наоборот, ведет себя как «тихий» узел, который гоняет трафик только в одну сторону, система ставит на него флажок. *

Коммерциализация банов: Есть мнение, что блокировки стали массовыми и автоматизированными. Если ты берешь пачку IP и начинаешь их менять, система может это «проглот��ть». Но если делать это слишком часто или использовать известные подсети хостеров, которые провайдеры «пристреляли» — IP улетает в блок в течение пары часов.

Как пытаются мимикрировать?

Те, кто до сих пор «в игре», используют новую тактику:

1. Легитимизация: На свой белый IP нужно обязательно повесить «белый» сайт. Обычный лендинг на Nginx, какой-то контент, сертификат Let's Encrypt. Нужно, чтобы при заходе по IP (или через домен) система видела «обычный веб-сервер», а не «черную дыру».

2. Отказ от частых смен: Вместо того чтобы каждый день менять IP, лучше один раз настроить «правильную» маскировку. Нужно прикинуться чем-то настолько обыденным, чтобы алгоритм анализа трафика просто не решился резать соединение.

3. Разделение потоков: Как я уже писал ранее, схема с разделением inbound (входящий) и outbound (исходящий) — это база. Держите «грязный» IP для внешних запросов, а «чистый» — только для связи с клиентом.

Если же вам лень всем этим заниматься самостоятельно, то можно прибегнуть уже к готовым решениям, в некторых из них нужно сделать лишь немного, в других же уже все сделано за вас

Готовые Решения


1. Hynet.space — Это уже ближе к категории готовых сервисов.

В чем прикол: По сути, вы платите за то, чтобы кто-то другой взял на себя геморрой с поиском «чистых» IP и настройкой маскировки. Они уже решили задачу легитимизации: у них есть сервера с нормальными сайтами, настроенным TLS и правильными заголовками.

2. Скрипты и мануалы с GitHub — Например, различные форки (вроде whitelist-bypass или специализированные сборки AmnesiaVPN/`AmneziaWG

Это попытка автоматизировать борьбу с DPI. Скрипт сам подменяет заголовки, пытается «замаскировать» протокол под обычный HTTPS и иногда даже умеет сам настраивать маршрутизацию.

3. Использование TURN-серверов — Как я уже писал, это сейчас самый «умный» способ обхода через инфраструктуру гигантов.

Суть: Мы притворяемся, что гоняем видео или аудио через Яндекс/VK. Это чертовски сложно забанить, не сломав UX обычным людям. Но опять же, как только схема станет массовой, её либо прикроют для этих сервисов, либо начнут жестко шейпить трафик.

4. RTC Tunnel — Есть проект RTC Tunnel, который позволяет организовать P2P-соединение через WebRTC.

Как это работает: Ты поднимаешь «сервер» на своей удаленной машине (например, VPS) и «клиент» на домашнем ПК. Программа устанавливает WebRTC-сессию, и через неё пробрасывается TCP-порт (например, для SSH или прокси).

5. AmneziaVPN / AmneziaWG — Это не «волшебная кнопка», но если вы готовы лезть в консоль и вручную править MTU, экспериментировать с портами, перебирать разные способы обфускации, чтобы подобрать ту, которую ваш провайдер еще не научился резать то вам сюда. Иногда приходится вручную выпиливать ненужные маршруты или «допиливать» серверную часть, чтобы обойти блокировку конкретной подсети хостера. Это отличный конструктор, но если вы не готовы периодически лазить в логи и перенастраивать конфиги после очередного обновления фильтров — будете сидеть со статусом «подключено» и нулевым трафиком.

Реалии

Не питайте иллюзий — интернет в привычном виде меняется на глазах. Мы переходим в стадию, где доступ к информации становится результатом технической смекалки. Завтра всё может опять «сломаться», и это не повод для паники, а очередной повод сесть, открыть логи и посмотреть, что там придумали на этот раз.