Содержание статьи
Провайдеры и DPI
У провайдеров есть две проблемы:
- они обязаны ограничивать доступ к некоторым данным в соответствии с законом;
- ни одна компания не хочет платить лишние деньги за собственное соединение с провайдером уровня выше, которое, очевидно, тарифицируется.
И та и другая проблема решается ограничением отдельных запросов или протоколов, с чем справляется тот самый глубокий анализ пакетов — DPI.
Рядовых пользователей это лишает многих возможностей. Провайдер, например, способен заблокировать или сильно замедлить весь трафик протокола BitTorrent, так что качать торренты станет невозможно. Или, ради дополнительной выгоды, может «отключать» VoIP и Skype для всех пользователей, кроме тех, кто специально оплатил доступ.
DPI способен обнаруживать и пресекать соединения по определенным правилам, а их возможности зависят от производителя оборудования. Единственное, что их объединяет, — DPI работает начиная с транспортного уровня сетевой модели.
Сетевая модель
Компьютерные сети устроены таким образом, чтобы работать над сложными приложениями, не думая о кабелях и битах.
Для этого было определено четыре степени абстракции. Каждый следующий шаг вверх упрощает работу с информацией, которая передается по сети.
- Самый первый уровень связи основан на физических процессах. Он позволяет определять и связывать устройства, работая с аппаратными адресами: это в первую очередь ARP, L2TP и PPP.
- Второй слой, уровень маршрутизации, затрагивает адреса IP и создает логическую связь между узлами IPv4, IPv6 и IPsec. Оба эти уровня — ключевые, они описывают основу, то, как компьютеры могут друг друга найти.
- Третий уровень — транспортный — занимается данными: что передавать и насколько качественно это делать. TCP и UDP — два ключевых протокола, которые занимаются передачей данных на этом уровне, обеспечивают сохранность информации и ее порядок. Благодаря им все соединения строго регулируются.
- Последний, четвертый уровень — прикладной, поэтому его описание очень широко (из-за невообразимо большого количества протоколов), а использование не обязательно, не все приложения это делают. Но если используют, то за дело берутся протоколы HTTP и WebSocket, чтобы ты мог сидеть в интернете, играть в MMORPG и чатиться. Протокол FTP используется в основном для обмена файлами, а POP и IMAP — электронной почтой.
Оборудование DPI обычно работает с транспортным уровнем, пакетами TCP и UDP, читая не только заголовки, но и содержимое пакетов.
Анализ пакетов данных
Любой протокол имеет свою четко обозначенную внутреннюю логику, а также специальные сигнатуры, которые позволяют участникам соединения определять, кто и о чем говорит.
HTTP
Давай разберемся, например, с HTTP — самым популярным протоколом. Отправим запрос на http://xakep.ru.
GET / HTTP/1.1
Host: xakep.ru
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Я уже участник «Xakep.ru»
slinkin
03.06.2019 at 14:04
Очень поверхностная статья. О работе DPI мало что сказано.
Касательно обходов блокировки — по тоннелям всё понятно. Это самый верный (на данный момент) способ, ибо для DPI это будет просто VPN, который пока что у нас в стране разрешён.
По изменению регистра и изменою размера пакета — это возможно будет работать только на самых безнадёжных DPI системах. Потому что на любой нормальной сетевой софтине, что ставится в разрыве, всегда есть reassembler, а поиск в хедере по паттернам (стоит сказать что «вычленение» урла, типа запроса, версию протокола, и прочую информацию по потоку, называться metadata extraction) по всем канонам должен выполняться как case-insensitive, ибо регистр никак не влияет на обработку запроса на конечном сервере.
Также не совсем понятно почему вы описываете что блокировка выполняется по IP и теряется доступ ко всем ресурсам на сервере. Это не так. Во-первых, любое обращение по урлу сопровождается dns запросом. (Возможно он может быть захеширован, но это другой случай). Адрес полученный для урла конкретным абонентом (DNS Answer) — сохраняется. Затем от абонента тут же улетает запрос на хендшейк (на IP полученный из DNS ответа). Затем идёт ответ от сервера, где в полях пакета можно найти домен, для которого устанавливается соединение. Тут DPI и рубит коннект отсылая RST для обоих потоков и/или перенаправляя пользователя на страницу с сообщением о блокировке ресурса.
На самом деле DPI использует достаточно интересные правила и эвристики для определения типа трафика, ведёт собственную таблицу потоков и накатывает различные ограничения, которые не только связаны с блокировкой и шейпингом.
necroromnt
03.06.2019 at 16:21
Судя по тому как работает emmet.io через ростелеком, они просто дропают пакеты, не обременяя себя оповещением клиента о том, что соединение разорвано, не говоря уже о перенаправлении.
Sudden
07.06.2019 at 14:32
Подтверждаю. И даже не РТК… С VPN норм.
icoz
08.07.2019 at 00:20
Тоже подтверждаю. А что с этим фреймворком не так? За что забанен?
Михаил Киреев
03.06.2019 at 20:27
Статья, к сожалению, не может быть настолько глубокой, насколько этого хочется, так как большинство DPI-решений (если не все) — закрытое, проприетарное ПО, и, следовательно, внутрь залезть и исследовать всё возможным не представляется.
Изменение регистра заголовков и размера пакета все еще работает, так как «безнадёжных» систем в России полно (никто не хочет тратить лишние деньги, если и так работает).
Reassembler, может, и работал бы хорошо, да вот незадача — у крупных провайдеров не одна и не две DPI-системы. И в таком случае трафик даже одного клиента невозможно проводить через один и тот же сервер, а значит, есть вероятность, что разные сервера увидят разные куски, и каждый из них пропустит данные. Даже внутренний обмен метаданными внутри, между серверами анализа, не помогает: слишком большой объем, необходима большая пропускная способность, есть задержка — всё это способствует успешной работе трюка с TCP Window Size.
В случае блокировки по IP всё же блокируется как весь ресурс, так и соседние с ним (исключение составляют крупные сервисы со множеством дублирующих серверов, где блокировка одного IP не затрагивает остальные):
Сначала производится DNS Query по URL от клиента: он получает A-записи об IP-адресах хоста (для DNS мы можем обеспечить отсутствие цензуры, равно как и шифрование DNSSEC, например, взять любой крупный, хоть 1.1.1.1 или 8.8.8.8).
Затем происходит TCP-handshake. Уже на этом этапе провайдеры блокируют соединение, сразу после хэндшейка отправляя поддельный запрос с флагом RST. До http(s) дело даже не доходит, если блокировка идёт по IP-адресу сайта.
Если же на одном и том же оборудовании (и, соответственно, на общем IP address) сидят несколько сайтов, например, с роутингом на nginx, когда запросы с разными директивами Host идут на разные внутренние порты, то в таком случае ранний RST не позволяет даже отправить HTTP-запрос, не говоря о каком-то роутинге и определении hostname. А значит, запрос не будет отправлен ни к блокируемому сервисы, ни к остальным.
О DPI говорить можно много, но точных алгоритмов и эвристик мы достоверно не знаем. Очевидно, что топовые производители уже привязали машинное обучение, создали тысячи ручных правил, но всё же цель статьи — объяснить не все эти правила, эвристики и новые технологии (мы о них можем даже не подозревать), а исключительно принцип. Принцип действия, то, как производится анализ и на что нацелено оборудование. Не более.
Владислав Д
07.06.2019 at 08:51
Статья очень слабая, обоснование необходимости написать ее такой в комментах и то информативней и интересней.
Sudden
07.06.2019 at 14:36
Так добавьте важной информации…
intrud3r
17.06.2019 at 17:46
100%