Автономный Способ Обхода Dpi И Эффективный Способ Обойти Блокировку Сайта По Ip-Адресу

Провайдеры в РФ в большинстве своем используют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, включенных в реестр запрещенных сайтов.

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

Существует два распространенных типа соединений DPI: пассивное и активное.



Пассивное разрешение

Пассивный DPI — DPI, подключенный к сети провайдера параллельно (не в разрезе) либо через пассивный оптический разветвитель, либо с помощью зеркалирования трафика, исходящего от пользователей.

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

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

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

адрес и последовательность TCP подделаны).

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



Обнаружение и блокировка пассивных пакетов DPI

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

Автономный способ обхода DPI и эффективный способ обойти блокировку сайта по IP-адресу

Мы видим, что сначала приходит пакет от DPI с кодом HTTP-перенаправления 302, а затем реальный ответ от сайта.

Ответ от сайта рассматривается как повторная передача и отбрасывается операционной системой.

Браузер переходит по ссылке, указанной в ответе DPI, и мы видим страницу блокировки.

Давайте подробнее рассмотрим пакет от DPI:

Автономный способ обхода DPI и эффективный способ обойти блокировку сайта по IP-адресу

  
  
  
  
   

HTTP/1.1 302 Found Connection: close Location: http://warning.rt.ru/Эid=17&st=0&dt=195.82.146.214&rs=http%3A%2F%2Frutracker.org%2F

В ответе DPI не устанавливается флаг «Не фрагментировать», а в поле «Идентификация» установлено значение 1. Серверы в Интернете обычно устанавливают бит «Не фрагментировать», а пакеты без этого бита встречаются редко.

Мы можем использовать это как особенность пакетов 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-байтовыми данными в пакете.

2-байтовое поле идентификации хранится по смещению 0x4, сразу за ним следуют 1-байтовые поля флагов и смещения фрагмента.

Со смещением 0x60 начинается домен перенаправления (заголовок HTTP Location).

Если Identification = 1, Flags = 0, Fragment Offset = 0, 0x60 = «предупреждать», 0x64 = «ing.», 0x68 = «rt.ru», то мы отбрасываем пакет и получаем реальный ответ от сайта.

В случае сайтов HTTPS DPI отправляет пакет сброса TCP также с идентификатором = 1 и флагами = 0.

Активное разрешение

Active DPI – DPI, подключенный к сети провайдера обычным способом, как и любое другое сетевое устройство.

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

Active 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:

Теги: #Сетевые технологии #Deep Packet Inspection #dpi #GoodByeDPI #reqrypt

Вместе с данным постом часто просматривают: