Skip to content

Zapret 2 и интернет — при чём тут обход блокировок Диск… — Transcript

Технический разбор работы интернета и механизмов обхода блокировок Zapret 2 с объяснением ключевых сетевых терминов и принципов.

Key Takeaways

  • Zapret — это инженерная система блокировок, основанная на анализе разных признаков трафика.
  • Разные сервисы используют разные протоколы и порты, поэтому блокировки работают по-разному.
  • Понимание базовых сетевых терминов критично для работы с обходом блокировок.
  • Методы обхода zapret направлены на обман DPI, чтобы скрыть реальный трафик от фильтров.
  • Термины zapret имеют специфический смысл, который отличается от общепринятого в сетях.

Summary

  • Видео объясняет, как устроен интернет на базовом уровне — от домена и DNS до протоколов TCP, UDP, HTTP, TLS и QUIC.
  • Разбирается, почему разные сервисы блокируются по-разному из-за разных протоколов, портов и признаков трафика.
  • Объясняется роль DPI и ТСПУ — технологий глубокого анализа трафика, используемых для блокировок.
  • Вводятся три группы терминов: общие сетевые, специфичные для zapret и пограничные, которые имеют двойной смысл.
  • Дается обзор основных понятий zapret: пресет, стратегия, hostlist и методы обхода блокировок (fake, split, disorder, fooling).
  • Поясняется, что zapret не изобретает интернет заново, а работает в его существующей инфраструктуре.
  • Подчеркивается важность понимания базовых сетевых понятий для правильного чтения и настройки пресетов zapret.
  • Видео служит технической базой для дальнейшего изучения механизмов zapret2 и обхода блокировок.
  • Автор предупреждает о сложности терминологии и необходимости терпения при изучении материала.
  • Дается карта терминов и концепций, чтобы облегчить понимание и навигацию по теме.

Chapters

  1. 00:00Введение и цели видео
  2. 11:08Терминология и группы слов
  3. 19:15Общие сетевые термины: IP, порт, DNS, пакеты
  4. 28:28Протоколы TCP и UDP, HTTP, TLS, QUIC
  5. 38:12Термины zapret: пресеты, стратегии, hostlist и методы обхода
  6. 45:32Пограничные термины и их особенности в zapret2
  7. 56:12Глубокий анализ трафика и роль DPI
  8. 63:32Заключение и подготовка к следующей части

Full Transcript — Download SRT & Markdown

00:00
Speaker A
Я очень долго думала, что же рассказать во второй части нулевого видео, так чтобы не перезагрузить его лишней информацией. Этот подход будет слегка нестандартный.
00:10
Speaker A
Привычные TCP и UDP вы здесь не услышите. По крайней мере пока что. Возможно, потому что об этом и так слишком много информации. Например, есть вот эти отличные два канала, которые я рекомендую посмотреть прежде чем продолжать изучать наш курс.
00:26
Speaker A
Проблема таких видео в том, что хочется больше рассказать именно про ограничения, но в то же время, если человек не понимает основы сети, его легче запутать, чем дать что-то понять.
00:58
Speaker A
С другой стороны, можно рассказать это так, что это отобьёт его желание ещё сильнее — и он просто испугается. Поэтому сегодня мы остановимся на ещё одном общем обзоре того, как устроен интернет с несколькими маленькими темами. Но разберём их очень досконально.
01:15
Speaker A
Что не относится к обходу блокировок, мы бережно упустим, чтобы не перегружать тебя информацией. Это вторая часть нулевого видео, и она целиком техническая. В первой части мы договорились о главном: zapret — это не «двенадцать альтов и один txt», а понятная инженерная система. И когда один
01:34
Speaker A
готовый альт открывает YouTube, но не Discord — это не везение и не порча, у этого есть причина: у разных сервисов разные протоколы, разные порты, разные признаки, за которые цепляется блокировка.
01:47
Speaker A
Собственно, вся первая часть была картиной «зачем». Теперь будет картина «как» — и она потребует немного терпения, потому что придётся спуститься на уровень ниже, туда, где живут байты.
01:59
Speaker A
В этой части мы соберём сетевую базу, без которой любой пресет выглядит как набор магических символов. Сейчас, скорее всего, строка пресета для вас — именно заклинание: набор дефисов и непонятных слов, которые почему-то работают. К концу ролика та же строка должна
02:16
Speaker A
читаться как обычное техническое предложение: для такого-то трафика, на таком-то протоколе, для таких-то сайтов — применить такой-то приём. Чтобы этого добиться, мы спокойно, слой за слоем, пройдём весь путь, который браузер пролетает за долю секунды между
02:40
Speaker A
нажатием Enter и открытой страницей. Что такое домен, DNS, IP и порт — то есть как устройство вообще понимает, куда стучаться. Почему данные идут не одним куском, а пакетами, и как своими глазами прочитать их байты. Чем TCP отличается от UDP. Что такое HTTP,
03:01
Speaker A
HTTPS, TLS и QUIC — и где в них, несмотря на всё шифрование, наружу торчит имя сайта.
03:19
Speaker A
А затем подойдём к главному для нашей темы: что такое DPI и ТСПУ — та техника, которой провайдер и Роскомнадзор анализируют и фильтруют трафик, — на каких уровнях вообще бывают блокировки, можно ли заблокировать сам zapret и где во всей этой цепочке он находится.
03:34
Speaker A
Ничего из этого не нужно заучивать наизусть — это не экзамен. Считайте это картой, по которой потом будет удобно читать любые термины zapret: встретили незнакомое слово — вернулись, посмотрели, на каком оно участке, пошли дальше.
05:34
Speaker A
Начнём с самих слов — точнее, с того, как в них не запутаться. Дело в том, что термины, которые нас ждут, относятся к разным группам, и эту разницу важно проговорить заранее — до того, как слова посыплются на вас десятками. Если смешать их
05:52
Speaker A
в одну кучу, новичок очень быстро потеряется, и потеряется не потому, что глупый, а потому, что рядом окажутся слова из разных миров: часть относится к интернету вообще и написана в любом учебнике по сетям, часть придумана внутри zapret и больше нигде не существует, а часть — самая
06:10
Speaker A
коварная — вроде бы общая, но в zapret получает свой, более конкретный прикладной смысл. Внешне все эти слова выглядят одинаково: латиница, короткие, стоят в пресете через дефис. А ведут себя по-разному. Собственно, вся эта часть про то, как научиться различать их с первого взгляда.
06:30
Speaker A
Первая группа — термины общего интернета. Это IP, порт, TCP, UDP, DNS, пакет, HTTP, TLS и QUIC. Сразу главное: это не термины zapret. Они существуют сами по себе и появились задолго до него — TCP расписан в документах ещё семидесятых годов,
06:49
Speaker A
DNS работает с восьмидесятых, и всё это гоняло пакеты по сети задолго до того, как вы впервые услышали слово zapret. Прямо сейчас, пока вы смотрите это видео, те же самые TCP, DNS и пакеты доставляют его вам — безо всякого zapret. Он просто действует в этой среде, как
07:04
Speaker A
рыба в воде, а не изобретает интернет заново. Это, кстати, полезная мысль и с практической стороны: всё, что вы узнаете про эту группу слов, останется с вами навсегда — пригодится и в настройке роутера, и в программировании, и просто чтобы понимать, почему «интернет тормозит».
07:21
Speaker A
Каждому из этих слов ниже посвящён свой раздел, поэтому сейчас пройдёмся по ним одной строкой — просто чтобы они были на слуху, как имена героев в начале книги. IP — это адрес устройства в сети. Порт — номер конкретной службы на этом адресе, как отдельная дверь в большом
07:41
Speaker A
здании. DNS — справочник, который превращает имя сайта в IP-адрес. Пакет — небольшая порция данных, на которые режется весь сетевой обмен, — и вокруг этого слова дальше закрутится почти всё. TCP и UDP — два способа доставки этих пакетов: TCP надёжный, с подтверждениями и порядком,
07:56
Speaker A
а UDP простой и быстрый, без гарантий. HTTP — язык веба, на котором браузер просит страницу, а сервер отвечает. TLS — шифрующая обёртка, которая и превращает HTTP в защищённый HTTPS.
08:15
Speaker A
А QUIC — современный транспорт поверх UDP, на котором работает HTTP/3. Если сейчас половина этих определений пролетела мимо — это нормально и даже ожидаемо: ничего из этого пока не нужно держать в голове целиком, всё это мы медленно, с картинками и примерами, разберём в следующих разделах.
08:33
Speaker A
Вторая группа — термины самого zapret. Это пресет, стратегия, hostlist, fake, split, disorder и fooling. Вот эти слова вы уже не найдёте ни в одном учебнике по сетям — они описывают не интернет вообще, а то, как именно zapret должен воздействовать на выбранный трафик.
08:43
Speaker A
Грубо говоря, первая группа — это язык, на котором говорит сеть, а вторая — команды, которые мы отдаём поверх этого языка. Пройдёмся и по ним коротко, чтобы дальше они не пугали.
09:01
Speaker A
Первые три задают рамку — они отвечают на вопросы «что», «как» и «к чему» применять. Пресет — не общий термин интернета, а обычный текстовый файл с параметрами zapret; по сути сохранённая настройка, которую удобно хранить, переключать и пересылать друг другу — когда вам кидают «рабочий конфиг»,
09:24
Speaker A
кидают именно его. Стратегия — не «жизненный план» и не «попробуем что-нибудь», а конкретный сценарий воздействия на DPI (Deep Packet Inspection — система, которой провайдер заглядывает внутрь трафика; подробно разберём её в отдельном разделе). Hostlist — список хостов,
09:31
Speaker A
то есть сайтов, к которым мы хотим применить правило: не ко всему трафику подряд, а прицельно.
09:50
Speaker A
Остальные четыре — это уже названия самих приёмов обхода, боевой арсенал, и вот они одной строкой.
10:07
Speaker A
Fake — отправить поддельный пакет, чтобы сбить DPI с толку. Split — разрезать сообщение на части так, чтобы имя сайта оказалось на стыке кусков и не читалось целиком. Disorder — намеренно перепутать порядок отправки частей. Fooling — общее название для приёмов, которые «обманывают» анализатор,
10:14
Speaker A
портя ровно то, что проверяет только он, а настоящий сервер не смущает. Заметьте общую логику: все четыре — про одно и то же, про то, чтобы DPI увидел одну картину, а настоящий сервер — другую. Заучивать их сейчас не нужно: каждый подробно разберём в следующем видео, про
10:30
Speaker A
механизм zapret2. Пока достаточно понимать, что все они из мира zapret, а не из общего интернета.
10:51
Speaker A
Третья группа — пограничные слова. И вот они самые коварные. С первыми двумя группами хотя бы честно: одни слова из учебника, другие из zapret, перепутать сложно. А пограничные слова играют на обе стороны: они действительно существуют в обычных сетях, в программировании или в
11:08
Speaker A
сетевых анализаторах — но в zapret2 получают более конкретный прикладной смысл. Получается ловушка именно для того, кто уже что-то знает: новичок с нуля просто пойдёт смотреть значение, а человек с сетевым бэкграундом уверенно подставит привычный смысл — и прочитает пресет неправильно, даже не замет...
11:24
Speaker A
в смысле конкретной сущности zapret2? Сам вопрос важнее ответа — кто спросил, тот уже не попался.
11:30
Speaker A
А чтобы вы узнавали эти слова при встрече, ниже разберём каждое по отдельности — сначала его обычный смысл, иногда даже за пределами сетей, а потом то, чем оно становится в zapret2.
11:41
Speaker A
Эти же три группы вы видите на схеме — тремя колонками, каждая своего цвета: слева синяя «общий интернет», в центре оранжевая «zapret», справа жёлтая «слова на границе» с честной подписью «значение зависит от контекста». Полные списки слов — в таблице ниже,
11:58
Speaker A
но сейчас важнее не заучить их состав, а выработать одну привычку. Привычка такая: читая чужой пресет и встретив незнакомое слово, первым делом прикиньте, из какой оно колонки. Из синей — значит, значение стандартное, сетевое, и его можно смело понимать как в любом учебнике по сетям; гуглится за минуту. Из оранжевой — это команда самому zapret,
12:19
Speaker A
и искать её смысл нужно в документации zapret, а не в общих знаниях про интернет: учебник тут не поможет, его писали до всякого zapret. Из жёлтой — читать вдвойне внимательно: в обычной сети слово значит одно, а в zapret2 за ним стоит конкретная деталь механики,
12:35
Speaker A
и подставив «обычное» значение, вы прочитаете правило неправильно. Почему это так важно на практике: перепутать колонку — типичная ошибка новичка, из-за которой весь пресет вдруг кажется бессмыслицей. Выглядит это всегда одинаково: человек видит знакомое слово, подставляет привычный смысл — и не понимает, почему правило ведёт себя не так,
12:55
Speaker A
как он ожидал. Он перечитывает пресет, проверяет опечатки, злится, идёт спрашивать в чат — а причина всего лишь в том, что слово было из жёлтой колонки, и читать его надо было в смысле zapret2.
13:07
Speaker A
Одна секунда на вопрос «из какой это колонки?» экономит потом час бессмысленной отладки. Для удобства всю эту сортировку можно держать в голове в виде таблицы — она сейчас на экране.
13:18
Speaker A
Дальше пройдём по каждому пограничному слову подряд — на экране они появляются карточками, где слева обычный сетевой смысл, а справа то, чем слово становится в zapret2. Заучивать их сейчас не нужно; цель проще — научиться узнавать эти слова в лицо и всякий раз уточнять,
13:34
Speaker A
в каком из двух смыслов они стоят. Разбирать будем нарочно явно и упрощённо, без синтаксиса и примеров из пресетов — сейчас важна суть, а не детали. По каждому из этих слов будет отдельный подробный разговор, когда перейдём непосредственно к разбору самого zapret2, — там
13:51
Speaker A
они лягут на конкретные шаги обработки пакета, и вы увидите их в работе. А пока — знакомство.
13:57
Speaker A
payload — начнём с самого слова, потому что оно того заслуживает. По-английски это «полезная нагрузка», и придумали его вовсе не для сетей. Payload — это то, ради чего запускают ракету: сама ракета, ступени, топливо и обшивка нужны лишь для доставки,
14:13
Speaker A
и все они по дороге сгорят и отвалятся, а полезная нагрузка — это спутник внутри, единственное, что должно долететь. Так же говорят про грузовик: часть веса приходится на кузов, двигатель и бак, а payload — то полезное, что он реально везёт клиенту. Идея во всех случаях одна:
14:30
Speaker A
есть оболочка-транспорт и есть ценное содержимое внутри. Payload — это именно содержимое, а не упаковка. Упаковку никто не заказывал — она просто необходима, чтобы содержимое доехало.
14:42
Speaker A
В сетях мысль ровно та же, только «упаковка» — это заголовки, а «полезная нагрузка» — данные под ними. Заголовок — служебная часть: адреса, порты, номера, контрольные суммы, всё то, что нужно самой сети, чтобы довезти пакет. Payload — то, ради чего пакет вообще отправили.
14:59
Speaker A
И вот тут начинается тонкость, из-за которой слово и попало в жёлтую колонку. Мы уже видели, что пакет устроен как матрёшка: уровень внутри уровня. Так вот, у каждого уровня этой матрёшки — свой заголовок спереди и свой payload следом. Для Ethernet-кадра полезная нагрузка — весь
15:17
Speaker A
IP-пакет целиком. Для IP-пакета — TCP-сегмент внутри него. Для TCP-сегмента — байты TLS. Для TLS — уже зашифрованные данные приложения, тот самый запрос страницы. Получается, один и тот же байт посреди пакета для одного уровня — payload, а для другого — часть чужой упаковки. Слово одно, а
15:38
Speaker A
охват каждый раз разный — помните скобку на схеме, которая прыгала вправо при каждой смене уровня?
15:40
Speaker A
Это она и есть. Поэтому сказать просто «payload» — всё равно что сказать «содержимое», не уточнив, содержимое чего: коробки, ящика или контейнера, в котором этот ящик едет. Всегда уточняем уровень.
15:51
Speaker A
Это был левый край карточки — общий сетевой смысл, он написан в любом учебнике. Теперь правый край: что со словом делает zapret2. Здесь payload — это уже не просто «данные под заголовком», а нечто более умное: распознанный тип содержимого. Разница принципиальная. Обычная сеть на содержимое
16:10
Speaker A
не смотрит — ей всё равно, что везти, лишь бы адрес был; для неё payload — просто мешок байтов.
16:16
Speaker A
А движок zapret2 в этот мешок заглядывает и пытается понять, что именно в нём едет: это TLS ClientHello — первое сообщение защищённого соединения, где открыто лежит имя сайта? Это QUIC Initial — такой же ранний пакет, но у современного транспорта? Или обычный HTTP-запрос со строкой
16:35
Speaker A
Host:? На карточке это те самые плашки после значка лупы: лупа — момент распознавания, плашки — возможные вердикты. И дальше вся логика zapret строится именно на этом вердикте: узнал в пакете ClientHello — применяй стратегию, не узнал ничего интересного — пропусти не глядя.
16:53
Speaker A
Именно поэтому zapret не трогает весь трафик подряд: подавляющее большинство пакетов для него «payload неинтересного типа», и они пролетают мимо без задержки.
17:03
Speaker A
Отсюда и вывод, вынесенный на карточке в самый низ: в обычных сетях payload — это данные, а в zapret2 payload — это данные плюс распознанный тип содержимого. Держите в голове оба смысла, оба скоро понадобятся: первый — когда будем читать байты пакета и искать, где кончается
17:20
Speaker A
упаковка и начинается содержимое; второй — когда дойдём до фильтров, которые выбирают трафик именно по типу содержимого. И если в пресете вы видите слово payload — это почти всегда второй смысл, прикладной: речь о том, что движок распознал внутри, а не о байтах вообще.
17:37
Speaker A
packet — слово тоже родом из обычной жизни. Packet по-английски — это пакет, свёрток, небольшая упаковка: пакетик чая, почтовый пакет, пачка чего-либо. Обратите внимание на масштаб слова: не мешок, не контейнер, а именно маленькая порция — в самом слове зашита уменьшительность, packet — это «пакетик». И суть везде одна: отдельная,
18:02
Speaker A
законченная порция, которую удобно взять и передать целиком, — в отличие от чего-то сплошного, что льётся рекой. Реку не возьмёшь в руки, пакетик — легко.
18:13
Speaker A
В сети packet — это ровно такая единица обмена: одна порция данных со служебным заголовком спереди и содержимым следом. Мы уже видели это на живом примере: большой файл не летит одним куском — он режется на пакеты, каждый пакет едет по сети самостоятельно,
18:31
Speaker A
сам по себе, со своим адресом на «конверте», а на месте получатель собирает их обратно в целое.
18:37
Speaker A
Один packet — один такой «свёрток» из общего потока. И помните дамп на 24 миллисекунды: в реальном проводе эти свёртки от разных программ едут вперемешку — кусок видео, сообщение мессенджера, DNS-запрос, — и каждый из них по отдельности называется этим словом.
18:56
Speaker A
Пока всё честно, и в синюю колонку слово не попало бы. Но смотрим на карточку справа — что с этим словом делает zapret2. А делает он вот что: отдельный пакет там почти никогда не рассматривают сам по себе, в вакууме — только в контексте. Для обычной сети два
19:15
Speaker A
пакета одинакового размера — просто два одинаковых свёртка. А движку zapret2 важен не «пакет вообще», а целый набор его признаков, и каждый признак — это ответ на конкретный вопрос. IPv4 это или IPv6 — по какой версии адресов он едет? TCP или UDP — каким способом доставки? В какую сторону
19:38
Speaker A
он идёт — от клиента к серверу или обратно? Это важно: воздействовать обычно нужно на исходящие пакеты, те, что мы сами отправляем. Есть ли внутри данные — или это пустой служебный пакет, одно голое подтверждение? И какая у пакета позиция в потоке — первый он в соединении,
19:58
Speaker A
второй, десятый? Позиция особенно важна: мы уже знаем, что всё самое интересное для DPI лежит в первых пакетах соединения, значит, и zapret охотится в первую очередь за ними. На карточке всё это — те самые ярлычки, которыми обвешано слово packet: один свёрток, а бирок на нём с полдюжины.
20:19
Speaker A
Из этих признаков и складывается решение, подходит ли пакет под правило: движок смотрит не «что это за пакет», а «что это за пакет, откуда, куда, какой по счёту и что у него внутри». Совпали признаки — пакет попадает под приём; не совпали — пролетает мимо нетронутым.
20:39
Speaker A
Поэтому запомните разницу, она же вынесена внизу карточки: в сети packet — просто единица обмена, безликий свёрток. А в zapret2 packet — это единица обмена вместе со всем её контекстом, и именно по контексту движок решает, что с ней делать. Когда в следующих видео вы встретите в
20:58
Speaker A
пресете условия вроде «первые N пакетов» или «только исходящие» — это как раз оно: правила разговаривают не с пакетом, а с его ярлычками.
21:09
Speaker A
protocol — пожалуй, самое «житейское» слово из всех. Протокол есть у дипломатов — строгий порядок, кто кого и как приветствует, кто входит первым, кто где сидит; нарушите — и встреча двух государств превратится в обиды и хаос. Протокол есть у врачей — заранее описанная
21:26
Speaker A
последовательность действий при болезни: сначала это, потом то, при таком-то результате — вот такое лечение; врач не изобретает порядок заново у постели каждого больного. Протоколом называют и запись хода собрания — кто что сказала и что постановили. Во всех случаях суть одна: это
21:44
Speaker A
согласованные заранее правила — как себя вести, в каком порядке, что за чем следует, — чтобы стороны понимали друг друга без путаницы. Заметьте важное: протокол работает, только когда его знают обе стороны. Дипломат, не знающий протокола, — источник международного скандала.
22:01
Speaker A
В сетях протокол — ровно то же самое, только договариваются не люди, а программы: набор правил, по которым две стороны общаются. Протокол задаёт всё: в каком виде слать сообщения, какими байтами они начинаются, чем на что отвечать, что делать при ошибке, как понять,
22:18
Speaker A
что разговор окончен. И так же, как у дипломатов, правила должны знать обе стороны: браузер говорит по HTTP — и сервер отвечает по HTTP; если бы каждый слал байты в своём формате, никто бы никого не понял. TCP, UDP, DNS, HTTP, TLS, QUIC — всё это протоколы, каждый со своими правилами,
22:39
Speaker A
и заметьте: мы уже полролика ими пользуемся. Когда мы говорили «TCP надёжный, с подтверждениями», «DNS спрашивает и отвечает», «TLS начинается с ClientHello» — мы каждый раз пересказывали кусочек правил соответствующего протокола. Так что слово это не новое — новым будет только уточнение.
22:58
Speaker A
А в zapret2 — и это видно на карточке справа — слово «протокол» коварно не тем, что меняет смысл, а тем, что протоколов в одном соединении едет сразу несколько, этажами, и путать этажи нельзя.
23:10
Speaker A
Вспомните матрёшку пакета: каждый её слой — это свой протокол со своими правилами. Есть транспорт — TCP или UDP: правила доставки, «как везём». Есть протокол приложения, его ещё зовут L7, — HTTP, TLS, QUIC: правила самого разговора, «о чём и в каком формате говорим». И есть тип payload внутри
23:32
Speaker A
потока — то самое распознанное содержимое из прошлой карточки: не просто «едет TLS», а «вот конкретно сейчас едет TLS ClientHello». На карточке эти три этажа выстроены ступенями сверху вниз — и одно и то же соединение честно присутствует на всех трёх сразу: по транспорту
23:49
Speaker A
оно TCP, по приложению TLS, а текущий payload в нём — ClientHello. Ни одна из этих характеристик не отменяет другие — как человек одновременно может быть «россиянин, инженер, на совещании».
24:02
Speaker A
Поэтому, встретив в пресете слово «протокол», всегда уточняйте, о каком этаже речь. Фильтр «по протоколу TCP» и фильтр «по протоколу TLS» — это условия на совершенно разных уровнях: первый цепляет вообще весь TCP-трафик — и сайты, и почту, и мессенджеры скопом, — а
24:19
Speaker A
второй только защищённые соединения, причём независимо от того, на чём они едут. Перепутать этажи — значит написать правило, которое ловит или слишком много, или слишком мало, или вообще не то. Это частый источник пресетов, которые «почему-то не срабатывают»: правило синтаксически верное, слово знакомое — а этаж не тот. Одна привычка — мысленно спрашивать
24:40
Speaker A
«протокол какого уровня?» — закрывает целый класс таких ошибок. Кстати, привычка та же самая, что и с payload: слово одно, уровней несколько, всегда уточняем который.
24:50
Speaker A
host — по-английски «хозяин», принимающая сторона, и слово это тоже пришло не из сетей. Хост — это ведущий передачи, который принимает гостей в студии; хостом называют того, кто устраивает у себя приём или пускает путешественников переночевать; в биологии хозяин-host — организм, на котором живёт паразит. Заметьте, во всех случаях смысл
25:14
Speaker A
один и тот же: host — это не гость и не груз, а тот, у кого всё происходит. Тот, кто принимает у себя кого-то или что-то — и по чьему адресу этого кого-то можно найти.
25:26
Speaker A
В сетях мысль ровно та же: host в широком смысле — это узел, машина в сети, которая «принимает у себя» службы и отвечает на обращения. У такой машины есть адрес, а часто и имя — отсюда «имя хоста», hostname: example.com — это человеческое имя той машины, к которой мы обращаемся. Обратите
25:48
Speaker A
внимание на тонкость, она нам уже встречалась в разделе про домены: example.com, www.example.com и api.example.com — это три разных имени хоста, даже если для человека это «один сайт».
26:05
Speaker A
Для сети хост — это конкретное имя, а не сайт в бытовом смысле, и дальше эта разница выстрелит.
26:11
Speaker A
А в zapret2 — как показано на карточке справа — host это уже не то, что вы набрали в адресной строке, и вообще не то, что кто-то ввёл руками. Это имя, которое движок сам достаёт из проходящего трафика: заглядывает в раннее сообщение протокола — в заголовок Host, если это открытый HTTP,
26:30
Speaker A
или в поле SNI, если это TLS, — и вытаскивает оттуда имя сайта, к которому на самом деле идёт это соединение. На карточке видна вся цепочка: раннее сообщение → извлечённое имя → сверка со списком. То есть host в zapret2 — это не ввод пользователя, а результат разбора живых пакетов.
26:52
Speaker A
И вот здесь ключ к применению: извлечённый host движок сверяет с hostlist — тем самым списком сайтов из второй группы терминов, к которым мы хотим применить приём. Совпало имя со списком — пакет обрабатываем, не совпало — пропускаем не глядя. Именно на
27:08
Speaker A
этой сверке держится вся точечная работа zapret: «трогаем только эти сайты, остальные не трогаем». Отсюда вывод, вынесенный на карточке в самый низ: в обычных сетях host — это машина и её имя, а в zapret2 host — это имя, извлечённое из трафика для сверки со списком. Держите
27:28
Speaker A
в голове оба смысла: первый пригодится, когда будем смотреть, куда идёт соединение, второй — когда дойдём до hostlist и увидим, как zapret выбирает, какой трафик его вообще касается.
27:39
Speaker A
filter — тут повезло: это то редкое слово, которое значит ровно то, что вы и думаете.
27:45
Speaker A
Фильтр в кофеварке пропускает воду и держит гущу. Фильтр в почте пропускает письма от людей и топит спам. Идея везде одна: стоит условие, и всё, что через него идёт, делится на два потока — «проходи» и «мимо».
28:00
Speaker A
Теперь примерьте это на zapret. Через ваше устройство летят тысячи пакетов в секунду: обновления, мессенджеры, фоновая синхронизация, чей-то торрент на соседнем устройстве за роутером.
28:12
Speaker A
А обходить блокировку нужно, скажем, только для YouTube. Неужели разбирать каждый пакет подряд и спрашивать «а ты не YouTube случайно?» — всеми силами движка? Вот чтобы этого не делать, на входе и стоит фильтр: короткая, дешёвая проверка, которая мгновенно отвечает на один
28:28
Speaker A
вопрос — наш это трафик или не наш. Отобрать можно по разным признакам: по IP или целой подсети, по порту, по имени сайта, по протоколу, по свойствам самого пакета. Не прошёл — свободен, движок его даже не разглядывает.
28:44
Speaker A
Почему это так важно, станет понятно, если вспомнить, как zapret2 устроен внутри. Сами приёмы обхода написаны на Lua — это удобный язык, на нём легко описывать логику, но звать его на каждый пакет подряд дорого: пока Lua проснётся, подумает и ответит, мимо пролетит ещё сотня
29:02
Speaker A
пакетов. Фильтр же — это быстрая проверка ещё на дешёвом уровне, до всей тяжёлой машинерии.
29:09
Speaker A
Получается вышибала у входа в клуб: он не ведёт с каждым гостем душевную беседу — он смотрит на список и за секунду решает, пускать ли дальше, туда, где уже начинается настоящая работа.
29:21
Speaker A
Отсюда и то, что вы увидите в любом пресете: фильтр почти всегда стоит первым. Сначала «кого берём», и только потом «что с ним делаем». Так что, читая чужой конфиг, начинайте с фильтра — он честно расскажет, на какой трафик вообще нацелено правило,
29:38
Speaker A
ещё до того, как вы разберётесь в самом приёме. range — по-английски «диапазон», «отрезок». Запас хода у электромобиля — range, разброс значений «от и до» — тоже range. Смысл везде один: не точка и не «всё сразу», а участок с началом и концом.
29:57
Speaker A
Чтобы понять, зачем это слово нужно zapret, вспомните, что соединение — не мгновенная вспышка. Оно живёт во времени, как разговор по телефону: сначала «алло» и «вы меня слышите?», потом сам разговор, и он может тянуться минутами — гигабайты видео, тысячи пакетов. И вот вопрос: если мы хотим
30:17
Speaker A
применить приём обхода, надо ли обрабатывать весь этот разговор, до последнего пакета? Не надо — и вот почему. Всё, за что цепляется DPI, живёт в первых секундах соединения: имя сайта в ClientHello, признаки протокола, ранние незашифрованные кусочки. Дальше поток закрывается шифром, и там для блокировки уже просто не за что ухватиться — а значит,
30:41
Speaker A
и обходить там нечего. Обрабатывать середину зашифрованного потока — всё равно что продолжать шептать, когда подслушивающий давно ушёл: сил тратится много, смысла ноль.
30:51
Speaker A
Range — это и есть прицел по этой протяжённости: «работай вот отсюда и досюда». Чаще всего — только первые пакеты соединения, иногда конкретные байты или отрезок TCP-потока. Заметьте, как это складывается с фильтром в одну систему наведения: фильтр отвечает на вопрос «какой
31:10
Speaker A
трафик наш», а range — «какая часть этого трафика нам нужна». Сначала выбрали цель, потом прицелились в её уязвимое место. Именно поэтому хорошо написанный пресет тратит силы на считанные первые пакеты каждого соединения — а всё остальное пролетает мимо zapret вообще без обработки, как будто его и нет.
31:30
Speaker A
direction — «направление». Самое честное слово во всей жёлтой колонке: никаких скрытых смыслов, пакет либо едет от вас, либо к вам. Но не спешите пролистывать — именно на этом простом слове новички чаще всего сжигают время впустую.
31:47
Speaker A
Смотрите: у любого соединения два потока навстречу друг другу. Исходящий — то, что отправляете вы: запросы, тот самый ClientHello с именем сайта. Входящий — то, что летит обратно: ответы сервера, страницы, видео. И вот ключевой вопрос, который стоит задать: а кто из них выдаёт
32:07
Speaker A
вас DPI? Вспомните прошлые разделы: DPI цепляется за имя сайта, а имя сайта везёт исходящий ClientHello. Это мы его отправляем, это наш пакет проходит мимо фильтра провайдера по пути туда. Ответ сервера, конечно, тоже идёт через DPI, но главная улика — в исходящем потоке.
32:27
Speaker A
Отсюда прямое следствие для zapret: большинство приёмов обхода имеет смысл применять только к исходящим пакетам. Обрабатывать входящие тем же приёмом — в лучшем случае бесполезно, в худшем можно сломать себе же приём страницы. Поэтому в правилах zapret2 направление указывается явно: этот приём — только для того, что уходит от нас;
32:50
Speaker A
этот — только для ответов. Не «на всякий случай в обе стороны», а прицельно. И теперь система наведения собралась целиком, все три вопроса подряд: фильтр — какой трафик наш, range — какая часть соединения нам нужна, direction — в какую сторону
33:06
Speaker A
смотрим. Три коротких слова, а вместе они означают: zapret не молотит по всему подряд, он бьёт в одну точку — в первые исходящие пакеты нужного сайта. Запомните эту мысль, она ещё не раз выручит при чтении чужих пресетов: если правило ведёт
33:22
Speaker A
себя странно, первым делом проверьте, не перепутано ли в нём одно из этих трёх. profile — у слова десяток бытовых значений: профиль лица, профиль в соцсети, профиль настроек в программе. Нам ближе всего последнее — сохранённый набор параметров под конкретный случай. Но в zapret2 это не просто «настройки»,
33:43
Speaker A
а кое-что поинтереснее, и вот тут стоит быть внимательным. Профиль в zapret2 — это блок «условия → действия». Читается он как обычное «если — то»: если пакет подходит под такие-то условия — применить такие-то приёмы. И заметьте, что за условия там стоят: это и есть наши старые знакомые из прошлых карточек — фильтр, range, direction.
34:06
Speaker A
Вот зачем мы их разбирали по отдельности: профиль просто собирает их в одно правило и прикручивает к ним действие. «Исходящие пакеты (direction) на порт 443 для сайтов из списка (filter), первые пакеты соединения (range) — резать вот так». Одно предложение — один профиль. А пресет целиком — это
34:27
Speaker A
стопка таких профилей, одно правило под YouTube, другое под Discord, третье под всё остальное. Теперь самое важное — как движок эту стопку читает. Пришёл пакет — движок идёт по профилям строго сверху вниз и берёт первый подходящий. Не «самый точный», не «все подходящие сразу» — именно
34:47
Speaker A
первый. Дальше он даже не смотрит: пакет уже забран, вопрос закрыт. Как охранник со списком гостей: нашёл ваше имя в третьей строке — всё, проходите, до конца списка он не дочитывает.
34:58
Speaker A
И вот здесь зарыта одна из самых частых ошибок новичков — запомните её сейчас, сэкономите себе вечер. Человек дописывает в конец пресета новое, идеально настроенное правило под нужный сайт... и оно не работает. Он проверяет синтаксис, меняет приёмы, злится — а правило в
35:16
Speaker A
полном порядке. Просто выше в стопке стоит более общий профиль, который перехватывает эти пакеты раньше, и до нового правила очередь физически не доходит. Лечение — переставить своё правило выше перехватчика. Отсюда и главная привычка: читайте чужой пресет так, как читает его движок, — сверху вниз, помня, что верхние правила всегда голоднее нижних.
35:40
Speaker A
dissect — по-английски «рассекать», «препарировать». Слово из анатомического класса: лягушку на столе вскрывают, чтобы из непонятного комка получились видимые органы — вот сердце, вот лёгкие. Смысл — разложить целое на понятные части, чтобы увидеть, как оно устроено.
35:57
Speaker A
И к сетям это прилипло буквально. Если вы когда-нибудь открывали Wireshark — программу, которая показывает трафик, — вы это уже видели: сырой пакет там не лежит сплошной лентой байтов, он аккуратно разложен на дерево. Раскрываешь ветку — вот адреса, раскрываешь другую — вот порты, вот флаги, вот поле за полем. Компоненты, которые это делают,
36:19
Speaker A
в Wireshark так и называются — диссекторы. Zapret взял и слово, и саму идею оттуда.
36:25
Speaker A
Теперь зачем это внутри zapret2, и тут кроется вся суть. Вспомните, что движок живёт на двух языках: тяжёлую черновую работу тянет быстрый C, а приёмы обхода пишут на Lua — том самом удобном языке из карточки про фильтр. Так вот, диссект — это мост между ними. C-часть делает
36:45
Speaker A
самую нудную работу: берёт сырые байты, вскрывает пакет, а заодно, если надо, собирает по кусочкам и расшифровывает начало TLS или QUIC — и складывает всё это в аккуратное дерево. А Lua получает уже готовое: не «мешок байтов, разбирайся сам», а структуру, где по имени можно спросить «дай TTL», «дай имя сайта из ClientHello».
37:07
Speaker A
Автору приёма не надо считать смещения и длины руками — за него это уже сделал C.
37:13
Speaker A
Поэтому запомните на будущее вот что: когда дальше встретится слово dissect, речь не про сам байтовый пакет из проводов, а про его удобный разобранный вид — ту самую структуру, с которой и работает стратегия. А в следующем видео, про механизм zapret2, вы увидите и кое-что поинтереснее:
37:31
Speaker A
этот диссект не просто читают — он путешествует через стратегию от приёма к приёму, и каждый может его на ходу подправить, а следующий уже видит изменённую версию. Но это забегание вперёд — пока достаточно образа: dissect — это пакет, выложенный на стол и разобранный на подписанные части.
37:51
Speaker A
blob — слово нарочно неряшливое. По-английски blob — это бесформенный комок, капля, клякса: капнули краской на стол — вот вам и blob, масса без формы. В программировании оно давно прижилось как BLOB, «binary large object», «двоичный большой объект» — просто кусок байтов,
38:12
Speaker A
про который не спрашивают, что там за структура: хоть картинка, хоть файл, хоть что попало.
38:18
Speaker A
И тут приятный контраст с прошлым словом. Диссект — это входящий пакет, аккуратно разобранный на подписанные части: вот адрес, вот порт, вот флаг. Blob — полная противоположность: байты, у которых структуры нет вообще и не предполагается. В zapret2 blob — это
38:38
Speaker A
просто переменная с двоичными данными любой длины, буквально от одного байта до гигабайтов. Так что «large object» — название историческое: в zapret блоб запросто бывает и в один-единственный байт.
38:51
Speaker A
Зачем такая штука? Главная его работа — быть телом подделки. Помните слово fake из оранжевой колонки — приём «подсунуть DPI поддельный пакет»? Так вот, начинка этого фальшивого пакета и есть blob. Больше того, самые ходовые фейки уже лежат в zapret готовыми блобами: заготовка под TLS, под HTTP, под QUIC — их не надо собирать руками,
39:16
Speaker A
они идут из коробки. Вторая роль скромнее — быть узором-заготовкой: движок берёт blob и растягивает его по размеру пакета, когда приёму надо чем-то заполнить или перекрыть данные.
39:28
Speaker A
Но какую бы роль blob ни играл, суть слова одна, и её стоит унести с собой: это чистые байты без привязки к протоколу. Blob не «знает», TLS он или HTTP, — важны ровно две вещи: его точное содержимое и его длина. Длина,
39:45
Speaker A
кстати, настолько важна, что на неё в пресете есть отдельный значок — движок умеет подставить размер блоба прямо в параметр. Одной фразой: диссект мы читаем, чтобы понять чужой входящий пакет, а blob собираем, чтобы отправить или подмешать свой. Когда дойдём до fake в видео про механизм,
40:04
Speaker A
blob окажется именно тем «телом», которое zapret подсовывает фильтру вместо настоящего сообщения. raw — по-английски «сырой», необработанный. Сырое мясо, сырьё, RAW-снимок с фотоаппарата — это сенсор как есть, без обработки. В технике raw — данные или доступ «как есть», впритык к железу,
40:24
Speaker A
без удобных надстроек: raw-доступ к диску — работа с байтами напрямую, минуя файловую систему. Общий смысл — то, что ещё не завернули в удобную оболочку.
40:34
Speaker A
И вот тут красиво: raw — это противоположный конец той же оси, на которой стоит диссект. Диссект, помните, — пакет, любезно разобранный C-частью на подписанные поля, работа сделана за вас.
40:46
Speaker A
Raw в zapret2 — обратная сторона: место, где удобных абстракций нет и с пакетом имеешь дело почти как с голыми байтами. В доках слово всплывает ровно там, где движок работает вплотную к проводу: при старте nfqws2 честно пишет в лог
41:04
Speaker A
«initializing raw sockets» — открывает сырые сокеты, низкоуровневый механизм системы, которым можно собрать пакет побайтно и выложить прямо в сеть, минуя обычный сетевой стек.
41:15
Speaker A
Через этот сырой уровень и уходят подделки. Помните blob — байтовое «тело» фальшивого пакета? Так вот, наружу его выпускают как раз функции семейства rawsend: берут blob, при надобности режут на сегменты или IP-фрагменты и инъецируют в сеть сырым сокетом. То есть blob — что отправляем,
41:34
Speaker A
raw-отправка — как отправляем, в обход нормального пути. А ещё «raw» в доках означает нераспознанный пакет: если внутри не TCP, не UDP и не ICMP, движок не знает, как его разбирать, и держит его как «raw ip» — голый IP-заголовок да payload, сырой кусок без разбора на поля.
41:53
Speaker A
Отсюда и честное предупреждение, ради которого это слово и стоит запомнить. Всё, что обычные уровни делают за вас на автомате — считают длины, проверяют смещения, следят за корректностью, — на сыром уровне ложится на движок и на автора пресета. Raw даёт больше контроля,
42:10
Speaker A
но и куда больше шансов промахнуться: ошибся в длине или смещении — и пакет уедет битым. Это территория для тех, кто уже понимает, что делает; в нулевом видео нам хватит одного рефлекса: увидел «raw» — значит, речь про низкий уровень, ближе к байтам, аккуратнее.
42:26
Speaker A
Теперь простой вопрос: если бы кто-то захотел просматривать и фильтровать ваш трафик, где ему выгоднее всего встать? Не у каждого же сайта в дата-центрах по всему миру.
42:37
Speaker A
Ответ подсказывает сама цепочка. Вспомните звено, про которое я сказала «через него идёт весь ваш трафик до единого пакета» — оборудование провайдера. Это и есть идеальная точка контроля: как в почте нет смысла караулить каждый ящик в городе, если можно поставить проверку на
42:54
Speaker A
единственном сортировочном центре, через который всё равно проходят все письма. Поэтому на схеме над узлом провайдера висит лупа — именно здесь удобнее всего решать, пропустить пакет, замедлить или проанализировать. Ту самую технику, что стоит в этой точке и заглядывает в трафик,
43:11
Speaker A
мы разберём отдельно — это DPI; пока достаточно запомнить, где она сидит. А теперь — самое важное для всего курса, ради чего мы и рисовали эту линию. Посмотрите ещё раз, где на ней вы, а где лупа. Вы — в самом начале, у левого края. Лупа провайдера — дальше по маршруту.
43:30
Speaker A
И сам zapret живёт вместе с вами, у того же левого края: на вашем компьютере или на вашем роутере, в самом начале пути. Не «где-то в интернете», не на стороне сервера — ровно здесь, у вас. А значит, zapret ходит первым: он успевает поработать с пакетом ещё до того, как тот дойдёт до фильтра,
43:49
Speaker A
и изменить его так, чтобы к моменту встречи с DPI картина оказалась не той, на которую фильтр рассчитывал. Возвращаясь к почте — zapret сидит за вашим столом и переписывает конверт ещё до того, как письмо вынесли из здания, а инспектор ждёт его только на сортировке, дальше по пути. Всю
44:07
Speaker A
остальную дорогу — магистрали, дата-центр, сервер — zapret не контролирует и не пытается: его зона только ваш конец линии. Эту границу полезно держать в голове.
44:18
Speaker A
Ещё пара уточнений, чтобы картинка была честной. Во-первых, маршрут не высечен в камне и не обязан быть симметричным. Запрос может уйти одним набором узлов, а ответ вернуться слегка другим путём.
44:30
Speaker A
Сегодня трафик идёт через один участок сети, завтра через другой — особенно если у провайдера работает балансировка или меняются маршруты. Для вас это невидимо: сайт либо открылся, либо нет. Но для диагностики блокировок важно — разные участки могут фильтровать по-разному, и то, что не
44:48
Speaker A
открывалось час назад, вдруг открывается сейчас просто потому, что пакет поехал другой дорогой. Во-вторых — и это подводит нас к самому нерву темы — промежуточные узлы вовсе не обязательно «видят страницу» так, как видите её вы. Если соединение защищено TLS (протокол шифрования,
45:06
Speaker A
разберём его подробно в разделе про HTTP и TLS), само содержимое страницы для постороннего закрыто — как запечатанное письмо внутри конверта. Казалось бы, тут фильтрации и конец: раз ничего не видно, что анализировать?
45:20
Speaker A
А вот здесь и кроется главное недоразумение. Закрыто содержимое — но не сам конверт. Снаружи, в открытом виде, остаётся масса примет, и пройдёмся по ним по одной. Видны IP-адреса — кто с кем вообще соединяется. Виден порт — к какой службе на сервере идёт обращение (что такое порт,
45:38
Speaker A
разберём буквально через раздел). Видно направление — летит пакет к серверу или обратно. Видны размеры пакетов и время — сколько данных и когда прошло. Виден сам факт соединения — что связь была, даже если больше ничего не понятно. И самое ценное для анализа — ранние,
45:55
Speaker A
ещё не зашифрованные части протоколов; в первую очередь имя сайта, которое браузер открыто передаёт в самом начале TLS-соединения. Вот это имя дальше и станет главной мишенью.
46:06
Speaker A
Может показаться, что без содержимого все эти приметы — мелочь. Совсем нет. По одним только размерам и ритму пакетов часто видно, чем вы заняты: у видео пакеты крупные и идут плотным потоком, у переписки в мессенджере — редкие и мелкие,
46:21
Speaker A
у звонка — равномерные и частые, как метроном. Добавьте порт и IP-адрес — и уже с большой вероятностью можно назвать сервис, ни разу не заглянув внутрь. Именно поэтому шифрование само по себе не делает трафик невидимым: спрятать можно данные, но не сам факт и форму обмена.
46:38
Speaker A
Вот из этой трещины и вырастает вся работа zapret. Спрятать приметы целиком нельзя — без адресов и портов сеть просто не довезёт пакет, это не блажь, а физическая необходимость. Но ранние открытые части — и то, как именно они разложены по пакетам, — zapret изменить может: так, чтобы DPI разобрал начало соединения иначе,
46:57
Speaker A
чем настоящий сервер, и не нашёл той приметы, по которой собирался блокировать. Как именно — это и есть содержание разделов про DPI и про сам zapret; пока достаточно усвоить одно: фильтрация питается внешними приметами обмена, и работать zapret будет ровно с ними.
47:13
Speaker A
И раз уж весь этот обмен всё равно идёт через промежуточные узлы, именно там его удобнее всего фильтровать, замедлять или блокировать — отсюда дальше вырастут три разных вида блокировки: по DNS, по IP и через DPI. Но прежде чем ломать соединение, его надо установить, а для этого
47:30
Speaker A
устройство должно сначала вообще найти сервер — понять, куда стучаться. С этого и продолжим. В конце прошлого раздела мы упёрлись в вопрос: прежде чем ломать или защищать соединение, устройство должно вообще найти сервер — понять, куда стучаться. Вот с этого «куда» и начнём, а начинается оно с имени.
47:49
Speaker A
Мы привыкли открывать сайты по именам: youtube.com, google.com, example.com. Такое имя называется доменом. И придуман домен целиком ради человека: его можно запомнить, набрать в адресной строке, продиктовать вслух по телефону, кинуть другу в сообщении. Вся суть домена — быть удобным для нас с вами. Машине он, как мы скоро увидим, вообще не нужен.
48:12
Speaker A
Но прежде чем идти дальше, разведём две вещи, которые в быту постоянно валят в одну кучу, — сам домен и полный адрес страницы. Для нашей темы это не занудство, а различие принципиальное. Возьмём типичную строку из адресной строки браузера: https://example.com/path/page. На вид — одно сплошное месиво из букв и косых черт,
48:39
Speaker A
а на самом деле это три разные части, у каждой своя работа. Разберём по кусочкам. Впереди стоит https:// — это схема, то есть по какому протоколу мы стучимся (что это значит — разберём чуть позже). В середине example.com — и вот только это и есть домен: имя той конкретной машины в сети,
49:00
Speaker A
к которой мы обращаемся. А хвост /path/page — это путь уже внутри сайта, к конкретной странице. Итого: домен — лишь серединка, имя машины. Всё, что вокруг, — служебная обвязка.
49:14
Speaker A
Зачем я так въедливо развожу эти части? Затем, что блокировки и zapret работают с доменом — и почти никогда с путём. Вот ключевой момент, который стоит уложить сразу. Когда соединение идёт по HTTPS, путь /path/page для стороннего наблюдателя невидим: он уезжает внутри шифрования вместе со всем остальным содержимым. DPI попросту не знает,
49:38
Speaker A
какую именно страницу вы открыли. А что торчит наружу, в открытом виде, — так это только имя example.com, да и то лишь в самом начале соединения. Поэтому дальше по всему курсу мы будем много говорить про имя сайта и почти не будем про путь: для нашей темы путь наблюдателю
49:55
Speaker A
недоступен, а значит, ни блокировке, ни обходу опереться на него не на что. И ещё одно, что стоит вынести отдельно, — поддомены. Вы их видели: www.example.com, api.example.com, static.example.com. Для человека это по-прежнему «тот же сайт, example.com». Но технически это разные имена — и сеть относится к ним как к разным. Каждое может превращаться
50:23
Speaker A
в свой отдельный IP-адрес, жить на своём сервере и фильтроваться само по себе, независимо от соседей.
50:30
Speaker A
И это не абстрактная теория — на практике она кусается постоянно. Хорошая новость: поддомены zapret берёт на себя сам. Строчка example.com в списке хостов накрывает и www.example.com, и api.example.com — движок отрезает поддомен и проверяет родительский домен. (Если нужно наоборот, только сам сайт без поддоменов, — ставят крышечку: ^example.com.)
50:58
Speaker A
А вот настоящая ловушка ждёт рядом. Сайт почти никогда не живёт на одном имени: страницу он отдаёт с одного домена, а видео, картинки и API — с совсем других. YouTube — это youtube.com плюс googlevideo.com, откуда реально льётся видео. Discord — это discord.com,
51:18
Speaker A
discord.gg и discord.media сразу. Instagram подтягивает картинки с cdninstagram.com. И это уже не поддомены, а посторонние имена — под правило для основного сайта они не попадают ни при каких условиях. Отсюда честный вывод: страница может открыться, а видео не поедет;
51:38
Speaker A
чат подключится, а звонок развалится. Проверять список надо по всем именам, которые сайт реально дёргает, — иначе почините фасад, а половина здания останется тёмной.
51:49
Speaker A
Итак, домен — это имя для человека. Теперь посмотрим на ту же ситуацию глазами машины, и окажется, что имя ей, по сути, бесполезно.
51:57
Speaker A
Проще всего это почувствовать через телефон. Откройте контакты — там записано «Мама», «Иван», «Доставка пиццы». Эти имена удобны вам: вы же не помните наизусть одиннадцать цифр каждого номера. Но сам телефон именами не звонит. Когда вы жмёте на «Маму», он под капотом достаёт настоящий номер и набирает именно его — цифры,
52:18
Speaker A
а не слово. Имя существует только для вас, на экране; в сеть уходит номер. В интернете — один в один. youtube.com — это «Мама» в ваших контактах: удобная подпись для человека. Но чтобы реально соединиться с сервером, устройству нужен его настоящий сетевой адрес — набор чисел, который называется IP-адрес.
52:38
Speaker A
Вот он и есть «телефонный номер» машины в сети. Ни один пакет никуда не поедет по имени youtube.com — он поедет по IP. Имя — это ярлык поверх адреса, не более.
52:50
Speaker A
Как этот адрес выглядит. Их в ходу два вида, и оба стоит узнавать в лицо. Первый, старый и самый привычный, — IPv4: четыре числа через точки, каждое от 0 до 255, например 142.250.185.78. Именно его обычно и представляют, когда слышат «айпишник». Проблема
53:16
Speaker A
в том, что таких адресов конечное число — примерно четыре миллиарда, — и на сегодняшний интернет с его морем устройств их банально перестало хватать. Поэтому есть и второй вид — IPv6: он куда длиннее, записывается шестнадцатеричными группами через двоеточия, вроде 2a00:1450:4001:800::200e,
53:47
Speaker A
и адресов в нём столько, что хватит с запасом на всё обозримое будущее. Оба вида живут в сети одновременно, и один и тот же сайт частенько доступен сразу и по IPv4, и по IPv6.
54:01
Speaker A
И вот тут — момент, ради которого и затевалось всё это разделение на «имя» и «адрес», так что задержимся на нём. Раз у сайта есть две разные личности — читаемое имя и числовой адрес, — то и заблокировать его, оказывается, можно на двух совершенно разных уровнях. Можно ударить по имени:
54:20
Speaker A
подстроить так, чтобы устройство вообще не смогло превратить youtube.com в его IP, — то есть сорвать сам перевод имени в адрес. А можно ударить по адресу: пусть имя спокойно превращается в IP, но пакеты, отправленные на этот IP, дальше не пропускать. Два уровня, два разных приёма — и работают они независимо друг от друга.
54:43
Speaker A
Держите эту развилку в голове, к ней мы ещё вернёмся вплотную: она и есть корень двух из трёх главных видов блокировки, про которые пойдёт речь дальше, — блокировки по DNS (удар по имени) и блокировки по IP (удар по адресу).
54:58
Speaker A
Пока не разбираем, как именно каждая устроена, — важно лишь увидеть, что сама возможность двух ударов растёт напрямую из того, что у сайта есть и имя, и номер.
55:09
Speaker A
Теперь вернёмся к адресам — и разрушим последнее наивное представление, которое ещё могло остаться. До сих пор мы говорили так, будто у сайта есть его IP-адрес. Один, свой, как номер телефона. На деле всё куда веселее, и это веселье лежит в основе половины блокировок.
55:26
Speaker A
Начнём с простого опыта. Спросите у DNS адрес крупного сайта — и вам вернётся не один адрес, а целый список. Не потому что справочная запуталась, а потому что за именем youtube.com стоит не сервер, а огромный парк серверов, разбросанных по всему миру. Крупные сервисы держат копии в десятках стран — это называется CDN,
55:48
Speaker A
сеть доставки контента, — и DNS специально отдаёт вам тот адрес, что ближе и свободнее.
55:54
Speaker A
Вы во Франкфурте — получите немецкий сервер. Ваш сосед по подъезду, спросивший минутой позже, вполне может получить другой адрес. И вы оба будете правы: оба откроете «тот самый» ютуб.
56:06
Speaker A
Отсюда первое следствие, довольно неуютное: IP сайта — не константа. Он может отличаться у вас и у соседа, меняться при переезде, меняться просто со временем — сервис добавил площадку, увёл нагрузку, поменял конфигурацию. Имя стабильно, адрес — текучая величина.
56:23
Speaker A
А теперь переверните картинку — и станет ещё интереснее. Если один домен может жить на многих адресах, то и один адрес может обслуживать многие домены. Это буквально норма современного интернета: на общем хостинге на одном IP спокойно сидят сотни разных сайтов,
56:41
Speaker A
а за адресами больших CDN вроде Cloudflare стоят вообще тысячи. Один и тот же IP сегодня — это и чей-то интернет-магазин, и блог о рыбалке, и заблокированный сервис, и сайт больницы.
56:53
Speaker A
Держите обе эти мысли рядом — и вы поймёте кое-что важное про блокировку по IP. Помните развилку из части 2: бить можно по имени (DNS) или по адресу (IP)? Так вот, удар по адресу — это стрельба дробью. Заблокировали IP ради одного сервиса — и
57:10
Speaker A
уронили всех соседей по адресу заодно. Отсюда легендарные истории про «блокировали одно, легло пол-интернета»: это не байка и не преувеличение, это прямое следствие того, что за одним адресом стоит толпа. И работает это в обе стороны: сервис легко переезжает на новый IP,
57:28
Speaker A
а блокировка остаётся висеть на старом — и бьёт уже только по невиновным. Из той же пары мыслей растёт и очень практический вывод про сам zapret. Раз адреса текучи, а под одним адресом — толпа чужих сайтов, то строить правила по IP — гиблое дело:
57:44
Speaker A
список протухнет через неделю, а заодно зацепит соседей. Поэтому zapret работает по именам. В его списках лежат домены, а не адреса, — и имя он берёт не из ваших настроек, а прямо из вашего трафика: из заголовка Host в обычном HTTP и из поля SNI в TLS-рукопожатии.
58:03
Speaker A
Проще говоря — из того самого места, куда браузер сам, добровольно, открытым текстом пишет, куда он собрался. Сколько бы адресов ни было у ютуба и как бы они ни менялись — имя youtube.com в начале соединения остаётся тем же самым. Оно и есть надёжный якорь.
58:20
Speaker A
И вот здесь надо сказать вторую неприятную правду — сразу вслед за той, что была про DNS. Если сайт заблокирован по IP — то есть провайдер просто не пропускает пакеты на этот адрес, — zapret снова бессилен. По той же причине, по которой он бессилен при подмене DNS: обманывать DPI
58:38
Speaker A
можно только там, где решение принимается по содержимому пакета. А блокировка по IP смотрит не в содержимое, а в адрес на конверте: пакет летит на запрещённый адрес — пакет уничтожается, и никакая маскировка начинки тут не спасёт. Иногда выручает то, что у сайта есть другие,
58:57
Speaker A
незаблокированные адреса — тогда можно ходить через них. А если адрес у сайта ровно один и он в чёрном списке — zapret не поможет, точка. Итого держите в голове две границы: подмена DNS и блокировка по IP — не территория zapret. Его территория — третий случай.
59:15
Speaker A
Вот к нему и подходим. Смотрите, что получилось у цензора. Блокировать по IP — грубо, дорого и валит невиновных. Ломать DNS — эффективно, но лечится сменой DNS-сервера за две минуты, и пользователи это давно освоили. Остаётся одно: разрешить соединению установиться,
59:32
Speaker A
дождаться, когда браузер сам назовёт имя сайта, — и уже по имени решать судьбу соединения. Это и есть DPI. А имя браузер называет всегда: в HTTP — в заголовке Host, в HTTPS — в поле SNI внутри первого же пакета TLS-рукопожатия, ещё до того,
59:50
Speaker A
как включится шифрование. Тот самый ClientHello, который мы уже поминали, — он летит открытым. Вот эта единственная строчка с именем сайта, отправленная вами добровольно и в открытую, и есть главное поле битвы. Именно её ищет DPI. Именно вокруг неё построены
60:08
Speaker A
почти все приёмы zapret. И именно с ней мы будем разбираться в следующем разделе. Чтобы превратить домен в IP, используется DNS - и маленькая схема из четырёх шагов уже показывает всю идею: сначала домен, затем запрос к DNS, следом ответ с IP-адресом и только потом
60:26
Speaker A
подключение к серверу по этому адресу. Разберём этот механизм подробно в следующем разделе. Со справочной мы уже знакомы: приносишь имя — получаешь адрес, и по дороге ответ могут подменить. Схема сверху — та самая базовая сценка, четыре шага: ввели имя, спросили,
60:42
Speaker A
получили IP, поехали подключаться. Держим её как скелет, а теперь нарастим на него то, без чего в реальной диагностике никуда: кто именно спрашивает и что именно приходит в ответ. Звучит занудно, а на деле именно здесь прячутся ответы на самые бесячие бытовые загадки.
61:00
Speaker A
Начнём с «кто спрашивает» — потому что интуиция здесь врёт. Кажется, что DNS-запрос делает «компьютер», один и единый. На самом деле спросить может каждый по-своему: сам браузер, операционная система, домашний роутер, любая отдельная программа. И между ними действует иерархия, которую стоит запомнить в одну строчку:
61:19
Speaker A
настройка выше по цепочке перекрывает всё, что ниже. Если браузер решил ходить со своим собственным DNS — ему глубоко безразлично, что прописано в системе. Если в системе задан свой сервер — роутер со своими настройками уже не при делах. Схема это и показывает двумя половинами:
61:36
Speaker A
слева лесенка «браузер → система → роутер» со стрелками-приоритетами, справа — откуда вообще может прийти ответ: из кэша, от DNS провайдера, от публичного сервера, через шифрованный DoH.
61:50
Speaker A
Из этой лесенки следуют две вещи, которые мы уже трогали, но теперь можно сказать их точно. Первая: когда браузер спрашивает через DoH, его запрос едет внутри обычного HTTPS — снаружи он неотличим от любого другого зашифрованного трафика, и ни система, ни провайдер этот вопрос даже не видят,
62:09
Speaker A
не то что подменить. Один и тот же вопрос «какой адрес у сайта?» может быть либо открыт для вмешательства, либо наглухо закрыт — целиком в зависимости от того, кто и как его задал. И вторая, прямое следствие: на одном компьютере одновременно
62:23
Speaker A
живут несколько разных «картин мира». Браузер со своим честным DoH видит настоящий адрес, приложение рядом ходит через системный DNS и получает подмену. Вот и весь секрет мистики «в браузере работает, в приложении нет» — никакой мистики, просто два разных отвечающих.
62:41
Speaker A
Теперь «что приходит в ответ». Ответ DNS — это не просто «вот тебе адрес», у записей есть типы, и два из них надо узнавать в лицо. Запись A отдаёт короткий адрес IPv4, запись AAAA — длинный IPv6.
62:56
Speaker A
То есть у одного имени запросто есть сразу оба адреса — и короткий, и длинный, — а какой из них реально возьмёт ваше устройство, зависит от его настроек и от того, работает ли у вас IPv6 вообще. Плюс уже знакомая история: адресов может прийти несколько, и в разных странах — разные,
63:15
Speaker A
потому что CDN подсовывает ближайший к вам сервер; карта мира на схеме — ровно про это.
63:20
Speaker A
И вот здесь — диагностический сценарий, ради которого этот раздел вообще стоит смотреть до конца. Сайт «то работает, то нет». Классика: утром открывался, вечером нет, у друга открывается, у вас нет. Первый рефлекс — «DPI лютует, пойду переберу пресеты». Не спешите. Очень часто виноват
63:39
Speaker A
вовсе не DPI: просто сегодня DNS выдал вам один адрес, а завтра другой — и один из них живой, а второй мёртвый или заблокированный. Вы будете часами крутить стратегии обхода, а проблема вообще не в обходе — она на уровне «по какому адресу мы сегодня поехали». Поэтому
63:56
Speaker A
правило: прежде чем трогать пресеты, проверьте две простые вещи — какой именно IP выдал DNS сейчас и на какой узел реально ушло подключение. Пять минут проверки экономят вечер перебора.
64:09
Speaker A
Сведём всё в памятку — последняя схема раздела как раз она, светофор из трёх веток. Зелёная: DNS ответил честно, адрес настоящий — дальше в игру вступают IP-доступность и DPI, вот там и живёт zapret. Оранжевая: адрес подменён — заглушка «доступ ограничен» или чужой IP;
64:28
Speaker A
лечится не пресетами, а сменой DNS или его шифрованием, zapret тут вне игры — это мы уже выучили намертво. Красная: пустой ответ или ошибка — имя вообще не превратилось в адрес, «не удаётся получить доступ к сайту», хотя сам сайт из другой сети жив-здоров; лечение то же,
64:46
Speaker A
что у оранжевой. Справа на схеме — уже разгаданный парадокс браузера с DoH против приложения с системным DNS, а внизу — порядок действий при диагностике. Одной строкой на память: DNS отвечает за «какой адрес у имени», DPI и zapret начинаются позже — там, где к этому адресу
65:05
Speaker A
уже идёт трафик. Не смешивайте эти два этажа, и половина «необъяснимых» проблем объяснится сама. Итак, имя превратилось в адрес — честный, проверенный. Но приехать «к серверу» мало: на одном сервере крутится десяток разных служб. Нужно указать, в какую именно дверь стучимся. Это порт — и это следующий раздел.
65:24
Speaker A
Итак, у нас на руках честный IP — мы знаем, к какой машине ехать. Казалось бы, всё: адрес есть, подключайся. Но попробуйте мысленно приехать «к серверу» — и сразу упрётесь в вопрос: а к чему именно на нём? Сервер — это не один сайт-одиночка. На одной и той же
65:41
Speaker A
машине обычно крутится целый набор служб сразу: сам сайт, почтовый сервер, API, админ-панель, может игровой сервер, VPN, сервис обновлений. Адрес у всего этого хозяйства один.
65:53
Speaker A
И если постучаться просто «по адресу», непонятно, кому из жильцов адресован стук. Для этого и придуман порт — номер, который дописывается к адресу и говорит: мне вот в эту конкретную службу. Продолжая нашу почтовую логику: IP — это адрес здания, а порт — конкретная дверь в нём. Здание одно, адрес один, а входов много:
66:14
Speaker A
парадный для посетителей, служебный для сотрудников, ворота для доставки. Захотел на сайт — стучишь в одну дверь; за почтой — в соседнюю, по тому же адресу.
66:24
Speaker A
Тут вы можете справедливо заметить: «я двадцать лет открываю сайты и ни разу никакой порт не набирал». Верно — и это не потому, что его нет, а потому, что программы подставляют его молча. Вводите адрес сайта — браузер сам дописывает порт по умолчанию:
66:39
Speaker A
80 для обычного HTTP, 443 для защищённого HTTPS. Подключаетесь к серверу Minecraft — клиент сам подставит 25565, если вы явно не указали другой. Порт есть в каждом подключении, всегда, — просто по умолчанию он спрятан от глаз. Как лифт в доме:
66:59
Speaker A
вы им пользуетесь ежедневно, но в адресе на конверте его не пишете. Для нашей темы главные двери — вот эти три: TCP 80 -> обычно HTTP. TCP 443 -> обычно HTTPS/TLS. UDP 443 -> часто QUIC И посмотрите внимательно на список — в нём спрятана деталь, о которую спотыкаются почти
67:23
Speaker A
все новички. Там дважды встречается число 443, но это не одна дверь, а две разные. Написано ведь не просто «443», а «TCP 443» и «UDP 443» — и вот эта буквенная приставка не украшение. Сам по себе номер порта — просто число, оно ничего не адресует. Рабочая единица — всегда пара:
67:46
Speaker A
транспортный протокол плюс номер. TCP 443 и UDP 443 — два отдельных входа в здание; да, на человеческом уровне за ними может жить один и тот же сайт (обычный HTTPS в одну дверь, современный QUIC — в соседнюю), но технически это разные виды сетевого обмена, и открываются,
68:06
Speaker A
закрываются и фильтруются эти двери независимо друг от друга. Провайдер может заколотить одну и не тронуть вторую — и, как увидим во второй половине раздела, регулярно так и делает.
68:17
Speaker A
Отсюда сразу практическое следствие для zapret, и это не педантизм, а рабочая необходимость. В пресетах фильтр по порту всегда задаётся с указанием протокола — отдельно правило для TCP-порта, отдельно для UDP-порта. Не потому что автору нравится писать длиннее, а потому что за разными дверями — разный трафик, и приёмы обхода для него нужны разные:
68:39
Speaker A
то, что помогает TLS-соединению на TCP 443, для QUIC на UDP 443 попросту не имеет смысла, и наоборот. Так что возьмите за привычку прямо сейчас: услышали или прочитали «порт 443» — мысленно переспросите «который из двух?». Эта привычка ещё не раз сработает и при чтении пресетов, и при диагностике.
69:02
Speaker A
Теперь уточнение, без которого в пресетах легко запутаться. До сих пор мы говорили «порт» так, будто он один. На самом деле у каждого TCP- или UDP-пакета их два: порт назначения — та самая дверь на сервере, и порт источника — дверь на вашей стороне,
69:18
Speaker A
из которой пакет вышел. И живут они совершенно по-разному. Порт назначения известен заранее и стабилен: веб — это 443, всегда и у всех, иначе браузеры не знали бы, куда стучать. А порт источника — временный: ваша система выдаёт его случайно,
69:34
Speaker A
под конкретное соединение, попользовалась — выбросила. Поэтому когда в обычной речи говорят «подключиться к 443 порту», имеют в виду именно порт назначения, серверную дверь.
69:46
Speaker A
Зачем вообще нужен этот второй, временный номер? А вот зачем — и это красивый механизм. Откройте три вкладки одного сайта. Все три соединения снаружи на одно лицо: тот же IP, та же дверь 443. Как системе понять, какой ответ сервера отдать какой вкладке? Ответ: по порту источника. У каждого
70:06
Speaker A
соединения он свой — скажем, 51873, 51874, 51880, — и полная пара «адрес+порт у вас ↔ адрес+порт у сервера» становится уникальным обратным адресом разговора. По нему ответ безошибочно находит дорогу к нужной вкладке. На схеме это и нарисовано: один пакет с двумя портами и пачка
70:32
Speaker A
соединений к одному 93.184.216.34:443, различимых только временными номерами. Для zapret отсюда прямое следствие. Фильтр «TCP 443» в пресете — это всегда про порт назначения: он один и тот же у всего веб-трафика, по нему трафик и опознаётся. Порт источника в правило не закладывают в принципе — он у каждого соединения свой и заранее непредсказуем; ловить по
71:03
Speaker A
нему — как ловить человека по номеру талончика в очереди: к следующему визиту номер будет другой.
71:09
Speaker A
Пара слов про роутер, раз уж он стоит между вами и интернетом, — он в этой портовой бухгалтерии участвует напрямую. Устройств в квартире много, а внешний адрес у всех один. Роутер выкручивается ведением учёта: запоминает, какой внутренний компьютер с каким временным портом открыл какое
71:27
Speaker A
внешнее соединение, и на лету переписывает адреса туда-обратно. Называется это NAT — преобразование сетевых адресов. Глубже в него сейчас не полезем, из него нам нужна одна мысль: порт — это не просто «номер службы на сервере», это часть адресации каждого конкретного разговора,
71:45
Speaker A
и учитывают её все участники цепочки, включая коробку с антеннами в вашем коридоре. Теперь вернёмся к подписям на дверях — «TCP 443 — обычно HTTPS». Слово «обычно» там стоит не для скромности. Порт — это договорённость, а не закон физики: никто не мешает повесить на 443 что угодно
72:06
Speaker A
другое, и в реальной жизни такое бывает. Порт даёт сильную подсказку о том, что внутри, но не доказательство. Именно поэтому серьёзные системы анализа портом не ограничиваются — они заглядывают глубже, в содержимое первых пакетов. Запомните это «обычно»: из него в следующих разделах вырастет
72:25
Speaker A
весь разговор про DPI, который смотрит не на дверь, а на то, кто в неё входит, — и про более точные признаки в пресетах: протокол седьмого уровня, payload, первые сообщения соединения.
72:37
Speaker A
И финал раздела — самое показательное: что происходит, когда дверь заколачивают. Это не теория, это любимый приём провайдеров, и выглядит он поучительно. Сценарий первый: закрыли только UDP 443 — дверь QUIC. Браузер стучится в неё, не дожидается ответа... и молча,
72:56
Speaker A
без единой жалобы, переходит на соседнюю дверь — обычный HTTPS поверх TCP. Вы в худшем случае заметите лёгкую задержку при первой загрузке. Ни ошибки, ни предупреждения — блокировка есть, а симптомов почти нет. Сценарий второй: закрыли обе двери 443, и TCP тоже. Запасного входа больше
73:17
Speaker A
нет — соединение виснет и умирает с ошибкой «превышено время ожидания». И вот пикантная деталь: сам сервер при этом жив-здоров и на пинг бодро отвечает. Адрес доступен — сайт не открывается. Узнаёте ситуацию? Это третья разгадка в нашу диагностическую копилку: «пингуется,
73:36
Speaker A
но не грузится» — вполне возможно, дело не в DNS и не в IP-блоке, а в закрытой двери-порте.
73:43
Speaker A
На последней схеме раздела всё это собрано вместе: слева таблица NAT в роутере, справа — оба сценария заколоченных дверей. А для пресетов вывод из всего раздела один, и он замыкает круг к слову «фильтр» из начала ролика: порт — это первый и самый дешёвый фильтр. Одно сравнение числа — и основная
74:02
Speaker A
масса чужого трафика отсечена ещё до всяких умных проверок. Дёшево, быстро, но грубо — поэтому за портом в пресетах и идут признаки поточнее. Порт отвечает «в какую дверь стучат», а вот что говорят, войдя в дверь, — это уже про пакеты и их содержимое. О них — следующий раздел.
74:21
Speaker A
Теперь разберём слово «пакет» по-настоящему — потому что дальше вокруг него будет крутиться вся терминология zapret, и от того, насколько верно вы его сейчас почувствуете, зависит, будете вы понимать приёмы обхода или заучивать их наизусть.
74:36
Speaker A
В быту мы говорим: «компьютер отправил запрос», «сайт прислал ответ», «браузер скачал страницу». Звучит так, будто от вас к серверу улетел один большой кусок данных — целиком, как посылка. В сети так почти никогда не бывает. Данные режутся на маленькие единицы передачи — вот они и есть пакеты.
74:57
Speaker A
Представьте, что вам нужно отправить книгу. Отправлять её одним неподъёмным ящиком неудобно и попросту невозможно — почта такого не примет. Вы разбираете её на страницы, раскладываете по конвертам и отправляете пачкой. На каждом конверте — служебная надпись: куда, от кого,
75:15
Speaker A
какая это по счёту страница, чтобы получатель собрал книгу обратно в правильном порядке. В сети идея ровно та же, только вместо бумажных конвертов — байты, заголовки и правила протоколов.
75:28
Speaker A
Но прежде чем лезть внутрь одного конверта, надо увидеть картину целиком — и вот тут бытовая интуиция подводит сильнее всего. Кажется, что у каждой программы своя труба: у браузера свой канал, у мессенджера свой, у игры своя. Ничего подобного. Через сетевую
75:45
Speaker A
карту вашего компьютера идёт один сплошной общий поток пакетов, и в нём вперемешку едет всё сразу: кусок видео с YouTube, сообщение в Telegram, DNS-запрос какой-то фоновой программы, служебный пакет Windows, ход в онлайн-игре. Не аккуратные параллельные ручейки — одна перемешанная река.
76:06
Speaker A
А отдельные соединения в этой реке живут на удивление недолго. Открыли страницу — браузер поднял несколько соединений, за пару секунд выкачал что нужно и тут же их закрыл. То есть «соединение к сайту» — это не труба, висящая всё время,
76:21
Speaker A
пока открыта вкладка; это короткие вспышки обмена, которые вспыхнули и погасли. Зато сама река не пересыхает почти никогда. Даже когда за компьютером «ничего не делают», пакеты идут: мессенджеры короткими служебными пакетиками поддерживают связь с серверами, программы проверяют обновления, системные службы сверяют время и синхронизируют облака.
76:44
Speaker A
Полной тишины в сети практически не бывает — фоновый шум идёт всегда. Оставьте ноутбук в покое на минуту, и он всё равно наговорит с интернетом несколько тысяч пакетов.
76:55
Speaker A
Не верите — посмотрите сами. Вот как выглядят несколько миллисекунд этого потока, если поймать их анализатором вроде Wireshark. Пример учебный, но по форме — ровно то, что вы увидите у себя.
77:08
Speaker A
Адреса тут настоящие, не выдуманные: 74.125 — это Google, 149.154 — Telegram, 8.8.8.8 — публичный DNS Google, 20.x — Microsoft, 162.125 — Dropbox, 155.133 — Steam. И теперь — две вещи, ради которых стоит задержать взгляд на таблице.
77:37
Speaker A
Первая — плотность. Два десятка пакетов от семи разных программ уложились в двадцать четыре тысячных доли секунды. Ни одна миллисекунда почти не пустует. Вы моргнуть не успели — а тут уже произошла вот такая толчея.
77:52
Speaker A
Вторая — кто тут главный шумит. Посмотрите, как часто мелькает видео: очередной его кусок приезжает каждые две-три миллисекунды, и весь остальной трафик протискивается в щели между ними.
78:05
Speaker A
Прикинем масштаб: ролик в 1080p — это примерно 5 мегабит в секунду, то есть около четырёхсот пакетов в секунду на одно только видео. Добавьте мессенджер, облако, игру, фоновые службы — и через обычный домашний компьютер в активный момент идут тысячи пакетов в секунду. Тысячи. Каждую секунду.
78:28
Speaker A
Естественный вопрос: если всё это едет в одной куче — почему ничего не путается? Почему кусок видео не приезжает в окно мессенджера? Ответ мы уже знаем из раздела про порты, просто теперь он заиграет по-новому. У каждого пакета есть адрес и порт источника, адрес и порт назначения. Эта
78:46
Speaker A
четвёрка — уникальная метка разговора. По ней операционная система на лету раскладывает общую реку обратно по руслам: этот пакет — вкладке с видео, этот — мессенджеру, этот — фоновой службе.
78:58
Speaker A
И вот здесь надо сделать сдвиг в понимании слова «соединение», который многое расставит по местам.
79:04
Speaker A
Соединение — это не провод и не труба. Это договорённость: набор пакетов с одинаковой четвёркой адресов и портов, которые обе стороны согласились считать одним разговором. Никакого физического канала под соединение не выделяется. Есть только общий поток — и метки, по которым
79:22
Speaker A
из него выуживают свои пакеты. Соединение живёт не в проводах, а в головах у сторон.
79:27
Speaker A
Теперь поднимите взгляд с вашего компьютера на оборудование провайдера. Там такие домашние реки от тысяч абонентов сливаются в одну — и через DPI идут уже не тысячи пакетов в секунду, а миллионы. Вдумчиво читать каждый физически невозможно: никакого железа не хватит. Значит,
79:45
Speaker A
DPI вынужден экономить — на лету раскладывать океан по соединениям и всерьёз изучать в основном их начала, первые пакеты. Запомните это: не «все пакеты подряд», а первые. Именно там, в начале разговора, лежит всё самое интересное — и именно поэтому
80:01
Speaker A
вся дальнейшая борьба развернётся вокруг первых пакетов соединения. А zapret, заметьте, работает ровно в тех же условиях — только на вашем конце линии. Ему на вход тоже поступает не «сайт» и не «страница», а такая же перемешанная река. И первое,
80:16
Speaker A
что он делает, — быстро выуживает из неё те немногие пакеты, которые вообще стоит трогать, а остальное пропускает не глядя. Держите эту картинку в голове: когда мы говорили про фильтр, профиль и range, они казались абстрактной бюрократией конфига.
80:32
Speaker A
Теперь видно, зачем они на самом деле: трафик приходит сплошным потоком, а не аккуратными подписанными разговорами, и его прежде всего надо просеять. Без этого движок захлебнётся.
80:43
Speaker A
Итак, данные едут пакетами по общей реке. Заглянем теперь внутрь одного пакета — и обнаружим, что он устроен не как простой конверт, а как матрёшка: конверт в конверте. Разберёмся, зачем столько слоёв и кто что читает, потому что на этой матрёшке держатся все будущие приёмы zapret.
81:01
Speaker A
Начнём с грубого, но честного факта. По кабелю, оптике или Wi-Fi не летят «сайты» и «страницы» — по ним бежит последовательность нулей и единиц, закодированных электрическим, световым или радиосигналом. Думать на уровне сигнала человеку неудобно, поэтому мы поднимаемся на ступеньку выше
81:20
Speaker A
и говорим: вот здесь проехала порция данных, оформленная по правилам конкретной сетевой технологии. Эти ступеньки — уровни — и есть слои нашей матрёшки. Пройдём их снаружи внутрь.
81:32
Speaker A
Самый внешний конверт — канальный уровень. В привычном Ethernet данные едут кадрами. Кадр — это ближайший к «железной» отправке конверт, тот, что доставляет данные на один короткий участок: от вашего компьютера до роутера, от роутера до следующего устройства. У него есть
81:48
Speaker A
адрес получателя и адрес отправителя, но — внимание, важное — это не те адреса, о которых мы говорили раньше. Это MAC-адреса, и они живут по другим правилам, чем IP.
82:00
Speaker A
Разница между MAC и IP — из тех, что стоит прочувствовать один раз и навсегда.
82:05
Speaker A
MAC-адрес нужен для одного короткого прыжка — «от меня до соседа по проводу». IP-адрес нужен для всего путешествия — «от меня до сервера на другом конце планеты». И вот следствие, которое поначалу удивляет: пока пакет едет через интернет, его внешний конверт переписывается на каждом переходе.
82:23
Speaker A
Пришёл на роутер — старый MAC-конверт сняли, надели новый, до следующего устройства. И так на каждом узле. А IP-пакет внутри всё это время едет неизменным и невозмутимо несёт своё «откуда» и «куда» через весь маршрут. Представьте эстафету: палочку (IP-пакет) передают от бегуна к бегуну,
82:42
Speaker A
бегуны (участки сети) всё время меняются, а палочка одна и та же от старта до финиша.
82:48
Speaker A
У Ethernet-кадра стоит заметить ещё две детали, обе всплывут позже. Внутри его заголовка, кроме двух MAC-адресов, есть поле EtherType — крохотная бирка «а что у меня внутри»; значение 08 00 в ней означает «дальше лежит IPv4». А в самом хвосте кадра едет FCS — контрольная сумма:
83:10
Speaker A
по ней приёмник замечает, что байты в дороге испортились, и выбрасывает битый кадр. Запомните этот приём с биркой «что внутри» — он повторится на каждом слое матрёшки, это их общий язык.
83:21
Speaker A
[Ethernet-заголовок] - [IP-пакет] - [проверка кадра] И раз уж речь зашла о цветах — вот кодировка, в которой нарисованы все схемы пакетов дальше в ролике, стоит запомнить сразу: Ethernet серый, IP синий, TCP зелёный, UDP фиолетовый, TLS жёлтый, QUIC оранжевый,
83:37
Speaker A
данные приложения белые. Дальше, увидев жёлтый блок, вы уже без подписи будете знать — это TLS.
83:44
Speaker A
Следующий конверт внутри — IP-пакет. Он отвечает за доставку между IP-адресами через весь интернет. В его заголовке — адрес источника, адрес назначения, пометка, что лежит внутри, и несколько служебных полей (к трём самым важным вернёмся в следующей части, они прямо выходят на приёмы обхода). Снаружи Ethernet даже не заглядывает,
84:06
Speaker A
что там за адреса внутри IP: для него весь IP-пакет — просто «груз, который надо докинуть до соседа». Каждый слой честно занимается только своим конвертом.
84:16
Speaker A
Ещё глубже — транспорт: TCP или UDP. Внутри IP-пакета обычно лежит либо TCP-сегмент, либо UDP-датаграмма, и разница между ними принципиальная. У TCP заголовок большой, полей много — порты, номера последовательности, флаги вроде SYN и ACK, размер окна; вся эта машинерия
84:35
Speaker A
нужна, чтобы построить надёжный упорядоченный поток (помните пронумерованные страницы книги? это его работа). У UDP заголовок аскетичный — порт источника, порт назначения, длина, контрольная сумма, и всё. UDP не заморачивается порядком и надёжностью, зато он простой и быстрый.
84:55
Speaker A
И тут пора навести порядок в названиях, иначе в разговорах про zapret будет путаница. В быту всё подряд зовут «пакетами», но строго на каждом уровне — своё слово: на канальном уровне это кадр, на IP-уровне — IP-пакет (или датаграмма), у TCP — сегмент, у UDP — датаграмма,
85:14
Speaker A
у QUIC — QUIC-пакет. Это не занудство ради занудства: когда приём обхода «режет TCP-сегмент», а другой «трогает QUIC-пакет» — это действия на разных слоях матрёшки, и путать их нельзя.
85:26
Speaker A
Соберём картину. Пакет — это матрёшка: снаружи Ethernet-кадр, внутри него IP-пакет, внутри того TCP-сегмент, внутри — данные. У каждого слоя свой заголовок, свой круг обязанностей и своя бирка «что внутри», и ни один слой не лезет в чужие конверты.
85:44
Speaker A
Но у этой матрёшки есть одна особенность, которая всё меняет и которую видно, только если перестать думать про «коробки внутри коробок» и посмотреть, как пакет на самом деле лежит в проводе. А лежит он там не вложенным, а плоским — одной лентой байтов, где заголовки
86:01
Speaker A
просто выстроены друг за другом. Вот с этой ленты и начнём следующую часть — и увидим, как пакет растёт и почему для постороннего наблюдателя матрёшка в какой-то момент перестаёт открываться.
86:13
Speaker A
Мы дошли до второго конверта матрёшки — IP-пакета — и теперь заглянем в его заголовок вплотную. Полей там больше десятка, но новичку достаточно найти глазами три. Не потому что остальные не нужны сети, а потому что именно на этих трёх держится вся дальнейшая тема:
86:30
Speaker A
по ним zapret решает, за что браться, и на них же стоят две из трёх блокировок. Пройдём по очереди.
86:37
Speaker A
Первое — адреса источника и назначения, «откуда» и «куда». Для нас важнее назначение: именно по адресу назначения zapret позже решает — наш это трафик или чужой, стоит ли вообще трогать этот пакет. На этом же поле держится самая грубая блокировка — запрет по IP,
86:55
Speaker A
когда к адресу просто не пропускают (мы про неё уже знаем, что тут zapret бессилен).
87:00
Speaker A
Второе — поле Protocol. Крохотное число, а говорит сразу главное: что за транспорт лежит внутри. 6 — значит дальше TCP, 17 — значит UDP. Это та самая «бирка что внутри», о которой мы говорили в матрёшке, только уже на уровне IP. Программа не гадает — читает
87:19
Speaker A
число. И на него же смотрит zapret, когда в пресете мы отделяем TCP-трафик от UDP: приёмы для них разные, и применять вслепую нельзя.
87:28
Speaker A
Третье — поле TTL (Time To Live, «время жизни»). Это счётчик прыжков: на каждом маршрутизаторе по пути он уменьшается на единицу, а как дойдёт до нуля — пакет выбрасывают, чтобы тот не кружил по сети вечно при ошибке маршрутизации (в IPv6 то же самое зовётся
87:45
Speaker A
Hop Limit). Казалось бы, скучная защитная мелочь — а на ней построен один из главных приёмов обхода: zapret шлёт поддельный пакет с таким крохотным TTL, что его успевает увидеть только близкий DPI у провайдера, а до настоящего сервера подделка не долетает — TTL обнуляется по дороге,
88:04
Speaker A
и пакет тихо гибнет, не запутав сервер. Красиво разберём в следующем видео; пока просто отметьте, что вот из этого невзрачного счётчика вырастет целый трюк.
88:14
Speaker A
Три поля, три прямых выхода на тему. Остальное в заголовке — служебное, сейчас не трогаем.
88:19
Speaker A
Здесь надо остановиться и сказать вслух важнейшую вещь про то, на каком уровне вообще живёт zapret — потому что без неё половина будущих вопросов «а почему он не может вот это» останутся без ответа.
88:32
Speaker A
Посмотрите, с чем мы возимся весь этот раздел: адреса, порты, протокол, поля заголовков, байты пакета. Всё это — уровень пакетов, и ни на сантиметр выше. Zapret живёт именно здесь: он перехватывает поток пакетов (через системную очередь на Linux, через драйвер-перехватчик на
88:50
Speaker A
Windows) и кормится пакетами — только ими. На входе у него не «ютуб» и не «браузер Chrome», а безымянный поток конвертов, разложенных по четвёрке «адрес и порт источника, адрес и порт назначения». Всё, чем он умеет фильтровать, — из той же коробки: IP, порт,
89:07
Speaker A
протокол, содержимое пакета. И это не недоделка, а сама природа инструмента. Отсюда — прямое и очень важное следствие, которое надо усвоить раз и навсегда: zapret не умеет работать «с приложениями». Он в принципе не знает, что такое приложение. Для него не существует ни
89:25
Speaker A
«Discord», ни «Telegram», ни «вот этой конкретной игры» — существуют только пакеты, летящие на такой-то адрес и такой-то порт. Нельзя сказать zapret «дури трафик вот этой программы и не трогай остальные»: у пакета на проводе не написано, какая программа его породила, эта информация осталась
89:42
Speaker A
выше, в операционной системе, и до уровня пакетов просто не доходит. Максимум, что можно, — описать трафик косвенно, через его пакетные приметы: «TCP на порт 443 к вот этим адресам с вот таким содержимым». Если приметы двух программ совпадают — zapret зацепит обе, он их не различает.
90:02
Speaker A
Это, кстати, разгадка частой жалобы новичков: «включил zapret — и вдруг отвалилось какое-то постороннее приложение». Логично: zapret не выбирал это приложение, он его вообще не видел. Он увидел пакеты, подходящие под свой фильтр, и обошёлся с ними по правилу — а что за
90:18
Speaker A
программа их слала, ему неведомо. Держите эту границу в голове весь курс: zapret — инструмент уровня пакетов, а не уровня программ. Всё, что он делает и чего не может, растёт отсюда.
90:29
Speaker A
Раз уж мы разобрали заголовки по косточкам, полезно увидеть, откуда они вообще берутся. Пакет не появляется на свет готовым — он растёт, слой за слоем. Каждый уровень берёт то, что пришло к нему сверху, целиком считает это своим грузом и приклеивает спереди только свой собственный
90:45
Speaker A
заголовок. Снизу вверх это выглядит как одно и то же сообщение, которое обрастает оболочками: Из этой картинки заберём два правила, они пригодятся дальше постоянно. Первое: каждый новый заголовок встаёт перед всем, что уже накопилось, — поэтому исходные данные приложения оказываются в самой глубине, а служебные оболочки нарастают снаружи. Второе:
91:06
Speaker A
ни один уровень не вскрывает чужие оболочки — для Ethernet всё, что внутри, просто «груз до соседа»; для IP содержимое TCP — просто «данные». На том конце всё разматывается в обратном порядке: получатель снимает Ethernet, потом IP, потом TCP — и только в самом конце добирается до данных.
91:25
Speaker A
Вот это «снимаем оболочки по одной» и есть ключ к следующей части: мы посмотрим, как далеко по этой лесенке может пройти посторонний — и где он застревает.
91:34
Speaker A
В прошлой части мы условились: пакет в проводе лежит не матрёшкой, а плоской лентой — заголовки просто выстроены друг за другом слева направо, а данные приложения в самом хвосте. Получатель читает эту ленту слева: снял свой заголовок — передал остаток дальше, снял следующий — снова
91:51
Speaker A
передал остаток. Давайте нарисуем это как лесенку, где каждая ступенька — минус один заголовок. Каждая строка — тот же самый пакет глазами очередного уровня: для Ethernet его «данные» — всё после Ethernet-заголовка, для IP — всё после IP-заголовка, и так до хвоста.
92:08
Speaker A
Никаких коробок внутри коробок физически нет — одна непрерывная лента, просто каждый уровень читает свой кусочек слева и передаёт остаток соседу снизу. Вот эти «остатки» — всё, что правее очередного заголовка, — чуть позже получат собственное имя: payload. Пока просто заметьте их.
92:25
Speaker A
А для HTTP/3 поверх QUIC лента собрана из других слоёв — после IP идёт не TCP, а UDP, за ним QUIC, и только в хвосте данные HTTP/3, — но правило чтения ровно то же: снимай заголовки слева по одному.
92:42
Speaker A
Теперь — мысль, ради которой вся эта лесенка и рисовалась. Она объяснит половину темы блокировок, так что задержимся.
92:51
Speaker A
Провод и любое устройство на пути видят все байты ленты, от первого до последнего: и заголовки, и хвост с данными. Спрятать байты от провода нельзя в принципе — не довезёшь их до сервера, если их не видно. Казалось бы, всё пропало: раз всё видно, что тут скроешь? Но вот ключевая тонкость: «видеть
93:13
Speaker A
байты» и «понимать их» — разные вещи. Байты можно видеть все и при этом не понимать почти ничего.
93:21
Speaker A
Почему? Потому что каждый уровень по-настоящему читает только свой заголовок, а остальное для него — непрозрачный груз. Оборудованию локальной сети, чтобы докинуть кадр соседу, хватает первых четырнадцати байт Ethernet — в IP-адреса оно даже не смотрит. Промежуточному маршрутизатору в интернете, чтобы переслать пакет дальше, достаточно IP-заголовка — что
93:45
Speaker A
там внутри TCP, его не касается. Каждый читает ровно столько, сколько нужно для его работы, и ни байтом больше. И вот закономерность, которую стоит увидеть: чем дальше по лесенке, тем меньше байтов остаётся в остатке — но тем ближе они к настоящему смыслу. Сверху — «куда
94:05
Speaker A
физически доставить», а в самой глубине — «какой сайт, какой запрос, какие именно данные». Отсюда — главный вопрос всей нашей темы. Посторонний наблюдатель на пути — может ли он пройти по лесенке так же глубоко, как настоящий получатель? Ответ: до определённой ступеньки — да,
94:25
Speaker A
а потом упирается в стену. Заголовки Ethernet, IP и TCP открыты по своей природе — сеть физически не смогла бы работать, если бы промежуточные устройства не умели их читать. Старый HTTP открыт целиком. DNS-запрос открыт. Наблюдатель спокойно спускается по этим ступенькам. Но на строке «TLS
94:48
Speaker A
расшифрован» лесенка для него обрывается: этот шаг требует ключей шифрования, а ключи есть только у двоих — у вашего браузера и у настоящего сервера. Посторонний застревает на ступеньку выше. Он видит, что дальше лежат какие-то данные, он знает их точную длину — но прочитать их не может. Перед
95:09
Speaker A
ним запертая дверь: видно, что за ней комната, слышно, что там кто-то есть, а войти нельзя.
95:16
Speaker A
И вот теперь можно дать точное определение тому, о чём весь курс. DPI — это ровно такой наблюдатель. Он стоит на пути (мы уже знаем где — на оборудовании провайдера), физически видит каждый байт и проходит по лесенке настолько глубоко, насколько уровни открыты. Где
95:35
Speaker A
открыто — читает и делает выводы. Где заперто TLS — упирается в стену. Вся дальнейшая борьба идёт именно на этой границе: DPI пытается выжать максимум из того, что до стены, а zapret — сделать так, чтобы прямо перед стеной картина для DPI оказалась не той, на которую он рассчитывал.
95:57
Speaker A
А теперь соберём две половины вместе, потому что вместе они дают неочевидный и очень важный вывод. С одной стороны — TLS прячет содержимое: что за страница, что в запросе, что в ответе.
96:11
Speaker A
С другой — от наблюдателя всё равно не спрятать: сами адреса и порты (иначе пакет не доедет), длины пакетов и их ритм во времени, сам факт соединения, и — то самое больное место — ранние, ещё не зашифрованные части начала соединения, где браузер открытым текстом называет имя сайта.
96:32
Speaker A
Шифрование закрыло комнату, но не сумело спрятать ни адрес дома, ни табличку с именем на входной двери, ни то, сколько народу и когда в эту дверь входит.
96:42
Speaker A
И этого «незашифрованного остатка» хватает на удивление на многое. По одним лишь размерам и ритму пакетов часто видно, чем вы заняты: у видео пакеты крупные и валят плотным потоком, у переписки в мессенджере — редкие и мелкие, у звонка — ровные и частые, как метроном. Добавьте
97:02
Speaker A
порт и адрес — и сервис угадывается с большой вероятностью, ни разу не заглянув внутрь. Вот почему шифрование само по себе не делает трафик невидимым: спрятать можно данные, но не форму и не факт обмена. И вот из этой-то щели — из того, что приметы видны, а сильнее всего
97:22
Speaker A
видно открытое имя сайта в начале, — и вырастет вся работа zapret. Как именно — в разделах про TLS и про сам движок; пока достаточно железно усвоить: фильтрация питается открытыми приметами обмена, и главная из них — имя сайта, которое вы сами отправляете в открытую в первых пакетах.
97:43
Speaker A
Сейчас будет самый технический кусок всего ролика — разбор живого пакета по отдельным байтам. И прежде чем вы увидите первую строчку цифр, я обязана честно ответить на три вопроса, которые иначе будут крутиться в голове и мешать: зачем мы вообще в это лезем, будете ли вы потом
97:52
Speaker A
читать так постоянно, и не придётся ли заучивать шестнадцатеричную абракадабру. Ответы приятные. Зачем. Ровно за одним: один раз своими глазами увидеть, что пакет — это просто числа, а не магия. Весь курс мы говорим «заголовок», «поле», «байты», «TTL», «имя в SNI». Пока это
98:12
Speaker A
слова — они остаются полуабстракцией. А когда вы один раз посмотрите на реальную строку и ткнёте пальцем — «вот эти два байта 01 bb и есть порт 443, вот оно, 443, никакого волшебства» — слова становятся вещами. После этого все дальнейшие приёмы обхода читаются не как заклинания,
98:32
Speaker A
а как понятные действия над понятными числами. Это прививка от страха, и ставится она один раз.
98:38
Speaker A
Будете ли вы так читать постоянно. Нет. Честно — почти никогда. Побайтовый разбор нужен разработчику движка и исследователю, который копает новый DPI. Обычный человек, настраивающий zapret, в hex не живёт — он смотрит на понятные подписи, а сырые байты видит разве что мельком в отладочном логе, когда что-то сломалось. Так что расслабьтесь:
98:59
Speaker A
это не навык, который вам придётся оттачивать, это экскурсия «как оно устроено под капотом». Заглянули, поняли, что там просто числа, — и поехали дальше.
99:08
Speaker A
И — придётся ли учить эту цифровую тарабарщину. Тоже нет, и вот тут особенно важно не создать ложного впечатления. Может показаться, что раз мы сейчас нырнули в hex, то и пресеты zapret — это сплошные загадочные числа. Совсем наоборот. Забегая вперёд: когда мы
99:24
Speaker A
дойдём до настоящих стратегий, вы увидите, что там почти всё написано словами, а не цифрами. Место, куда приём должен резать соединение, задаётся не «байтом номер сорок семь», а человеческими метками вроде sniext — «у поля с именем сайта», host — «у заголовка хоста», midsld — «в середине доменного
99:44
Speaker A
имени». Тип данных тоже словом: tls_client_hello, http_req. Движок сам находит нужное место по имени и сам пересчитывает его в байты — вам этого делать не нужно. Голые шестнадцатеричные числа в пресетах всё же встречаются, но редко и в одной узкой роли — как готовое «тело» поддельного пакета, тот самый
100:05
Speaker A
blob из жёлтой колонки (0x1603030000 и подобное). То есть hex в zapret — это материал для подделок, а не язык чтения трафика. Читать же трафик мы с движком будем в основном по-человечески.
100:20
Speaker A
Так что этот побайтовый раздел — не обязательный. Если в какой-то момент станет тяжело, его можно без всякой потери пролистнуть до раздела про TCP и UDP — всё дальнейшее в курсе понятно и без него. Но кто досмотрит — получит ту самую прививку: увидит, что за словами «заголовок»
100:36
Speaker A
и «поле» стоят обычные числа, лежащие на обычных позициях. Идём медленно и спокойно. Сначала — как эту штуку вообще читать, потому что именно здесь новичок спотыкается чаще всего, и почти всегда об одно и то же место. Слева в дампе идёт узкий столбик: 0000, 0010, 0020, 0030. Первый
100:58
Speaker A
рефлекс — принять его за данные пакета. Это не данные. Это просто номера строк — линейка сбоку.
101:04
Speaker A
Представьте: все байты пакета выложены в одну длинную линейку — байт №0, №1, №2 и так далее, десятки штук подряд. Читать такую бесконечную ленту одной строкой невозможно, поэтому её каждые 16 байт переносят на новую строку, а слева подписывают, с какого по счёту байта эта строка начинается. Почему подписи такие странные — 0010,
101:28
Speaker A
0020? Потому что счёт здесь шестнадцатеричный, и 0x10 в нём — это наша привычная 16, а 0x20 — 32.
101:37
Speaker A
Польза от этой линейки простая: по метке мгновенно находишь нужный байт. Говорят «смотри байт на смещении 0x22» — и сразу ясно, что искать в строке 0020 (которая стартует с 32-го), чуть правее её начала. Это как номера строк в книге: помогают быстро сослаться на нужное место,
101:56
Speaker A
но частью текста не являются. Уберёшь левый столбик — пакет не изменится, просто ориентироваться станет труднее. Итого: слева линейка, справа — сами байты.
102:06
Speaker A
А теперь про сами байты. Каждая пара символов справа — это один байт: 08 — байт, 00 — ещё байт, вместе 08 00 — два байта. Откуда буквы? Оттуда же — из шестнадцатеричности: после 09 идёт не 10, а 0a, 0b, 0c, 0d, 0e, 0f, и только потом 10. Это не текст и не команды — просто компактный способ
102:30
Speaker A
записать число от 0 до 255 всего двумя знаками. Одна пара — одно число — один байт. Вот и весь алфавит, который нужен, чтобы прочитать следующие два примера.
102:41
Speaker A
Здесь стоит на минуту остановиться и ответить на вопрос, который наверняка возник: а почему, собственно, 08 00 — это IPv4? Что в этих цифрах такого «айпишного»? Может, в них зашифрован какой-то смысл?
102:54
Speaker A
Нет. И это первое, что надо понять про числа в пакетах: никакого смысла в самих цифрах нет.
103:00
Speaker A
0800 означает IPv4 ровно по одной причине — потому что так договорились. Есть международный реестр, где каждому типу вложения назначен свой номер: 0800 — IPv4, 86DD — IPv6, 0806 — ARP. Могли бы назначить 0001, могли 1234 — работало бы точно так же, лишь бы все читали один и тот же
103:26
Speaker A
справочник. Это как телефонный код страны: почему у России +7, а не +9? Ни почему. Договорились, записали в таблицу, все ей следуют. Смысл не в числе, а в общем соглашении про число.
103:39
Speaker A
Теперь второй кусок вопроса — при чём тут hex. А ни при чём, и это важно не путать.
103:45
Speaker A
Шестнадцатеричная запись — это просто способ показать байты на экране, а не какая-то особая «сетевая система счисления». В проводе никаких букв 08 и 00 нет — там электрические импульсы, а в памяти компьютера просто числа. Мы записываем их в hex, потому что так удобно: один байт всегда
104:03
Speaker A
ровно две цифры, и границы байтов видны глазом. То же самое значение можно записать десятичным числом 2048 — это будет ровно тот же 0x0800. Пакет от смены записи не изменится ни на бит; изменится только то, как мы это печатаем в дампе. Hex — это очки, а не сам объект.
104:22
Speaker A
И вот теперь — правило, ради которого мы затевали эту врезку. Все числа, которые вы встретите в пакете, делятся на две принципиально разные породы, и различать их полезно всегда.
104:33
Speaker A
Первая порода — числа-величины. Они реально что-то измеряют, и их значение можно посчитать. Длина пакета 00 28 = 40 байт — это честные сорок байт, их можно пересчитать пальцем. TTL = 64 — это счётчик, который правда уменьшается на каждом узле. IP-адрес 5d b8 d8 22 — это четыре числа, из которых складывается адрес.
104:59
Speaker A
Контрольная сумма — результат вычисления. Такие числа вычисляются или измеряются. Вторая порода — числа-ярлыки. Они ничего не измеряют, они просто ссылаются на строчку в общем справочнике. 0800 = «внутри IPv4». 06 = «внутри TCP», 11 = «внутри UDP». Порт 01 bb = 443 = «сюда
105:24
Speaker A
обычно ходит HTTPS». Флаг 02 = SYN. Ни одно из этих чисел не «содержит» протокол внутри себя — оно просто указывает пальцем в таблицу, которую обе стороны выучили заранее. Отсюда, кстати, и знакомая нам оговорка «порт 443 — обычно HTTPS»: 443 — это ярлык-договорённость,
105:45
Speaker A
а не гарантия содержимого; повесить на него что-то другое никто не мешает, просто так не принято.
105:51
Speaker A
Зачем вам это различение? Затем, что оно объясняет всю дальнейшую механику блокировок и обхода одним махом. Смотрите: вся сеть работает на том, что все читают одни и те же таблицы. DPI у провайдера читает те же самые ярлыки, что и ваш браузер, и сервер:
106:07
Speaker A
видит 06 — понимает «TCP», видит 01 bb — понимает «похоже на HTTPS», лезет глубже, ищет имя сайта.
106:16
Speaker A
Он не расшифровывает магию — он сверяется с общим справочником, ровно как мы с вами только что.
106:21
Speaker A
А раз так — становится понятно, откуда вообще берётся возможность обхода. Zapret играет как раз на этом: он не ломает шифрование и не изобретает новых чисел, он подсовывает DPI такие числа и такие куски, что тот, честно сверяясь со справочником,
106:36
Speaker A
приходит к неверному выводу — решает, что перед ним не то, что есть на самом деле, или что имени сайта тут нет вовсе. Обман строится не вопреки правилам чтения, а на самих правилах чтения.
106:47
Speaker A
Именно поэтому мы и потратили время на байты: чтобы, когда в следующем видео пойдут приёмы, вы видели не колдовство, а простую механику — кто на какое число посмотрел и что из этого понял.
106:59
Speaker A
Теперь второй пример — и он покажет две вещи сразу: во-первых, что читаются все пакеты по одному и тому же алгоритму, а во-вторых — самое красивое во всём разборе: как числа вдруг превращаются в слово.
107:11
Speaker A
Вот он целиком. Форма похожа на первый: слева линейка, справа байты. Но обратите внимание — строк уже пять, пакет длиннее. Значит, внутри что-то есть.
107:21
Speaker A
Начало — до боли знакомое. Ethernet: MAC получателя, MAC отправителя, потом ярлык 08 00 — «дальше IPv4». Затем 45 — версия 4, заголовок 20 байт. Всё то же самое, что и в прошлый раз, — и это, между прочим, полдела: вы уже читаете вторую половину пакета
107:38
Speaker A
не глядя в подсказки. Внешние конверты у всех пакетов одинаковые, меняется начинка. Первое отличие — длина. Раньше было 00 28 = 40 байт, теперь 00 39 = 57 байт. Пакет потолстел, и понятно почему: в первом примере внутри был только пустой стук в дверь,
107:58
Speaker A
а тут внутри едет настоящее сообщение. А вот и ключевой байт — тот самый ярлык-указатель. Помните, в первом пакете на месте поля Protocol стояло 06 — «внутри TCP»? Здесь на том же месте стоит 11. Это UDP. Одно число — и вся дальнейшая
108:15
Speaker A
матрёшка меняется: программа теперь знает, что за IP-заголовком лежит не TCP-сегмент с его нумерацией и флагами, а простая UDP-датаграмма. Вот вам живая иллюстрация того, о чём мы говорили: никто ничего не угадывает — читают ярлык и идут по указанному адресу в справочнике.
108:32
Speaker A
Дальше адреса: источник 192.0.2.10 (тот же учебный компьютер), назначение — 8.8.8.8. Узнаёте? Это публичный DNS Google, мы про него говорили в разделе про справочную. Уже по одному адресу можно предположить, что сейчас будет DNS-запрос — и это, кстати, ровно то, что делает DPI: строит догадки по внешним приметам, ещё не заглянув внутрь.
109:01
Speaker A
Теперь UDP-заголовок — и почувствуйте контраст. У TCP заголовок был двадцать байт, набитый номерами и флагами. Здесь — восемь байт, четыре поля, и всё: cf 08 — порт источника (53000, временный), 00 35 — порт назначения. 0x35 = 53. А порт 53 — это, по общей договорённости,
109:24
Speaker A
DNS. Дальше 00 25 — длина (37 байт: восемь на заголовок и двадцать девять на содержимое) и контрольная сумма. Вот и весь UDP. Никакой надёжности, никакой нумерации, никакого рукопожатия — просто «вот тебе датаграмма, лови». Аскетизм в чистом виде.
109:42
Speaker A
И вот мы добрались до дна матрёшки — до DNS-запроса. Тут стоит притормозить: у DNS-сообщения есть жёсткая, всегда одинаковая шапка — ровно 12 байт заголовка, шесть полей по два байта, и только потом идёт сам вопрос. Пройдём эти шесть полей, они короткие.
109:59
Speaker A
Первое поле, байты 1a 2b — это ID, номер запроса, бирка «свяжи ответ с вопросом». Второе, 01 00 — Flags, параметры запроса; здесь это «обычный рекурсивный запрос» (к нему сейчас вернёмся вплотную). Третье, 00 01 — QDCOUNT, сколько вопросов в пакете: один. Дальше идут три счётчика, и все три в запросе нулевые:
110:24
Speaker A
00 00 — ANCOUNT, сколько ответов (ноль — мы же спрашиваем, а не отвечаем); 00 00 — NSCOUNT, записей серверов полномочий (ноль); 00 00 — ARCOUNT, дополнительных записей (ноль).
110:39
Speaker A
Логика прозрачная, если прочесть поля как фразу: «вот мой номер, вот флаги, у меня один вопрос и ноль ответов». Три последних поля — счётчики разных секций ответа, и в запросе они закономерно пусты: отвечать нам пока нечего, мы сами пришли спрашивать.
110:55
Speaker A
В ответе сервера, наоборот, ANCOUNT станет ненулевым — там появятся адреса. То есть по одной этой шапке уже видно, вопрос перед нами или ответ, ещё до чтения содержимого.
111:07
Speaker A
Только теперь, после этих 12 байт, начинается секция вопроса — и в ней имя сайта. Смотрите на байты: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 Читаем. Байт 07 — это не данные, это счётчик:
111:18
Speaker A
«дальше идёт кусок имени длиной семь байт». А следом — те самые семь: 65 78 61 6d 70 6c 65. И если перевести каждый байт в символ по обычной таблице ASCII, получится... example. Буквально. Дальше байт 03 — «следующий кусок длиной три»,
111:40
Speaker A
и три байта 63 6f 6d — com. И финальный 00 — «имя кончилось». Соберите вместе: example.com. Прямо здесь, в проводе, обычными буквами, безо всякого шифрования. Заметьте изящную деталь: точек в записи нет — их роль играют счётчики длины. DNS не пишет «example.com», он пишет «семь букв:
112:04
Speaker A
example, три буквы: com, конец». Точка — это выдумка для человека; сети хватает длин. Поле 01 00 — заглянем в него по битам, оно того стоит. Мы привыкли, что байт — это одно число. Но иногда байт, или пара байт, — это набор отдельных выключателей,
112:21
Speaker A
где каждый бит отвечает за своё «да/нет». Поле Flags в DNS как раз такое: два байта, шестнадцать бит, и почти каждый бит — отдельный флажок. Если развернуть 01 00 в двоичный вид, получится 0000 0001 0000 0000 — из шестнадцати бит поднят ровно один.
112:47
Speaker A
У этого бита есть имя — RD, Recursion Desired, «нужна рекурсия». Это та самая просьба из раздела про справочную: «не отсылай меня искать по цепочке самому — сходи и узнай за меня всё до конца». Все остальные тумблеры лежат в нуле, и каждый ноль тоже осмысленный. Бит QR
113:08
Speaker A
равен нулю — значит это запрос, а не ответ. Opcode нулевой — обычный запрос имени, а не служебная операция. AA (авторитетность ответа) в запросе неактуален и потому ноль. TC — сообщение не обрезано. RA (доступна ли рекурсия) — это сервер скажет уже в ответе, в запросе ноль.
113:29
Speaker A
RCODE, код ошибки, — ноль, ошибок нет. И только RD поднят в единицу. Самый показательный тут — бит QR. Ноль значит «вопрос». Когда 8.8.8.8 пришлёт ответ, он поставит этот бит в единицу, а заодно поднимет RA («да, рекурсию сделал») — и
113:50
Speaker A
байты флагов станут другими, 81 80 вместо 01 00. То есть по одному этому биту машина мгновенно отличает вопрос от ответа, даже не читая остального. Аккуратно, дёшево, однозначно.
114:05
Speaker A
И вот тут — мостик к главной теме, который я не могу не протянуть. Тот же приём с битом-тумблером есть и у TCP: флаг SYN — это единственный поднятый бит, а несёт он целый смысл «хочу открыть соединение» (его байты, 50 02, мы разберём в первом пакете чуть ниже).
114:24
Speaker A
Так вот, добрая половина всех приёмов zapret работает именно на уровне таких битов-флажков, где один поднятый или сброшенный тумблер заставляет DPI и настоящий сервер понять пакет по-разному. Механизм разберём подробно в следующем видео; но теперь, увидев, что флаги — это просто ряды осмысленных «да/нет», вы будете смотреть на те приёмы не как
114:47
Speaker A
на магию, а как на переключение конкретных, понятных тумблеров. Теперь сделаем паузу — она важнее самого разбора. Отойдите на шаг и посмотрите, что сейчас произошло. Для человека это просто «компьютер спросил DNS про example.com» — одна фраза. А для программы это лестница из чисел, где каждая ступень указывает на следующую:
115:11
Speaker A
IPv4 сказал «внутри UDP» (ярлык 11), UDP сказал «порт 53 и вот содержимое» (ярлык 00 35), а DNS внутри сказал «вопрос про имя, вот его куски по длинам». Никто ничего не додумывал.
115:27
Speaker A
Слой за слоем, ярлык за ярлыком — из голых чисел вырастает понятный смысл. И вот теперь — вывод, ради которого стоило лезть в эти байты. Мы весь курс повторяем как заклинание: «имя сайта едет открытым текстом», «DPI видит имя». Вы это слышали — а теперь увидели своими
115:47
Speaker A
глазами. Вот оно, имя, лежит в пакете обычными ASCII-буквами. Никакой расшифровки не нужно — ни вам, ни провайдеру, ни DPI: достаточно уметь считать байты по счётчикам длины. И заметьте, кто это имя туда положил — вы сами. Точнее, ваш компьютер, добровольно,
116:06
Speaker A
чтобы получить адрес. Другого способа спросить попросту нет. Вот вам, кстати, в живом виде и разгадка блокировки по DNS из третьей части: если этот вопрос летит открытым и его читает кто угодно по дороге — то ответить на него подложным адресом
116:22
Speaker A
ничего не стоит. Мы это разбирали на словах — теперь вы видите байты, которые это позволяют.
116:28
Speaker A
И заодно понятно, что чинит DoH: он прячет ровно эти байты внутрь шифрованного HTTPS-соединения, и наблюдатель на пути больше не видит ни example, ни com — только очередной непрозрачный поток.
116:41
Speaker A
Мы уже несколько раз упомянули «первый пример» — тот самый TCP SYN, с длиной которого сравнивали DNS-пакет. Пора разобрать и его; тем более что после DNS он покажется совсем простым — это самый пустой пакет, какой вообще бывает. Когда браузер подключается к сайту по HTTPS,
117:00
Speaker A
он не сразу шлёт запрос: сначала надо установить TCP-соединение, и самый первый пакет этого рукопожатия и есть SYN, «давай соединимся», о котором мы говорили в разделе про TCP. Данных внутри — ноль, только служебные заголовки. Идеальный случай, чтобы увидеть матрёшку без начинки, — пройдём его слева направо тем же движением пальца по строке.
117:23
Speaker A
Внешний конверт — Ethernet. Первые шесть байт 02 00 00 00 00 02 — MAC получателя, следующие шесть 02 00 00 00 00 01 — MAC отправителя; здесь они учебные, нарочно простые. А дальше уже родной ярлык 08 00 — «внутри IPv4». Узнаём не глядя.
117:43
Speaker A
Слой глубже — IPv4. Открывается байтом 45: четвёрка — версия протокола, пятёрка кодирует длину заголовка (20 байт). Следом 00 28 — величина: 0x28 = 40, полная длина IP-пакета. И вот оно, обещанное сравнение: сорок байт целиком уходят на два заголовка, 20 на IP и 20 на TCP,
118:12
Speaker A
а на данные не остаётся ничего. Ровно поэтому DNS-пакет был толще (57 байт): там внутри ехал вопрос, а тут — пустой стук в дверь. Несколько служебных полей — 12 34 идентификатор, 40 00 флаги, 40 тот самый TTL (64) — сейчас пропустим. А ключевой ярлык не пропустим: 06,
118:36
Speaker A
«внутри TCP». Стой здесь 11 — был бы UDP, как в DNS-примере. Дальше контрольная сумма 30 b7 и два адреса: источник c0 00 02 0a = 192.0.2.10, назначение 5d b8 d8 22 = 93.184.216.34. Переводить в уме не нужно — важен принцип: адрес это не «example.com», а ровно четыре байта.
119:16
Speaker A
Самое дно — TCP. Первые два байта c9 3a — порт источника (51514, тот самый временный номер, что система выдала под это соединение). Следующие 01 bb — порт назначения, и вот оно, знакомое 0x01bb = 443. Так порт 443 и выглядит в проводе: не текст «443», а два байта. Дальше 01
119:46
Speaker A
02 03 04 — номер последовательности, 00 00 00 00 — номер подтверждения, здесь нулевой: подтверждать пока нечего, соединение только открывается. И смысловой аккорд — 50 02: байт 50 говорит, что TCP-заголовок занимает 20 байт, а 02 — флаг SYN, тот самый бит-тумблер «хочу открыть соединение»,
120:14
Speaker A
родной брат по механике тех DNS-флажков, что мы только что разбирали по битам. Хвост fa f0 ee 10 00 00 — окно, контрольная сумма и указатель срочности, для нуля их можно не трогать.
120:30
Speaker A
Соберём вывод. Всё, что тут есть, — «клиент стучится на порт 443, хочет начать TCP-соединение». Ни имени сайта, ни ClientHello, ни строки Host — данные пойдут позже, отдельными пакетами. Поэтому если DPI или zapret смотрят именно на этот SYN, они видят
120:51
Speaker A
только сам факт попытки соединиться — и ждут следующих пакетов, где и поедет всё интересное.
120:57
Speaker A
Два прошлых пакета были без «начинки»: у SYN данных ноль, у DNS-запроса — служебный вопрос. Но мы весь раздел твердим про «данные приложения» в самой глубине матрёшки. Пора наконец на них посмотреть — и лучший случай для первого знакомства — старый добрый HTTP без шифрования.
121:16
Speaker A
Там нет ни одного секрета, и это делает его идеальным учебным материалом. Вот как выглядит простейший запрос страницы в байтах: 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a, а следом 48 6f 73 74 3a 20 65 78 61 6d 70 6c 65 2e 63 6f 6d 0d 0a
121:57
Speaker A
0d 0a. На вид — очередная строка чисел. Но давайте прочитаем их не как числа, а как буквы, по обычной таблице ASCII — той же, по которой мы вытащили example из DNS.
122:09
Speaker A
Первые три байта 47 45 54 — это G, E, T. GET. Дальше 20 — пробел, 2f — косая черта /, снова пробел, и 48 54 54 50 2f 31 2e 31 складывается в HTTP/1.1.
122:34
Speaker A
Пара 0d 0a — это перевод строки (нажатие Enter, если угодно). А вторая строка читается как Host: , и за ней — 65 78 61 6d 70 6c 65 2e 63 6f 6d, то есть example.com. Соберите всё вместе, и байты превращаются в две простые человеческие строчки: GET / HTTP/1.1 и Host: example.com.
123:09
Speaker A
Вот оно, дно матрёшки, в самом честном виде. Никакой расшифровки не потребовалось — байты буквально складываются в читаемые слова: метод GET, путь /, и заголовок Host с именем сайта прямо в открытую. И тут надо ясно сказать, что это значит для нашей темы: DPI читает эти буквы
123:29
Speaker A
ровно так же легко, как вы сейчас. По такому трафику блокировать по имени — проще некуда: имя лежит открытым текстом, бери и сравнивай со списком. Именно поэтому — не только ради безопасности, но и ровно поэтому — современный веб спрятал всё это внутрь TLS. Посмотрим,
123:48
Speaker A
что происходит с теми же данными, когда сайт работает по HTTPS. Важно понять: сам запрос никуда не делся и не изменился по смыслу.
123:57
Speaker A
Браузер по-прежнему готовит те же GET / HTTP/1.1 и Host: example.com. Но перед отправкой в сеть TLS шифрует эти байты и заворачивает их в свою единицу передачи — запись (по-английски record). У записи есть маленький открытый заголовок из пяти байт, а дальше — шифртекст. Вот тот же запрос глазами наблюдателя на пути.
124:23
Speaker A
Заголовок записи: 17 03 03 00 36. Разберём по нашему же методу «ярлыки и величины». Байт 17 — ярлык: он означает «внутри — данные приложения» (не рукопожатие, не служебное сообщение, а полезная нагрузка). 03 03 — метка версии TLS, тут снова знакомая нам странность: написано «1.2»
124:51
Speaker A
для совместимости со старым оборудованием, хотя соединение на самом деле новее. А 00 36 — это уже величина: 0x36 = 54 байта шифртекста дальше. Пять байт открыты — их видит кто угодно.
125:08
Speaker A
А вот сам шифртекст: d4 8f 3a c2 91 5e 7b 0a ... — и так далее, 54 байта. Попробуйте прочитать их как буквы, тем же приёмом, что сработал с HTTP. Не выйдет: получается Ô·:·^{·... — бессмысленная каша символов. И это не осечка разбора, а точное требование к шифрованию.
125:35
Speaker A
Здесь у внимательного зрителя обязан возникнуть вопрос: неужели во всех 54 байтах не проступит ни одной буквы имени? Ведь исходный-то текст мы знаем. Ответ: не проступит — и вот почему. Хорошее шифрование по определению делает результат неотличимым от случайного шума. Все значения байт от 00 до ff встречаются примерно поровну, никаких повторов,
126:01
Speaker A
обрывков слов или узоров исходного текста не остаётся. Больше того: отправьте один и тот же запрос дважды — получите два совершенно разных шифртекста. Поэтому DPI не может «подсмотреть хоть кусочек»: внутри просто не за что зацепиться, там нет ни единой закономерности.
126:20
Speaker A
Кстати, обратите внимание на арифметику, она поучительна: исходных данных было 37 байт, а шифртекста получилось 54. Шифрование не только не сжало — оно добавило 17 байт. Это криптографический тег проверки целостности: он позволяет получателю убедиться, что сообщение не подменили по дороге. То есть TLS не просто
126:43
Speaker A
прячет содержимое — он ещё и подписывает его, и за это платит небольшим привесом. Чтобы не оставаться на учебных примерах, посмотрим, как всё это выглядит в настоящем анализаторе. Перед нами — имитация окна Wireshark с деревом разбора первых двух кадров реального
127:00
Speaker A
TLS-соединения. И это дерево стоит прочитать по-настоящему внимательно, потому что здесь, в этих строчках, буквально нарисовано, где проходит линия фронта всей нашей темы.
127:11
Speaker A
Разберёмся, как вообще устроено это дерево. Wireshark показывает пакет не строкой байт, а раскрывающимися ветками — по нашей же матрёшке, слой за слоем. Верхние ветки (Ethernet, IP) он сворачивает как очевидные, а раскрывает самое интересное — Transport Layer Security. Каждый отступ вправо — это шаг вглубь матрёшки:
127:33
Speaker A
запись TLS → внутри неё Handshake → внутри него конкретные поля. То самое «дерево-диссект», о котором мы говорили в самом начале ролика, — вот как оно выглядит вживую.
127:44
Speaker A
FRAME 1 — ClientHello, первое слово клиента. Смотрим по веткам сверху вниз. Строка Source: 192.168.1.50 -> Destination: 93.184.216.34 — это адреса из IP-заголовка: наш компьютер стучится к серверу. Protocol: TLSv1.3 — Wireshark опознал, что внутри едет TLS. Дальше раскрывается сама запись: Handshake Protocol:
128:18
Speaker A
Client Hello — то есть это ещё не данные, а начало рукопожатия, представление клиента. А вот теперь три ветки, ради которых стоило открывать это окно. Version: TLS 1.2 (0x0303) — и рядом честная пометка «для обратной совместимости». Помните наши байты 03 03 в заголовке записи? Вот они же в дереве. Клиент притворяется, что он версии 1.2,
128:44
Speaker A
хотя на деле умеет 1.3, — чтобы не спугнуть старое оборудование по дороге. Реальную версию он назовёт ниже, в отдельном расширении. Дальше Cipher Suites — список шифров, которые клиент умеет («вот чем я готов шифровать, выбирай, сервер»). И — кульминация всего
129:00
Speaker A
кадра — Extension: server_name (SNI: example.com), с подписью-стрелкой «виден запрашиваемый сайт!». Вот на этой строке и надо замереть. Мы весь раздел шли к ней. Соединение — «защищённое», TLS, HTTPS, замочек в браузере. А имя сайта example.com лежит открытым текстом, и Wireshark
129:23
Speaker A
прочитал его безо всяких ключей — просто взял из байтов, как мы читали example из DNS. Почему так вышло — глубокий вопрос (сервер должен узнать, какой из размещённых у него сайтов вы просите, ещё до того, как предъявит сертификат), и весь этот парадокс мы подробно разберём в
129:40
Speaker A
разделе про TLS. Пока зафиксируйте факт: в начале TLS-рукопожатия имя сайта не зашифровано. Это не дыра и не ошибка — так устроен протокол. И ровно это делает SNI главной мишенью DPI.
129:53
Speaker A
FRAME 2 — ответ сервера. Server Hello — сервер выбрал из предложенного списка конкретный шифр (Cipher Suite: TLS_AES_256_GCM_SHA384), затем Change Cipher Spec — сигнал «всё, дальше переходим на шифрование». После этого кадра занавес падает: всё последующее содержимое — уже шифртекст.
130:17
Speaker A
И тут — честное уточнение, которое отличает добросовестный ролик от красивой картинки. В настоящем TLS 1.3 занавес падает очень рано: почти всё, что сервер говорит после Server Hello (включая его сертификат с именем сайта!), уже зашифровано, и наблюдатель на пути этого не увидит. Наш кадр показывает Server Hello упрощённо-раскрытым — как
130:39
Speaker A
учебную схему. Запомните правильную картину: единственное по-настоящему щедрое на открытую информацию место во всём TLS-обмене — это ClientHello, самый первый пакет от клиента.
130:51
Speaker A
Там открыто и имя сайта в SNI, и список шифров, и настоящая версия, и даже то, какой протокол поедет внутри (расширение ALPN — h2 или http/1.1). Дальше почти всё закрывается.
131:05
Speaker A
Отсюда — вывод, который и переносит нас к финалу раздела. У DPI есть, по сути, одно богатое окно, чтобы опознать сайт: тот самый первый ClientHello. Не «всё соединение», а один пакет в его начале. Именно поэтому вся дальнейшая борьба сожмётся в такую узкую
131:21
Speaker A
точку — и именно поэтому zapret возится с первыми пакетами соединения, а не со всем потоком. Если испортить DPI разбор этого пакета — дальше портить уже нечего, окно закрылось само.
131:33
Speaker A
Вернёмся к учебному примеру с 54 байтами и подведём под ним черту: что именно HTTPS прячет, а что — нет. Прячет он содержимое: исходные 37 байт запроса зашифрованы, и в получившихся 54 байтах не найти ни GET, ни Host, ни имени сайта — там,
131:53
Speaker A
как мы видели, бессмысленная каша. А вот пять байт заголовка записи остаются открытыми всегда: наблюдатель читает байт 17 («идут данные приложения») и длину — то есть видит, что данные пошли, сколько их, в какую сторону и как часто. Короче: DPI посреди
132:10
Speaker A
HTTPS-соединения по-прежнему видит факт, объём, направление и ритм обмена — но не его смысл. Тут у внимательного зрителя должен щёлкнуть вопрос, и хорошо, если он щёлкнул: а если всё-таки прочитать эти 54 байта как текст — тем же приёмом, что сработал с открытым HTTP, — неужели ни одной буквы не проступит? Мы же знаем,
132:33
Speaker A
что внутри example.com. Ответ: ни одной — и это не осечка, а прямое требование к шифру. Хорошее шифрование по определению делает результат неотличимым от случайного шума. Давайте это прочувствуем на цифрах: если взять сто тысяч по-настоящему случайных байт, каждое из 256
132:54
Speaker A
возможных значений встретится примерно по 390 раз, и ни одно заметно не выделится — ровный фон, без пиков. Шифртекст TLS выглядит точно так же: все значения примерно поровну, никаких повторов, обрывков слов или узоров исходного текста. Больше того — отправьте один и тот же запрос дважды,
133:15
Speaker A
и получите два совершенно разных шифртекста. Поэтому DPI не может «подсмотреть хоть кусочек»: внутри просто нет ни закономерности, ни зацепки, не за что ухватиться в принципе.
133:27
Speaker A
И заметьте попутно любопытную арифметику: было 37 байт, стало 54 — шифрование не сжало, а добавило 17 байт. Это не потеря места, а плата за доверие: криптографический тег, которым получатель проверяет, что сообщение не подменили по дороге. TLS не просто прячет содержимое — он его ещё и
133:47
Speaker A
запечатывает печатью, которую нельзя подделать. За такую печать и доплачиваем этими байтами. Вывод из всего этого один, и он определяет всю дальнейшую стратегию блокировок. Раз середина соединения наглухо закрыта и читать там нечего — самое ценное место для наблюдателя не там,
134:05
Speaker A
а в начале: в рукопожатии, где ещё до включения шифра открыто лежит ClientHello с именем сайта в SNI. Мы это уже видели в дереве Wireshark; подробно же разберём в разделе про HTTP, TLS и QUIC. Пока запомните расстановку сил: весь HTTPS-обмен закрыт,
134:24
Speaker A
кроме короткого светлого окна в самом начале — и вся борьба идёт за это окно.
134:29
Speaker A
Соберём всё, что мы разобрали по байтам, в один кадр — он показывает один и тот же запрос глазами наблюдателя на четырёх этапах: Пробегитесь по нему сверху вниз — это вся суть раздела на одной картинке.
134:41
Speaker A
Этап 1, DNS: имя example.com едет открытым, разложенное по слогам-меткам (07 example 03 com), — читается насквозь.
134:52
Speaker A
Этап 2, открытый HTTP: байты прямо складываются в GET и Host: example.com, видно всё. Этап 3, середина HTTPS: от записи открыты только 5 байт заголовка 17 03 03 00 36 (тип и длина), а тело — серый шум, который как текст читается бессмыслицей.
135:15
Speaker A
Этап 4, TLS ClientHello: вот оно, единственное светлое окно — имя в server_name лежит открытым (сюда и смотрит DPI), а всё, что идёт следом (Server Hello, сертификат, данные), в TLS 1.3 уже зашифровано. Отсюда и вывод внизу кадра: открыто только имя в самом первом пакете — вся борьба идёт за него.
135:38
Speaker A
Теперь, держа эту карту в голове, выстроим те же пакеты по времени — как одну живую загрузку страницы.
135:45
Speaker A
Мы разобрали три пакета порознь — SYN, DNS, TLS-запись. Но они не случайные: это кусочки одной истории — загрузки страницы https://example.com. Просто в ролике мы шли не по порядку жизни. Выстроим их теперь по времени — и всё встанет на места.
136:04
Speaker A
Сначала — DNS, и это надо понять правильно. DNS не часть TCP и не «начало» соединения с сайтом. Это отдельный обмен, целиком проходящий ещё до всякого TCP, и с другой машиной. Устройство шлёт короткий UDP-пакет с вопросом «какой IP у example.com», но не сайту,
136:24
Speaker A
а DNS-серверу — справочнику адресов (это ровно наш второй учебный пакет). Тот отвечает 93.184.216.34. На этом DNS закончился: соединения с сайтом ещё нет вообще, устройство лишь узнало адрес.
136:43
Speaker A
Только теперь, с адресом на руках, начинается TCP — новое, отдельное соединение и уже с самим веб-сервером 93.184.216.34, а не со справочником. На этот адрес уходит наш первый учебный пакет: SYN на порт 443. Сервер отвечает SYN-ACK, клиент подтверждает ACK — трёхшаговое рукопожатие
137:10
Speaker A
TCP завершено. Канал есть, но данных сайта в нём ещё ноль: чистая техническая подготовка. Дальше — TLS ClientHello, то самое раннее сообщение с открытым именем сайта в SNI. Стороны обмениваются им и ответом сервера, договариваются о шифре — и с этого мига канал по-настоящему закрыт.
137:31
Speaker A
И только теперь, внутри закрытого канала, уезжает настоящий запрос страницы — по смыслу тот самый GET / HTTP/1.1, но упакованный в запись TLS: пять открытых байт, дальше шифр. А ответ с HTML приходит не одним куском, а десятками сегментов подряд, и браузер склеивает их в целую страницу.
137:54
Speaker A
Вот эти девять шагов — и есть всё, что стоит за одним нажатием Enter. Причём это скелет для крохотного сайта. Реальная страница тащит картинки, стили, скрипты, шрифты, рекламу, видео; браузер открывает пачку соединений к разным серверам, часть — по QUIC вместо TCP. За одним Enter встают не «запрос и ответ», а сотни, на тяжёлых сайтах — тысячи
138:19
Speaker A
пакетов. Оборудование на пути видит каждый — но самые лакомые для DPI именно первые: DNS-вопрос, SYN и ClientHello, потому что в них адреса, порты и имя сайта видны ещё до того, как всё закрылось шифром. Запомните это окончательно: борьба идёт за начало, не за объём.
138:39
Speaker A
И эти схемы — таймлайн, матрёшка, лесенки — не нужно зубрить как перед экзаменом. Они все служат одной спокойной мысли, ради которой и затевался весь раздел: данные в сети почти всегда идут вложенными слоями, и каждый слой добавляет снаружи свою служебную обёртку, а внутрь кладёт данные
138:59
Speaker A
следующего. Всё, что мы делали, — разглядывали эту матрёшку с разных сторон. И вот теперь, держа её в голове, мы можем дать точное имя тому, что лежит внутри каждой обёртки. Это имя — payload.
139:12
Speaker A
Теперь — последнее слово раздела, payload, и оно ставит точку в матрёшке. Payload — это «полезная нагрузка». Но полезная относительно какого уровня? Для Ethernet-кадра payload — весь IP-пакет. Для IP-пакета — TCP-сегмент. Для TCP-сегмента — байты TLS. Для TLS — зашифрованные данные
139:33
Speaker A
приложения. То есть нельзя раз и навсегда сказать «payload — это вот это»: одна и та же скобка «всё, что правее заголовка» прыгает по ленте в зависимости от того, чьими глазами смотришь.
139:45
Speaker A
И вот тут — важный поворот именно для zapret2, о котором мы уже мельком говорили на карточке.
139:51
Speaker A
В доках движка payload — это не просто «байты после заголовка». Это содержимое пакета плюс распознанный тип того, что внутри. Zapret не таращится на «байты вообще» — он старается понять: это TLS ClientHello? QUIC Initial? HTTP-запрос? Соединение может быть TLS,
140:10
Speaker A
а конкретный интересующий payload — именно ClientHello в нём. Это возвращает нас к самому началу ролика: помните, я обещал, что payload в zapret — это «распознанный тип данных», а не сырьё? Вот теперь, пройдя через матрёшку и hex, вы понимаете, почему:
140:26
Speaker A
чтобы применить приём к нужному месту, движку мало видеть байты — ему надо знать, что это за байты.
140:32
Speaker A
Осталось соединить payload с тем, с чего раздел начинался: данные не идут одним куском. Один запрос приложения не обязан совпадать с одним пакетом.
140:41
Speaker A
Браузер отдаёт TCP поток байтов, а TCP уже сам решает, как порезать его на сегменты: иногда логический кусок влезает в один сегмент, иногда делится на несколько.
140:53
Speaker A
Поэтому «первый пакет» не всегда значит «весь запрос» — это значит «первая сетевая единица, которую мы увидели на своём уровне». (У UDP иначе: там границы датаграммы обычно сохраняются, но надёжность и порядок, если нужны, протокол вроде QUIC строит уже сам поверх.)
141:09
Speaker A
Почему вообще режут? Есть MTU — максимальный размер, влезающий в один пакет на участке сети; в Ethernet это около 1500 байт на IP-пакет. Не влезло — дроби. Пощупаем на живом примере, и числа тут красивые. Сервер отдаёт картинку 90 килобайт. При MTU 1500 за вычетом 20 байт IP- и
141:30
Speaker A
20 байт TCP-заголовка на данные в пакете остаётся 1460 байт. Девяносто килобайт — это 92160 байт, значит картинка приедет примерно 64 сегментами, и каждый повезёт свои ~54 байта служебных заголовков (Ethernet+IP+TCP). Браузер этой нарезки не видит вообще: принимающий TCP по номерам последовательности склеит сегменты обратно в сплошной поток,
141:58
Speaker A
и картинка появится целой. Резать и склеивать — штатная, ежесекундная работа сети, не экзотика. И вот теперь — кульминация всего раздела, ради которой он и писался. Есть три похожих слова, и различать их критически важно. Сегментация TCP — поток режется на сегменты; это штатная
142:18
Speaker A
автоматика. IP-фрагментация — IP-датаграмму дробят, чтобы пролезть в участок с меньшим MTU; тоже автоматика, никто не просит. А split в стратегиях zapret — совсем другое: это осознанный приём. Данные режут не «как получится», а в специально выбранной точке.
142:37
Speaker A
Вникните, в чём фокус, — это сердце всей темы обхода. Представьте: имя сайта в SNI — example.com. Приём режет поток ровно так, чтобы это имя попало на границу двух сегментов: скажем, exam в конце одного пакета, ple.com в начале следующего. Что происходит дальше? Настоящий сервер по номерам последовательности TCP
142:59
Speaker A
спокойно склеивает поток обратно и видит целое example.com — для него ничего не изменилось. А DPI, который смотрит на пакеты по отдельности и экономит силы, видит в одном пакете exam, в другом ple.com — и не узнаёт имя из чёрного списка. Оно проскользнуло, разорванное по
143:18
Speaker A
живому. В пресетах zapret2 этот приём так и называется — multisplit, и слово «split» там всегда значит намеренную нарезку ради обхода, а не обычное деление, которым TCP занят и без нас.
143:30
Speaker A
Вот теперь понятно, зачем был весь этот раздел. Чтобы split не выглядел магией. Он стоит ровно на том, что мы разбирали по кирпичику: данные идут кусками (пакеты), у кусков есть порядковые номера (sequence из SYN-разбора), имя сайта лежит открытым в начале (ClientHello), а DPI ленив и
143:49
Speaker A
смотрит на первые пакеты по отдельности. Убери любой кирпич — приём не собрать. Соберём всю часть в одну мысль на вынос. DPI не видит «красивую страницу» — он видит сетевой обмен: заголовки, направления, порты, размеры, первые сообщения протоколов. И zapret работает
144:07
Speaker A
не с «сайтом», а с выбранными пакетами и байтами внутри них: C-часть разбирает пришедший пакет в дерево-диссект (то самое, из начала ролика и из окна Wireshark), а Lua-логика уже действует над разобранным. Поэтому когда дальше пойдут слова payload, range, split,
144:24
Speaker A
fake, disorder, TTL, SYN, ACK — они будут относиться не к «сайту вообще», а к конкретным частям конкретного обмена, которые вы теперь умеете видеть своими глазами.
144:35
Speaker A
Не нужно заучивать приёмы — рано. Нужно унести одну привычку зрения: интернет-обмен состоит из вложенных единиц передачи. Биты в проводе → кадры → IP-пакеты → TCP-сегменты или UDP-датаграммы → TLS, QUIC, HTTP выше. DPI читает приметы этого обмена; zapret меняет выбранные его части. Всё остальное в курсе — подробности этих двух фраз.
145:02
Speaker A
Мы построили сцену — в следующем видео на неё выйдут актёры. До сих пор мы разбирали, как устроен обмен; дальше пойдёт, как в него вмешиваться — те самые приёмы, ради которых всё и затевалось.
145:14
Speaker A
Мы разберём, что такое DPI изнутри: как именно он вылавливает имя в ClientHello и почему одни фильтры «помнят» соединение, а другие смотрят на каждый пакет по отдельности (и как эта разница нам на руку). Возьмём приёмы по одному и увидим их механику вживую:
145:31
Speaker A
fake — как подсунуть DPI поддельный пакет-обманку, который до настоящего сервера не долетает (помните трюк с крохотным TTL?); split и disorder — как разрезать и перемешать начало соединения так, чтобы сервер собрал, а фильтр — нет; игры с флагами SYN, RST, ACK. Разберём, почему имя вообще
145:50
Speaker A
торчит наружу в TLS и что меняет QUIC. А под конец — научимся читать пресет как предложение: filter → range → direction → profile, слева направо, ровно как обещали в самом начале. И выстроим порядок диагностики, чтобы не гадать: DNS → IP → порт → DPI.
146:11
Speaker A
Другими словами: этот ролик был про то, что происходит в сети. Следующий — про то, как zapret это меняет. Всё, что казалось загадочными буквами в чужом конфиге, начнёт читаться как понятный текст.
146:23
Speaker A
Спасибо, что досмотрели до конца — это была самая тяжёлая, фундаментная часть. Дальше будет заметно интереснее: пойдёт живая механика обхода. Увидимся в следующем видео.
Topics:zapretобход блокировокDPITCPUDPHTTPTLSQUICсетевые протоколыинтернет

Answers

Frequently Asked Questions

Что такое zapret и как он работает?

Zapret — это инженерная система блокировок, которая анализирует трафик по разным признакам (протоколы, порты, IP, DNS) и применяет фильтры для ограничения доступа к сервисам.

Почему один пресет zapret может открывать YouTube, но блокировать Discord?

Потому что разные сервисы используют разные протоколы, порты и признаки трафика, и блокировка зависит от того, как zapret распознаёт эти особенности.

Какие основные методы обхода блокировок используются в zapret?

Основные методы — fake (поддельные пакеты), split (разрезание сообщений), disorder (перемешивание порядка) и fooling (обман анализатора), которые вводят в заблуждение DPI, не мешая работе настоящего сервера.

Get More with the Söz AI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play
Or transcribe another YouTube video here →

Free tools: TXT to SRT · SRT Validator · Merge SRT · Subtitle to Text · All tools

Related Transcripts

View All
КАК УСТРОЕНА ВЛАСТЬ? Невидимая система, которую мы не з… — Transcript1:23:43
КАК УСТРОЕНА ВЛАСТЬ? Невидимая система, которую мы не з… — Transcript
Файб
11,512 1 Russian
Аффективная рыбалочка — Transcript1:31
Аффективная рыбалочка — Transcript
Псовский Диктор
50 1 Russian
§8 “Жизнь египетского вельможи”, История древнего мира … — Transcript8:20
§8 “Жизнь египетского вельможи”, История древнего мира … — Transcript
Учебник Вслух
663 1 Russian
§7 “Как жили земледельцы и ремесленники в Египте”, Исто… — Transcript6:09
§7 “Как жили земледельцы и ремесленники в Египте”, Исто… — Transcript
Учебник Вслух
453 1 Russian
ЗАПРЕТНАЯ ИСТОРИЯ: ЧТО НА САМОМ ДЕЛЕ НАШЛИ НАЦИСТЫ В АН… — Transcript1:33:41
ЗАПРЕТНАЯ ИСТОРИЯ: ЧТО НА САМОМ ДЕЛЕ НАШЛИ НАЦИСТЫ В АН… — Transcript
Война без лжи
9,668 1 Russian
§6 “Государство на берегах Нила”, История Древнего мира… — Transcript6:36
§6 “Государство на берегах Нила”, История Древнего мира… — Transcript
Учебник Вслух
657 1 Russian
Маткапитал в ПДС? Вот почему это не сработает 😱 #нпф #н… — Transcript0:55
Маткапитал в ПДС? Вот почему это не сработает 😱 #нпф #н… — Transcript
Дмитрий Бурнаев | Пенсионный эксперт | ПДС
70 1 Russian
Подросток. Инструкция для родителей — Transcript18:22
Подросток. Инструкция для родителей — Transcript
Доктор Комаровский
2,344 1 Russian
Урок 1 Обзор ниш — Transcript36:32
Урок 1 Обзор ниш — Transcript
Матвей Абрамов | AI-продюсер
5,514 1 Russian
ЭФИР 1. НИША | клуб от @abramotti — Transcript59:14
ЭФИР 1. НИША | клуб от @abramotti — Transcript
Матвей Абрамов | AI-продюсер
8,293 1 Russian
Три закона крутости, которые ты нарушаешь — Transcript25:06
Три закона крутости, которые ты нарушаешь — Transcript
Dagon
1,149 1 Russian
Крейсер “Варяг” – как россия 100 лет позорнейшее ПОРАЖЕ… — Transcript23:48
Крейсер “Варяг” – как россия 100 лет позорнейшее ПОРАЖЕ… — Transcript
MegaShow TV
2,670 1 Russian