⚡ Автономный способ обхода DPI и эффективный способ обхода блокировок сайтов по IP-адресу. GoodbyeDPI и ReQrypt + Blockcheck (ОБНОВЛЕНО 14 августа 2024)

Пассивный DPI — DPI, подключенный в провайдерскую сеть параллельно (не в разрез) либо через пассивный оптический сплиттер, либо с использованием зеркалирования исходящего от пользователей трафика. Такое подключение не замедляет скорость работы сети провайдера в случае недостаточной производительности DPI, из-за чего применяется у крупных провайдеров. DPI с таким типом подключения технически может только выявлять попытку запроса запрещенного контента, но не пресекать ее. Чтобы обойти это ограничение и заблокировать доступ на запрещенный сайт, DPI отправляет пользователю, запрашивающему заблокированный URL, специально сформированный HTTP-пакет с перенаправлением на страницу-заглушку провайдера, словно такой ответ прислал сам запрашиваемый ресурс (подделывается IP-адрес отправителя и TCP sequence). Из-за того, что DPI физически расположен ближе к пользователю, чем запрашиваемый сайт, подделанный ответ доходит до устройства пользователя быстрее, чем настоящий ответ от сайта.

Выявляем и блокируем пакеты пассивного DPI
Поддельные пакеты, формируемые DPI, легко обнаружить анализатором трафика, например, Wireshark.
Пробуем зайти на заблокированный сайт:



Мы видим, что сначала приходит пакет от DPI, с HTTP-перенаправлением кодом 302, а затем настоящий ответ от сайта. Ответ от сайта расценивается как ретрансмиссия и отбрасывается операционной системой. Браузер переходит по ссылке, указанной в ответе DPI, и мы видим страницу блокировки.

Рассмотрим пакет от DPI подробнее:

Код: выделить все HTTP/1.1 302 Found Connection: close Location:

В ответе DPI не устанавливается флаг «Don't Fragment», и в поле Identification указано 1. Серверы в интернете обычно устанавливают бит «Don't Fragment», и пакеты без этого бита встречаются нечасто. Мы можем использовать это в качестве отличительной особенности пакетов от DPI, вместе с тем фактом, что такие пакеты всегда содержат HTTP-перенаправление кодом 302, и написать правило iptables, блокирующее их:

Код: выделить все # iptables -A FORWARD -p tcp --sport 80 -m u32 --u32 "0x4=0x10000 && 0x60=0x7761726e && 0x64=0x696e672e && 0x68=0x72742e72" -m comment --comment "Rostelecom HTTP" -j DROP

Что это такое? Модуль u32 iptables позволяет выполнять битовые операции и операции сравнения над 4-байтовыми данными в пакете. По смещению 0x4 хранится 2-байтное поле Indentification, сразу за ним идут 1-байтные поля Flags и Fragment Offset.
Начиная со смещения 0x60 расположен домен перенаправления (HTTP-заголовок Location).
Если Identification = 1, Flags = 0, Fragment Offset = 0, 0x60 = «warn», 0x64 = «ing.», 0x68 = «rt.ru», то отбрасываем пакет, и получаем настоящий ответ от сайта.

В случае с HTTPS-сайтами, DPI присылает TCP Reset-пакет, тоже с Identification = 1 и Flags = 0.

Активный DPI — DPI, подключенный в сеть провайдера привычным образом, как и любое другое сетевое устройство. Провайдер настраивает маршрутизацию так, чтобы DPI получал трафик от пользователей к заблокированным IP-адресам или доменам, а DPI уже принимает решение о пропуске или блокировке трафика. Активный DPI может проверять как исходящий, так и входящий трафик, однако, если провайдер применяет DPI только для блокирования сайтов из реестра, чаще всего его настраивают на проверку только исходящего трафика.

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

Изучаем стандарт HTTP
Типичные HTTP-запросы в упрощенном виде выглядят следующим образом:

Код: выделить все GET / HTTP/1.1 Host: habrahabr.ru User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/50.0 Accept-Encoding: gzip, deflate, br Connection: keep-alive

Запрос начинается с HTTP-метода, затем следует один пробел, после него указывается путь, затем еще один пробел, и заканчивается строка протоколом и переносом строки CRLF.
Заголовки начинаются с большой буквы, после двоеточия ставится символ пробела.

Давайте заглянем в последнюю версию стандарта HTTP/1.1 от 2014 года. Согласно RFC 7230, HTTP-заголовки не зависят от регистра символов, а после двоеточия может стоять произвольное количество пробелов (или не быть их вовсе).

Код: выделить все Each header field consists of a case-insensitive field name followed    by a colon (":"), optional leading whitespace, the field value, and    optional trailing whitespace.      header-field   = field-name ":" OWS field-value OWS      field-name     = token      field-value    = *( field-content / obs-fold )      field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]      field-vchar    = VCHAR / obs-text      obs-fold       = CRLF 1*( SP / HTAB )                     ; obsolete line folding

OWS — опциональный один или несколько символов пробела или табуляции, SP — одинарный символ пробела, HTAB — табуляция, CRLF — перенос строки и возврат каретки (\r\n).

Это значит, что запрос ниже полностью соответствует стандарту, его должны принять многие веб-серверы, придерживающиеся стандарта:

Код: выделить все GET / HTTP/1.1 hoSt:habrahabr.ru user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/50.0 Accept-Encoding:           gzip, deflate, br coNNecTion:  keep-alive      ‡здесь символ табуляции между двоеточием и значением

На деле же, многие веб-серверы не любят символ табуляции в качестве разделителя, хотя подавляющее большинство серверов нормально обрабатывает и отсутствие пробелов между двоеточием в заголовках, и множество пробелов.

Старый стандарт, RFC 2616, рекомендует снисходительно парсить запросы и ответы сломанных веб-северов и клиентов, и корректно обрабатывать произвольное количество пробелов в самой первой строке HTTP-запросов и ответов в тех местах, где требуется только один:
Clients SHOULD be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required.
Этой рекомендации придерживаются далеко не все веб-серверы. Из-за двух пробелов между методом и путем ломаются некоторые сайты.

Спускаемся на уровень TCP
Соединение TCP начинается с SYN-запроса и SYN/ACK-ответа. В запросе клиент, среди прочей информации, указывает размер TCP-окна (TCP Window Size) — количество байт, которые он готов принимать без подтверждения передачи. Сервер тоже указывает это значение. В интернете используется значение MTU 1500, что позволяет отправить до 1460 байтов данных в одном TCP-пакете.
Если сервер указывает размер TCP-окна менее 1460, клиент отправит в первом пакете данных столько, сколько указано в этом параметре.

Если сервер пришлет TCP Window Size = 2 в SYN/ACK-пакете (или мы его изменим на это значение на стороне клиента), то браузер отправит HTTP-запрос двумя пакетами:

Пакет 1:

Код: выделить все GE

Пакет 2:

Код: выделить все T / HTTP/1.1 Host: habrahabr.ru User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/50.0 Accept-Encoding: gzip, deflate, br Connection: keep-alive

Используем особенности HTTP и TCP для обхода активного DPI
Многие решения DPI ожидают заголовки только в стандартном виде.
Для блокировки сайтов по домену или URI, они ищут строку "Host: " в теле запроса. Стоит заменить заголовок «Host» на «hoSt» или убрать пробел после двоеточия, и перед вами открывается запрошенный сайт.
Не все DPI можно обмануть таким простым трюком. DPI некоторых провайдеров корректно анализируют HTTP-заголовки в соответствии со стандартом, но не умеют собирать TCP-поток из нескольких пакетов. Для таких DPI подойдет «фрагментирование» пакета, путем искусственного уменьшения TCP Window Size.

В настоящий момент, в РФ DPI устанавливают и у конечных провайдеров, и на каналах транзитного трафика. Бывают случаи, когда одним способом можно обойти DPI вашего провайдера, но вы видите заглушку транзитного провайдера. В таких случаях нужно комбинировать все доступные способы.