Всем привет
Это расширенная версия моей первой статьина тему tcp, тспу и прочего, если не читали первую часть(она можно сказать как введение к этой статье) - welcome
Скажу заранее, я буду приводить и простые аналогии, и сложные "гиковские" термины и иллюстрации
Приятного чтения!
Блок 1. Фундаментальная архитектура сетей: Модель OSI, инкапсуляция и анатомия пакета
Блок 2. Транспортный уровень (L4) под микроскопом: Стейт-машина TCP и анархия UDP
Блок 3. Эволюция веба: Контроль перегрузок, протокол QUIC и жестокий Downgrade
Блок 4. Криптография и TLS-рукопожатие: Главная дыра современного интернета
Блок 5. Архитектура цензуры: ТСПУ, DPI и топология сетей
Блок 6. Механика удушения: Стейт-машины, Рессемблинг и алгоритм Token Bucket
Блок 7. Практический кейс: Хронология удушения YouTube
Блок 8. Теория обхода DPI: Десинхронизация и почему классический VPN умирает
Блок 9. Анатомия магии: Как программно работают GoodbyeDPI и Zapret
Блок 10. Будущее интернета: Гонка вооружений, ECH и угроза "Белых списков"
Блок 2. Транспортный уровень (L4) под микроскопом: Стейт-машина TCP и анархия UDP
Блок 3. Эволюция веба: Контроль перегрузок, протокол QUIC и жестокий Downgrade
Блок 4. Криптография и TLS-рукопожатие: Главная дыра современного интернета
Блок 5. Архитектура цензуры: ТСПУ, DPI и топология сетей
Блок 6. Механика удушения: Стейт-машины, Рессемблинг и алгоритм Token Bucket
Блок 7. Практический кейс: Хронология удушения YouTube
Блок 8. Теория обхода DPI: Десинхронизация и почему классический VPN умирает
Блок 9. Анатомия магии: Как программно работают GoodbyeDPI и Zapret
Блок 10. Будущее интернета: Гонка вооружений, ECH и угроза "Белых списков"
Блок 1. Фундаментальная архитектура сетей: Модель OSI, инкапсуляция и анатомия пакета
Интернет не работает магическим образом. Это строгая, многоуровневая система спецификаций и стандартов. Чтобы понять, как работает Deep Packet Inspection (DPI) и почему мы можем его обманывать, необходимо понимать, как данные преобразуются перед тем, как покинуть вашу сетевую карту.
1.1. Эталонная модель OSI (Open Systems Interconnection)
Сетевое взаимодействие принято делить на 7 уровней абстракции. Каждый уровень решает свою узкую задачу и общается только с соседними уровнями (выше и ниже).
Для наших задач (анализ блокировок и обхода) нас интересуют не все уровни, но давайте пройдемся по стеку снизу вверх:
• L1. Физический уровень (Physical): Здесь нет никаких данных, только напряжение, радиоволны или свет в оптике. Единица измерения - Бит (Bit).
• L2. Канальный уровень (Data Link): Отвечает за передачу в пределах одной физической сети. Здесь работают MAC-адреса, ARP-таблицы и коммутаторы. Единица измерения - Кадр (Frame).
• L3. Сетевой уровень (Network): (Важно!) Обеспечивает логическую адресацию и маршрутизацию между разными сетями. Главный протокол - IPv4 / IPv6. Железо - маршрутизаторы. Единица измерения - Пакет (Packet).
• L4. Транспортный уровень (Transport): (Критически важно!) Отвечает за доставку данных от процесса к процессу (через порты). Здесь живут протоколы TCP и UDP. Единица измерения - Сегмент (для TCP) или Датаграмма (для UDP).
• L5-L6. Сеансовый и Представительский: Здесь происходит установка криптографических сессий (TLS/SSL) и кодирование данных.
• L7. Прикладной уровень (Application): (Критически важно!) Уровень конечных приложений. Здесь работают HTTP, DNS, FTP. Именно сюда лезет DPI, чтобы прочитать ваш SNI. Единица измерения - Данные (Data / Payload).
Ремарка: Оборудование ТСПУ (РКН) работает как глубокий анализатор, то есть оно разбирает трафик начиная с L3 и вплоть до L7 уровня.
1.2. Процесс инкапсуляции (Принцип матрешки)
Когда вы отправляете запрос к YouTube, ваши L7 данные не летят в сеть голыми. Они проходят процесс инкапсуляции - обрастают служебными заголовками на каждом уровне модели OSI при движении вниз.
1. Ваш браузер формирует HTTP-запрос (L7 Data).
2. На транспортном уровне (L4) этот кусок данных заворачивается в TCP-заголовок. В нем прописываются порты (например, source: 54321, destination: 443). Теперь это называется TCP-сегментом.
3. На сетевом уровне (L3) сегмент заворачивается в IP-заголовок. Прописываются Source IP (ваш) и Destination IP (сервер Google). Теперь это IP-пакет.
4. На канальном уровне (L2) пакет заворачивается в Ethernet-кадр с MAC-адресами вашего роутера и провайдера.
5. На принимающей стороне (или на DPI) происходит Декапсуляция - распаковка заголовков снизу вверх.
1.3. Анатомия L3: Структура IPv4 пакета
Разблокировка сайтов часто сводится к модификации конкретных битов в заголовках. Давайте под микроскопом посмотрим на заголовок стандарта IPv4 (он занимает минимум 20 байт).
Из десятка полей нас сейчас интересуют три самых главных, с которыми мы будем работать в следующих блоках:
• Protocol (8 бит): Идентификатор того, что лежит внутри IP-пакета (в Payload). Если там значение 0x06 - значит внутри TCP. Если 0x11 - внутри UDP. DPI читает это поле, чтобы понять, какой парсер запускать дальше.
• Source / Destination IP Address (по 32 бита): Логические адреса. ТСПУ может блокировать трафик тупо по блэклисту IP-адресов получателя (так сейчас блокируют инсту или сервера Discord).
• TTL (Time To Live - 8 бит): Самое важное поле для обхода блокировок! Изначально создано для защиты от бесконечных циклов маршрутизации. Каждое устройство (роутер) на пути пакета уменьшает значение TTL на 1. Если TTL падает до нуля - пакет уничтожается (drop), а отправителю возвращается ICMP-сообщение "Time Exceeded".
Именно манипуляция полем TTL позволяет программам вроде GoodbyeDPI скармливать ТСПУ фейковые пакеты, которые "умирают" сразу после прохождения цензора и никогда не доходят до конечного сервера. Но об этой магии мы поговорим в Блоке 9.
Блок 2. Транспортный уровень (L4) под микроскопом: Стейт-машина TCP и анархия UDP
Итак, L3 (IP-пакет) успешно доставил наши данные до нужного компьютера. Но на компьютере одновременно работают сотни программ: браузер, телеграм, дискорд, торренты. Как операционная система понимает, какому именно приложению отдать прилетевшие байты?
Для этого существует Транспортный уровень (L4) и концепция Портов (от 0 до 65535).
Трафик ютуба летит на порт 443 (HTTPS), а DNS-запросы - на порт 53. Но разные задачи требуют разных гарантий доставки. Поэтому на L4 у нас есть два абсолютно разных протокола.
2.1. UDP (User Datagram Protocol) - Курьер без тормозов
UDP - это протокол без установления соединения (stateless). Его девиз: "Fire and forget" (Выстрелил и забыл).
Заголовок UDP смехотворно мал - всего 8 байт (Порт отправителя, Порт получателя, Длина и Чексумма).
Как это работает:
Приложение просто берет кусок данных, клеит сверху 8-байтовый стикер UDP и со всей дури швыряет его в сеть.
UDP не проверяет, дошел ли пакет. Он не восстанавливает порядок пакетов (если 2-й пакет обогнал 1-й, это проблемы приложения). Он не снижает скорость, если сеть перегружена.
Долгое время считалось, что UDP годится только для онлайн-игр, стриминга и DNS-запросов (где важнее скорость, а потеря одного кадра не критична). Но всё изменилось, когда Google решил натянуть сову на глобус и создал поверх UDP протокол QUIC, добавив туда криптографию и контроль доставки, но без тормозов TCP. (Об этом подробно в Блоке 3).
2.2. TCP (Transmission Control Protocol) - Фундамент цензуры
В отличие от UDP, TCP - это тяжеловесная, параноидальная стейт-машина (протокол с сохранением состояния - stateful). Он гарантирует, что каждый байт дойдет до получателя в идеальном порядке. Без TCP не было бы ни веба (HTTP), ни скачивания файлов, ни SSH.
Заголовок TCP огромный (минимум 20 байт) и содержит критически важные для обхода DPI поля:
1. Sequence Number (SEQ) и Acknowledgment Number (ACK):
Это номера пакетов. TCP нумерует каждый отправленный байт. Получатель обязан ответить пакетом-квитанцией (ACK): "Я получил байты до номера 1000, жду 1001-й". Если ACK не пришел вовремя, TCP агрессивно начинает ретрансмиссию (отправляет пакет заново).
2. Флаги (Control Bits):
Это 6 битов (переключателей), которые управляют состоянием соединения.
• SYN (Synchronize): Открывает соединение.
• ACK (Acknowledgment): Подтверждает получение.
• FIN (Finish): Вежливое завершение соединения (обе стороны согласны разойтись).
• RST (Reset): Агрессивный сброс. Переводится как: "Да пошел ты нахуй".
Обратите внимание на флаг RST! Это любимое оружие ТСПУ. Когда железяка Роскомнадзора видит, что вы лезете на заблокированный сайт, она не просит вас вежливо уйти (FIN). Она генерирует фейковый пакет с флагом RST и кидает его вам в лицо, мгновенно убивая сессию на уровне ядра вашей ОС.
3. Window Size (Размер окна):
Сколько байт можно отправить до того, как потребуется ждать подтверждения (ACK).
Еще один спойлер: GoodbyeDPI умеет искусственно занижать Window Size до крошечных значений, заставляя ваш ПК разбивать "запрещенное" слово (SNI) на кучу микро-пакетов (фрагментация), от чего у DPI-системы буквально едет крыша и не хватает памяти на их склейку.
2.3. Танец бюрократов: 3-Way Handshake
TCP никогда не начнет передачу полезных данных (например, HTTP-запроса) сразу. Сначала он обязан установить состояние ESTABLISHED (Соединение установлено) через трехкратное рукопожатие:
1. Клиент -> Сервер: Пакет с флагом SYN ("Привет, хочу открыть соединение, мой начальный номер SEQ=100").
2. Сервер -> Клиент: Пакет с флагами SYN + ACK ("Привет, я получил твой 100, мой начальный номер SEQ=300").
3. Клиент -> Сервер: Пакет с флагом ACK ("Подтверждаю твой 300, погнали").
И только в 4-м пакете (Push) полетят реальные данные.
Почему это важно для цензуры?
Потому что DPI-система (ТСПУ) на сетях провайдера тоже работает как стейт-машина (Stateful Inspection). Она молча наблюдает за этим танцем. Она видит SYN, видит SYN-ACK, и записывает в свою оперативную память: "Ага, открылось новое TCP-соединение между Васей и IP-адресом X".
Если бы DPI не следил за флагами и порядком сессий, он бы просто захлебнулся в мусорном трафике. И именно эту зависимость DPI от состояний TCP мы будем нещадно эксплуатировать при обходе блокировок.
Блок 3. Эволюция веба: Контроль перегрузок, протокол QUIC и жестокий Downgrade
В предыдущем блоке мы выяснили, что TCP - это надежный, но очень тяжелый протокол. Его главная проблема кроется в механизме, который изначально создавался во благо, но стал главным оружием цензоров - Congestion Control (Контроль перегрузок).
3.1. Окно перегрузки (cwnd) и алгоритм CUBIC
Представьте, что вы скачиваете файл. Ваш ПК и сервер не могут сразу забить канал на 1 гигабит - маршрутизаторы по пути просто захлебнутся и начнут выкидывать пакеты.
Поэтому TCP использует переменную cwnd (Congestion Window) - количество байт, которое можно отправить без подтверждения.
Большинство операционных систем (Linux, Windows) исторически используют алгоритмы контроля перегрузок вроде Reno или CUBIC. Их логика примитивна и работает по принципу AIMD (Additive Increase, Multiplicative Decrease):
1. Медленный старт: Окно растет экспоненциально (1, 2, 4, 8 пакетов). Скорость увеличивается.
2. Потеря пакета (Loss): Если хотя бы один пакет теряется по дороге (не пришел ACK-ответ вовремя), алгоритм впадает в панику. Он считает, что физический кабель забит под завязку.
3. Наказание: Алгоритм моментально режет окно cwnd в 2 раза. Скорость падает вдвое.
Именно этот механизм используют провайдеры для примитивного шейпинга (замедления). Оборудование провайдера (или ТСПУ) просто искусственно выкидывает 1-2% ваших TCP-пакетов. Ваш тупой CUBIC видит потери, думает "сеть перегружена" и сам добровольно душит вашу скорость до состояния диалапа.
3.2. Google наносит ответный удар: Алгоритм BBR
Инженеры Google поняли, что в современном интернете (особенно на мобильных сетях) пакеты теряются постоянно, и это не всегда значит, что канал перегружен (пакет мог просто потеряться из-за помех радиоэфира).
Поэтому Google для своих серверов (включая YouTube) разработал собственный алгоритм - BBR (Bottleneck Bandwidth and Round-trip propagation time).
BBR игнорирует потерю пакетов. Вместо этого он постоянно измеряет реальную пропускную способность канала и пинг (RTT). Если пакет потерялся, но пинг остался хорошим - BBR не снизит скорость ни на мегабит. Он будет агрессивно пушить видео в ваш плеер.
Из-за BBR просто так замедлить ютуб, выкидывая пакеты, стало очень сложно - серверы Гугла сопротивляются шейпингу до последнего.
3.3. Побег от TCP: Протокол QUIC (HTTP/3)
Но Google пошел еще дальше. TCP устарел архитектурно.
Во-первых, у TCP есть проблема HoL Blocking (Блокировка начала очереди): если из потока теряется один пакет, весь остальной поток ставится на паузу, пока этот пакет не будет переотправлен.
Во-вторых, 3-way handshake + TLS рукопожатие занимают слишком много времени (высокий RTT).
Поэтому Google создал QUIC (HTTP/3).
Инженеры взяли быстрый, но глупый UDP (из Блока 2) и реализовали поверх него всю логику надежности, криптографии (TLS 1.3 вшит по умолчанию) и мультиплексирования.
Главные фишки QUIC:
• Нет HoL Blocking: потоки независимы. Если потерялся кусок аудио, видео продолжит грузиться.
• 0-RTT: При повторном подключении к серверу данные начинают передаваться в первом же пакете, без "рукопожатий".
• Полная шифровка: В отличие от TCP, где заголовки открыты, в QUIC зашифровано почти всё, включая номера пакетов. DPI-системам стало невероятно сложно понимать, что происходит внутри QUIC-сессии.
3.4. Оружие ТСПУ: Downgrade-атака
Итак, 2024 год. Ютуб работает по сверхбыстрому QUIC поверх UDP. Трафик зашифрован, потери пакетов алгоритму BBR не страшны. Как ТСПУ (DPI Роскомнадзора) всё это ломает?
Очень просто: грубой силой.
Цензоры ненавидят QUIC. Они не могут залезть внутрь UDP-датаграмм и прочитать стейты. Поэтому ТСПУ делает классический Fallback / Downgrade (принудительное понижение версии протокола).
Как это выглядит на практике:
1. Ваш браузер пытается открыть видео и шлет UDP-пакет на порт 443 серверам Google (пытается поднять QUIC).
2. Оборудование ТСПУ просто берет весь UDP-трафик, идущий к AS (автономным системам) Гугла, и отправляет его в Blackhole (Черную дыру). Пакеты молча уничтожаются (Drop).
3. Ваш браузер ждет ответа. Ответа нет. Браузер вздыхает и думает: "Наверное, местный провайдер не поддерживает UDP/QUIC".
4. Происходит Fallback: браузер откатывается к старым стандартам и инициирует классическое TCP-соединение (HTTP/2).
И всё. Капкан захлопнулся. Вы снова в мире TCP. ТСПУ видит ваши прозрачные TCP-заголовки, видит 3-way handshake и готовится читать ваш открытый SNI, чтобы всадить вам RST-пакет или начать шейпить трафик.
Блок 4. Криптография и TLS-рукопожатие: Главная дыра современного интернета
Итак, 3-way handshake завершен. У нас есть открытый TCP-канал. Если мы начнем передавать HTTP-трафик прямо сейчас, он полетит в открытом виде (Plaintext). Любой сисадмин провайдера сможет прочитать ваши куки, токены авторизации и содержимое просматриваемых страниц.
Чтобы этого не произошло, поверх TCP натягивается криптографический протокол TLS (Transport Layer Security).
4.1. Гибридное шифрование: Асимметрия и Симметрия
Проблема криптографии в интернете: как безопасно передать ключ шифрования по незащищенному каналу, который уже прослушивает товарищ майор?
TLS решает это изящно, используя два вида шифрования.
1. Асимметричное шифрование (RSA, ECDSA): Используется только на старте. У сервера есть два ключа - публичный (открытый) и приватный (закрытый). Публичный ключ сервер отправляет всем желающим, им можно только зашифровать данные. А вот расшифровать их можно только приватным ключом, который никогда не покидает сервер. Это математически сложный и очень медленный процесс, шифровать им терабайты видео с ютуба невозможно - процессоры просто расплавятся.
2. Симметричное шифрование (AES-GCM, ChaCha20): Быстрое шифрование одним ключом (и для шифровки, и для расшифровки).
Поэтому TLS делает так: браузер и сервер используют медленное асимметричное шифрование (алгоритмы Диффи-Хеллмана, например ECDHE), чтобы безопасно договориться об общем симметричном ключе (Session Key). Как только ключ сгенерирован, асимметрия отбрасывается, и весь дальнейший трафик шифруется быстрым симметричным алгоритмом.
4.2. TLS Handshake: Роковой пакет ClientHello
Процесс создания защищенного канала называется TLS-рукопожатием. И начинается он с того, что ваш ПК отправляет серверу пакет ClientHello.
В этом пакете клиент говорит: "Привет, я хочу установить защищенное соединение. Вот версии TLS, которые я поддерживаю, и вот список шифров (Cipher Suites), которые я умею использовать".
И именно в этом самом первом пакете кроется фатальная уязвимость.
Проблема виртуального хостинга и дефицита IPv4:
В мире не хватает IP-адресов. Поэтому на одном IP-адресе сервера (например, за CDN Cloudflare) могут физически лежать тысячи разных сайтов: от безобидного форума про котиков до заблокированного рутрекера или инстаграма.
Каждому сайту нужен свой уникальный SSL-сертификат, чтобы браузер убедился, что это не фейк. Но канал еще не зашифрован, ключей нет! Сервер тупо не знает, к какому из тысяч сайтов вы сейчас обращаетесь, и какой сертификат вам отдать для начала асимметричного шифрования.
4.3. SNI (Server Name Indication) - Подарок для цензоров
Чтобы решить эту проблему маршрутизации, в 2003 году придумали расширение SNI.
Его суть проста до безобразия: ваш браузер, отправляя самый первый пакет ClientHello, прямо внутри него пишет доменное имя сайта ОТКРЫТЫМ ТЕКСТОМ.
Выглядит это примерно так:
Extension: server_name (len=15)
Server Name Indication extension
Server Name list length: 13
Server Name Type: host_name (0)
Server Name: googlevideo. com
Код
Код:
Extension: server_name (len=15)
Server Name Indication extension
Server Name list length: 13
Server Name Type: host_name (0)
Server Name: googlevideo. com
Вдумайтесь: у вас может быть настроен мощнейший криптографический профиль, TLS 1.3, идеальная совершенная прямая секретность (PFS). Весь ваш трафик превратится в нечитаемую кашу из случайных байтов. НО! Самый первый пакет, содержащий имя сайта, летит по кабелю абсолютно прозрачным и не зашифрованным.
Как это использует ТСПУ (DPI):
DPI-система провайдера не пытается расшифровать ваш трафик (это математически невозможно без квантовых компьютеров или установки корневого сертификата Минцифры на ваш ПК). Ей это и не нужно.
Она просто работает как продвинутый парсер на L7 уровне модели OSI.
1. DPI видит TCP-соединение на порт 443.
2. Анализирует структуру пакетов в поисках магических байт протокола TLS (`0x16 0x03 0x01`).
3. Находит пакет `ClientHello`.
4. Парсит расширение `Server Name Indication`.
5. Читает `rutracker. org`, `instagram. com` или домены отдачи видео ютуба (`*.googlevideo. com`).
6. Сверяет строку со своим блэклистом. Совпадение найдено.
Как только сигнатура спалена, в дело вступают алгоритмы блокировки (L4 инъекции), о которых мы говорили ранее: ТСПУ отправляет фейковый пакет с флагом `RST` (сброс) или начинает агрессивно выкидывать ваши TCP-сегменты, ломая алгоритм контроля перегрузки. Ваше соединение мертво, даже не успев стать защищенным.
Блок 5. Архитектура цензуры: ТСПУ, DPI и топология сетей
Мы разобрали протоколы и нашли уязвимость (открытый SNI). Но как государству прочитать этот SNI у миллионов пользователей одновременно? Для этого потребовалось физически изменить топологию интернета внутри страны.
5.1. Что такое ТСПУ (Технические средства противодействия угрозам)
До 2019 года цензура в РФ была децентрализованной. Роскомнадзор присылал провайдерам (Ростелеком, МТС, Дом.ру и тысячам мелких) списки запрещенных IP и доменов (Реестр), а провайдеры сами решали, как их блокировать. Кто-то ставил дешевые фильтры, кто-то блокировал по IP, из-за чего страдали соседние сайты (вспомните ковровые блокировки Telegram).
Потом был принят закон о "Суверенном интернете", и правила игры изменились. Государство за свой счет установило на узлах связи всех провайдеров ТСПУ.
ТСПУ - это программно-аппаратный комплекс (чаще всего серверы с софтом от EcoNAT или RDP. ru).
Главная фишка: провайдер не имеет к ним доступа. Это буквально "черный ящик" в стойке провайдера, которым напрямую управляет ГРЧЦ (Главный радиочастотный центр) из Москвы. Провайдер даже не знает, что именно в данный момент блокирует или замедляет ТСПУ.
5.2. DPI (Deep Packet Inspection) как движок
Внутри ТСПУ крутится система DPI - глубокий анализ пакетов.
Обычный файрвол (брандмауэр) работает на уровнях L3-L4. Он смотрит на IP-адрес и порт: "Ага, трафик идет на IP 1.1.1.1, порт 80 - разрешить". Ему плевать, что внутри.
DPI работает иначе. Он собирает фрагментированные пакеты, восстанавливает TCP-сессии в оперативной памяти и лезет на уровень L7 (Прикладной). Он парсит HTTP-заголовки, читает TLS ClientHello в поисках SNI, анализирует поведенческие паттерны трафика (эвристика), чтобы выявить протоколы VPN (WireGuard, OpenVPN), даже если они работают на нестандартных портах.
5.3. Схемы установки DPI: Пассивный vs Активный
То, как именно ТСПУ интегрирован в сеть провайдера, определяет его возможности и наши способы обхода. Есть две фундаментальные схемы подключения.
1. Пассивный DPI (Out-of-Band / SPAN)
Анализатор подключается параллельно основному каналу связи. С помощью оптического сплиттера или SPAN-порта на коммутаторе ТСПУ получает копию всего проходящего трафика.
Особенности:
• Ваш оригинальный трафик летит к серверу без задержек.
• Пассивный DPI не может физически удалить или замедлить ваш пакет (он ведь работает с копией).
• Как он блокирует? Только инъекциями! Увидев в копии трафика запрещенный SNI, пассивный DPI судорожно генерирует фейковые TCP RST пакеты (Блок 2) и шлет их вам наперерез, пытаясь "догнать" и убить сессию.
• Слабость: Если сервер ответит быстрее, чем прилетит RST от цензора, блокировка не сработает.
2. Активный DPI (Inline)
ТСПУ ставится "в разрыв" магистрального кабеля (как L2-bridge или маршрутизатор). Весь трафик физически проходит сквозь него.
Особенности:
• Это самая жесткая схема (именно она сейчас применяется почти везде в РФ).
• Активный DPI имеет власть над каждым битом. Он может не просто кидаться RST-пакетами. Он может молча уничтожать пакеты (Blackhole / Drop).
• Именно Inline-установка позволяет осуществлять Шейпинг (замедление) ютуба, искусственно задерживая пакеты в буфере (создавая джиттер) или выкидывая часть сегментов, чтобы заставить алгоритмы контроля перегрузок снизить битрейт.
• Слабость: Через Inline-DPI проходят терабиты трафика (Tbps). Это колоссальная нагрузка на CPU и RAM процессоров ТСПУ. Оборудование вынуждено балансировать: если проверять каждый пакет слишком тщательно, интернет в городе просто встанет. Именно эту нехватку ресурсов (Timeout состояний, лимиты памяти на рессемблинг) мы и эксплуатируем программами обхода.
Блок 6. Механика удушения: Стейт-машины, Рессемблинг и алгоритм Token Bucket
ТСПУ пропускает через себя терабиты данных в секунду. Чтобы найти в этом океане мусора один запрещенный SNI, DPI-системе приходится работать на пределе вычислительных возможностей.
6.1. Stateful Inspection (Отслеживание состояний)
DPI не может анализировать каждый пакет изолированно (как это делают тупые L3-файрволы). Чтобы поймать `ClientHello` с доменом ютуба, DPI обязан следить за контекстом. Он работает как Stateful-анализатор (система с памятью).
Когда вы начинаете 3-way handshake (Блок 2), DPI видит пакет `SYN`. Он тут же выделяет кусок своей оперативной памяти и создает запись в таблице состояний:
"IP 192.168.1.5 открывает сессию с IP 142.250.72.110 на порт 443. Состояние: SYN_RCVD".
Дальше он ждет `ACK` и переводит сессию в состояние `ESTABLISHED`. И только теперь DPI активирует свои регулярные выражения (regex), чтобы искать SNI в полезной нагрузке.
Почему это наша главная лазейка?
Потому что оперативная память не бесконечна! У ТСПУ могут быть миллионы одновременных сессий. Если сессия зависает или ведет себя нестандартно, DPI вынужден держать ее в памяти до наступления таймаута, либо сбрасывать. Программы обхода (спойлер к Блоку 9) специально шлют мусорные пакеты с кривыми флагами (например, `SYN+ACK` без предварительного `SYN`), чтобы запутать стейт-машину ТСПУ и заставить ее "забыть" или проигнорировать наше реальное соединение.
6.2. Рессемблинг (Сборка пазла)
Допустим, `ClientHello` разбился на три мелких TCP-сегмента (фрагментация). В первом пакете летит `you`, во втором `tube`, в третьем `. com`.
DPI не может проверить их по отдельности - сигнатура не совпадет. Поэтому DPI использует Reassembly (Рессемблинг): он задерживает первые два пакета в своем буфере, ждет третий, склеивает их в оперативной памяти, читает целиком `youtube. com`, понимает, что это запрещенка, и только потом наносит удар.
Склейка пакетов жрет колоссальное количество ресурсов процессора ТСПУ. Если мы разобьем `ClientHello` на 10 крошечных кусков по 1 байту, процессор ТСПУ может просто сказать: "Да ну нахрен, у меня нет времени это клеить, там еще миллион пакетов ждут очереди" - и пропустит их без проверки. На этом принципе работает обход через фрагментацию (Window Size trick).
6.3. Шейпинг трафика: Алгоритм Token Bucket
С полными блокировками всё ясно: нашел SNI -> кинул фейковый `RST` -> убил сессию. Но как работает замедление (шейпинг), когда ютуб вроде грузится, но со скоростью 128 кбит/с?
ТСПУ не может просто сказать вашему ПК "качай медленнее". Вместо этого он использует математический алгоритм ограничения полосы пропускания - Token Bucket (Маркерная корзина).
Представьте себе виртуальное ведро.
1. Каждую миллисекунду система кладет в ведро токены (монетки). Скорость пополнения ведра строго фиксирована (например, 128 кбит/с - это лимит, установленный РКН).
2. Прилетает ваш пакет с видео от серверов Google (размером 1500 байт).
3. Чтобы ТСПУ пропустил этот пакет дальше к вам, он должен достать из ведра 1500 токенов и "заплатить" ими.
4. Если вы смотрите видео в 4K, пакеты летят с огромной скоростью (20 Мбит/с). Ведро пустеет мгновенно!
5. Что делает ТСПУ, когда прилетает следующий пакет, а токенов в ведре больше нет? У него два пути:
• Drop (Выкинуть): Пакет уничтожается. Ваш TCP CUBIC видит потерю и в панике режет скорость в 2 раза (о чем мы говорили в Блоке 3).
• Delay (Задержать): Положить пакет в буферную очередь и ждать, пока в ведро накапают новые токены. Задержка (ping) вырастает до небес. Умный гугловский TCP BBR видит, что RTT (задержка) стала катастрофической, и сам сбрасывает битрейт видео, подстраиваясь под "ширину ведра".
Вот так, изящно и математически безжалостно, ТСПУ заставляет даже самые передовые протоколы Google сдаться и выдавать вам "мыльное" качество.
Блок 7. Практический кейс: Хронология удушения YouTube
Давайте сведем все наши знания (L3/L4 уровни, TCP/UDP, QUIC, SNI, Downgrade и Token Bucket) в единую посекундную хронологию. Что именно происходит физически на магистралях провайдера прямо сейчас, когда вы открываете видео на ютубе без средств обхода?
Этап 1: Засада на QUIC и Downgrade-атака
Вы кликаете на превью ролика. Ваш браузер (Chrome) знает, что сервера Google (в том числе кэширующие сервера GGC - Google Global Cache) поддерживают современный и быстрый протокол QUIC.
Браузер формирует зашифрованную UDP-датаграмму на порт 443 и отправляет ее провайдеру.
Но на узле связи провайдера стоит ТСПУ (Inline DPI). У него есть жесткое правило от РКН: "Весь UDP-трафик, идущий к пулам IP-адресов Google, отправлять в /dev/null".
ТСПУ молча уничтожает ваш UDP-пакет (Blackhole).
Ваш браузер ждет пару сотен миллисекунд, понимает, что ответа нет, и совершает Fallback (откат). Он говорит: "Окей, UDP заблокирован, придется использовать старый медленный TCP".
Первая победа ТСПУ: вас успешно загнали в контролируемую среду.
Этап 2: Бюрократия и Stateful-трекинг
Браузер инициирует TCP-соединение (3-way handshake).
Летит пакет SYN. ТСПУ видит его, выделяет оперативную память и записывает в свою стейт-таблицу: "Новая сессия, жду продолжения".
Сервер Google отвечает SYN-ACK. Вы отвечаете ACK.
Соединение переходит в статус ESTABLISHED. Канал открыт, но ТСПУ пока не знает, что именно вы там собираетесь качать - ютуб или гугл-доки. Он переводит свой парсер в режим ожидания L7-данных.
Этап 3: Фатальный ClientHello
Начинается TLS-рукопожатие для установки HTTPS. Ваш ПК отправляет тот самый роковой пакет ClientHello.
Внутри пакета, в расширении SNI, открытым текстом сияет домен кэш-сервера отдачи видео (например, rr1---sn-n8v7znes.googlevideo. com).
DPI-движок ТСПУ мгновенно парсит этот пакет. Регулярное выражение (regex) ловит совпадение по маске `*.googlevideo. com`.
Система кричит: "Тревога! Зафиксировано обращение к запрещенному ресурсу видеохостинга!".
ТСПУ мгновенно вешает на вашу TCP-сессию внутренний маркер (Tag), привязывая к ней определенный класс обслуживания (QoS) - "Жесткое замедление".
Этап 4: Экзекуция (Token Bucket в действии)
Видео начинает грузиться. Гугловский алгоритм TCP BBR со стороны сервера радостно разгоняет окно передачи (Window Size) и начинает пушить в вас мегабайты видеоданных с огромной скоростью.
Но на пути этих данных стоит ТСПУ с активированным алгоритмом Token Bucket (Маркерная корзина). Лимит ведра установлен, скажем, на 128 Кбит/с.
Первые несколько пакетов пролетают нормально (токены в ведре еще есть). Но через долю секунды токены заканчиваются.
ТСПУ начинает безжалостно задерживать (Delay) или выкидывать (Drop) ваши пакеты с видео.
Что происходит в этот момент под капотом:
1. Пакеты застревают в буферах маршрутизаторов. Возникает Bufferbloat (буферизация). Ваш пинг до гугла улетает в космос (с 20 мс до 5000 мс).
2. Гугловский сервер видит, что пакеты до вас не доходят (ACK-квитанции не возвращаются вовремя).
3. Алгоритм BBR понимает: канал мертв. Он снижает скорость отдачи.
4. Плеер YouTube в вашем браузере видит, что буфер опустел. Он судорожно переключает качество с 1080p на 480p, потом на 144p, пытаясь уложиться в ту мизерную пропускную способность, которую ему оставил ТСПУ.
5. Если и это не помогает (ТСПУ может выкидывать пакеты слишком агрессивно), соединение рвется по таймауту. На экране крутится бесконечное колесо загрузки.
Именно так, технически элегантно и математически жестоко, вас лишают возможности смотреть видео в высоком качестве. Государство не блокирует IP-адреса гугла (иначе лягут Android-смартфоны). Оно точечно находит видео-трафик по открытому SNI и душит его на транспортном уровне.
Блок 8. Теория обхода DPI: Десинхронизация и почему классический VPN умирает
Долгие годы рецепт свободы в интернете был прост: купил сервер за 5 баксов, накатил OpenVPN или WireGuard, завернул весь трафик в зашифрованный туннель и сидишь довольный. ТСПУ видит лишь поток нечитаемых байтов до какого-то IP-адреса в Нидерландах.
Но в 2024 году этот праздник закончился. Почему? Потому что DPI поумнел.
8.1. Эвристика и Фингерпринтинг (Смерть WireGuard)
ТСПУ больше не нужно расшифровывать ваш VPN, чтобы понять, что это VPN. Он использует Фингерпринтинг (Снятие отпечатков) и эвристический анализ.
У каждого протокола есть свой уникальный паттерн поведения (размеры пакетов, тайминги, структура рукопожатия):
• OpenVPN: Имеет очень характерные размеры пакетов при установке сессии и специфические заголовки.
• WireGuard: Хотя он работает по UDP и выглядит как белый шум, его первый пакет рукопожатия (Handshake Initiation) всегда имеет размер ровно 148 байт. Следующий ответ (Handshake Response) - ровно 92 байта.
DPI-движок ТСПУ просто видит: "Ага, полетел UDP-пакет на 148 байт, а в ответ прилетел на 92 байта... Это WireGuard! Блокирую!". И ваш туннель отваливается.
Прятать трафик в туннель становится всё сложнее (приходится использовать Shadowsocks, VLESS, XTLS-Reality, которые маскируются под обычный HTTPS). Но у всех VPN есть минусы: они режут скорость, повышают пинг и требуют денег на сервера.
Что если мы не будем прятать трафик, а просто заставим DPI проигнорировать его?
8.2. Концепция Десинхронизации (DPI Evasion)
Здесь на сцену выходит Десинхронизация. Это класс атак на системы глубокого анализа трафика.
Суть метода: создать ситуацию, когда ТСПУ "видит" одну картину сетевого соединения, а конечный сервер (YouTube) - совершенно другую.
Мы помним из Блока 6, что DPI - это Stateful-система. Она отслеживает состояние TCP-соединения (флаги SYN/ACK, номера SEQ/ACK).
Но DPI стоит посередине (Middlebox). Это означает, что он лишь пытается угадать, как эти пакеты обработает конечный сервер. И в этой "угадайке" кроется фундаментальная уязвимость оборудования за миллиарды рублей.
8.3. Фундаментальная уязвимость ТСПУ
Оборудование ТСПУ (EcoNAT/RDP) написано программистами. Оно работает на базе собственного, сильно урезанного (для скорости) TCP-стека.
А серверы Google работают на полноценном TCP-стеке ядра Linux.
Эти два стека (ТСПУ и Linux) по-разному реагируют на сетевые аномалии (нарушения стандартов RFC).
Вот несколько примеров того, как мы можем свести ТСПУ с ума:
1. Битые контрольные суммы (Bad Checksum):
Что если мы отправим пакет с фейковым SNI, но специально испортим в нем контрольную сумму (сделаем его битым)?
Некоторые DPI настолько спешат, что не проверяют чексумму ради экономии ресурсов процессора. DPI прочитает фейковый SNI, поверит в него и обновит свой стейт. А когда этот пакет долетит до серверов Google, ядро Linux увидит битую чексумму и выкинет пакет в мусорку на уровне железа сетевой карты. Сервер даже не узнает о нем!
2. Игра с номерами последовательности (SEQ/ACK Overlap):
Мы можем отправить два пакета с одинаковыми номерами SEQ (наложение данных).
В первом пакете написано: "Я иду на gosuslugi. ru".
Во втором пакете (с тем же номером): "Я иду на googlevideo. com".
Какой из них перезапишет другой? DPI может посчитать, что валиден первый пакет (поверив в гoсycлyги), а Linux-сервер Гугла по своим внутренним правилам примет второй пакет (и выдаст видео).
3. Лимиты памяти (Ослепление цензора):
Память ТСПУ не резиновая. Если мы отправим `ClientHello`, но разобьем его на 100 крошечных кусочков (по 1 байту), да еще и отправим их в обратном порядке (сначала конец слова, потом начало), DPI придется держать всё это в оперативной памяти и пытаться собрать пазл. Мы можем специально отправить кучу мусорных фрагментов, чтобы переполнить буфер рессемблинга конкретной сессии. DPI скажет: "Да пошел ты, у меня нет на это времени" - и просто пропустит трафик без проверки.
Итог:
Методы десинхронизации (на которых работают GoodbyeDPI, Zapret, SpoofDPI) - это не взлом РКН. Это использование багов и архитектурных компромиссов самого оборудования ТСПУ. Мы шлем математически выверенный мусор, который ослепляет цензора, но игнорируется конечным сервером.
Блок 9. Анатомия магии: Как программно работают GoodbyeDPI и Zapret
Вся теория из восьмого блока звучит круто, но как это реализовано в коде? В этом блоке мы разберем конкретные флаги и параметры запуска самых популярных утилит обхода - GoodbyeDPI (от ValdikSS) под Windows и Zapret (от bol-van) под Linux/роутеры.
Мы посмотрим, как именно они модифицируют ваши пакеты на лету, работая на уровне сетевого драйвера (WinDivert или NFQUEUE).
9.1. Метод 1: Фрагментация на уровне TCP (Аргумент -f)
Это базовый метод, с которого всё начиналось. Его задача - не дать ТСПУ прочитать SNI целиком, разорвав слово googlevideo. com на два разных TCP-сегмента.
В GoodbyeDPI за это отвечает параметр -f (или --frag-by-sni).
Как это работает технически:
Когда браузер формирует пакет ClientHello (допустим, размером 512 байт), GoodbyeDPI перехватывает его до отправки в сетевую карту.
Программа находит смещение (offset), где начинается SNI, и искусственно разрезает этот пакет на два независимых IP-пакета.
В первом пакете улетает половина ClientHello, во втором - остаток.
А как же Window Size? (Аргумент -w)
Чтобы усилить эффект, используется параметр -w (или --set-window-size). Утилита подменяет TCP-заголовок в пакете рукопожатия (SYN), указывая серверу и ТСПУ крошечный размер окна. DPI-система, видя такое маленькое окно, часто просто отключает для этой сессии рессемблинг (склейку), так как алгоритмы ТСПУ считают, что анализировать поток со столь мелким окном слишком дорого для CPU. И фрагментированный SNI пролетает незамеченным.
9.2. Метод 2: Изящный обман (Аргумент -e и Wrong Sequence)
Иногда ТСПУ умеет склеивать обычные фрагменты. Тогда в дело вступает "неправильная" сборка.
В Zapret есть мощный механизм disorder. В GoodbyeDPI похожий трюк вызывается параметром -e (или --wrong-seq).
Как это работает:
Программа режет ClientHello на две части. Но отправляет их в обратном порядке!
1. Сначала улетает вторая половина слова (например, tube. com) с номером последовательности (SEQ) = 100.
2. Потом улетает первая половина (например, you) с номером SEQ = 1.
Реакция ТСПУ: Его примитивный TCP-стек получает пакет SEQ=100. ТСПУ понимает, что пропустил начало (дыра в данных). Многие DPI-системы в этот момент просто сбрасывают буфер слежения за сессией, чтобы не тратить оперативную память на "битый" коннект.
Реакция серверов Google: Полноценное ядро Linux на сервере Гугла спокойно помещает пакет SEQ=100 в буфер ожидания (Out-of-Order Queue), дожидается пакета SEQ=1, склеивает их в правильном порядке и выдает вам видео.
9.3. Метод 3: Оружие Судного Дня - Fake Packets и TTL Trick
Когда Роскомнадзор начал блокировать ютуб жестко (Inline DPI с дpопом пакетов), фрагментация перестала помогать. ТСПУ научили собирать фрагменты.
Тогда Валдик (автор GoodbyeDPI) активировал пресеты -5, -7, -9, которые включают отправку фейковых пакетов и магию с TTL (Time To Live).
Мы уже затрагивали этот механизм, но давайте разберем его побитово.
1. Вы запрашиваете ютуб. Софт перехватывает ваш ClientHello.
2. Утилита генерирует абсолютно новый, фейковый пакет. Внутри него - валидный ClientHello, но в поле SNI прописан russia. ru или vk. com.
3. Этому фейку прописывается поддельный номер SEQ (точно такой же, как у вашего настоящего пакета).
4. Главная магия: утилита меняет заголовок L3 (IP-пакет), выставляя поле TTL = 3 (аргумент `--set-ttl`).
5. Фейковый пакет улетает к провайдеру. Ваш настоящий пакет ставится на паузу на несколько миллисекунд.
Что происходит на магистрали:
ТСПУ обычно стоит на 2-м или 3-м хопе (маршрутизаторе) от вас. До серверов Google в Европе - 10-15 хопов.
Фейк (с TTL=3) долетает до ТСПУ. Значение TTL уменьшается до 2.
ТСПУ вскрывает пакет. Видит SNI vk. com. Его стейт-машина делает запись: "Эта TCP-сессия чистая, тут смотрят ВК. Проверку отключаю".
Фейк летит дальше. На следующем роутере его TTL падает до 0. Роутер по стандарту RFC убивает пакет и кидает его в корзину. До Google этот мусор не доходит!
Добивание:
Через миллисекунду ваш ПК отправляет настоящий ClientHello с ютубом и нормальным TTL (например, 128).
Этот пакет проходит через ТСПУ. Но ТСПУ его уже игнорирует! Ведь для этой сессии цензор уже обновил статус на "разрешено" из-за предыдущего фейка.
Именно поэтому GoodbyeDPI и Zapret требуют тонкой настройки. Если вы поставите `--set-ttl 1`, фейк умрет на вашем домашнем роутере и не долетит до ТСПУ. Если поставите `--set-ttl 20`, фейк долетит до серверов Google, Гугл увидит пакет с кривым SNI (vk. com) и сам сбросит ваше соединение с ошибкой SSL_ERROR.
Найти идеальный TTL (обычно от 3 до 7) - ключ к успешному обходу!
Блок 10. Будущее интернета: Гонка вооружений, ECH и угроза "Белых списков"
Всё, что мы обсуждали в предыдущих 9 блоках (десинхронизация, фрагментация, подмена TTL), - это костыли. Это игра в кошки-мышки с DPI, где мы эксплуатируем несовершенство парсеров ТСПУ.
Но глобальное IT-сообщество (Google, Cloudflare, Mozilla) решило убить саму причину болезни - тот самый открытый SNI, о котором мы говорили в Блоке 4.
10.1. ECH (Encrypted ClientHello) - Смерть классического DPI
Если SNI - это открытая открытка, которую может прочитать любой провайдер, то ECH кладет эту открытку в бронированный сейф.
Как это работает технически:
1. Прежде чем подключиться к заблокированному сайту (например, rutracker. org на серверах Cloudflare), ваш браузер делает хитрый DNS-запрос и получает публичный ключ шифрования этого CDN-провайдера.
2. Браузер берет пакет `ClientHello` (где лежит настоящий SNI rutracker. org) и зашифровывает его этим ключом. Это называется Inner ClientHello (внутренний пакет).
3. Затем браузер создает Outer ClientHello (внешний фейковый пакет), в котором открытым текстом пишет: "Я иду на публичный IP-адрес Cloudflare, мой SNI - cloudflare. com", и прячет внутрь него зашифрованный Inner-пакет.
Что видит ТСПУ?
Он видит абсолютно легитимное TLS-рукопожатие с `cloudflare. com` или `google. com`. Внутри летит какая-то зашифрованная каша. ТСПУ пропускает трафик.
А когда этот пакет долетает до серверов Cloudflare, они своим приватным ключом расшифровывают внутренний пакет, видят там rutracker и отдают вам нужный сайт.
Цензор абсолютно слеп. DPI превращается в бесполезную железку.
10.2. Шифрование DNS (DoH и DoT)
Но ECH бессмысленен, если вы используете стандартный DNS от вашего провайдера (порт 53, UDP). Потому что прежде чем пойти на сайт, ваш ПК спрашивает у провайдера открытым текстом: "Какой IP-адрес у instagram. com?". ТСПУ перехватывает этот запрос и либо блокирует его, либо подменяет ответ (DNS Hijacking).
Поэтому стандарт будущего - это DNS over HTTPS (DoH) или DNS over TLS (DoT).
Ваши DNS-запросы заворачиваются в такой же зашифрованный HTTPS-трафик, как и обычные сайты. Провайдер больше не знает, IP-адреса каких доменов вы пытаетесь узнать.
10.3. Ответный удар: Ковровые бомбардировки и "Белые списки"
И вот тут начинается самое страшное.
Когда повсеместно внедрят ECH и DoH, ТСПУ потеряет возможность точечно блокировать сайты по доменным именам (SNI). Цензор будет видеть только то, что вы подключаетесь к гигантским CDN-сетям (Cloudflare, Fastly, Google).
Как государству заблокировать один сайт, если оно не видит, куда именно вы идете внутри Cloudflare?
Ответ: Блокировать по IP-адресам. Целыми подсетями.
Именно это мы наблюдали в конце 2024 года, когда РКН пытался блокировать Cloudflare, ломая половину рунета, форумы, магазины и сервисы, которые вообще не имели отношения к политике или пиратству. Ковровые бомбардировки - это акт отчаяния слепого цензора.
И финальной стадией этой гонки, если DPI окончательно проиграет криптографии, станет переход интернета на модель Default Deny (Белые списки).
Это ситуация (как в КНДР или Китае), когда заблокировано всё по умолчанию, кроме того, что явно разрешено (гoсycлyги, ВК, Яндекс, Сбер).
К счастью, реализовать Белые списки в масштабах экономики РФ сейчас практически невозможно без тотального коллапса банковской сферы, логистики и бизнеса. Поэтому битва брони и снаряда (DPI против криптографии) будет продолжаться еще очень долго.
Мы проделали огромный путь от битов и кадров L2-уровня до алгоритмов BBR, маркерных ведер ТСПУ, инъекций TCP RST и десинхронизации стейт-машин.
Интернет изначально строился как децентрализованная и отказоустойчивая сеть (ARPANET), способная пережить ядерный удар. Как выяснилось, она способна пережить и попытки государственного регулирования, находя лазейки в самом ядре сетевых протоколов. Каждое действие цензуры рождает еще более изощренное противодействие.
Огромное спасибо всем, кто прочитал статью полностью. Надеюсь, теперь работа сети, блокировок и утилит вроде GoodbyeDPI стала для вас кристально понятной, и вы больше не верите в сказки про "износ оборудования Google"(Хотя я не уверен то что кто то в них верил...)
целую в носик
Комментарии 0