Инструменты пользователя

Инструменты сайта


ru:software:article:utp_dpi

Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
Следующая версия
Предыдущая версия
ru:software:article:utp_dpi [2015/05/23 13:30]
root [Сигнатуры]
ru:software:article:utp_dpi [2015/05/27 23:28] (текущий)
root [Torrent/uTP — о протоколе и самодельных DPI]
Строка 10: Строка 10:
 Вот какой бред написан в [[https://​ru.wikipedia.org/​wiki/​ΜTorrent|русской википедии]] про uTP:\\ Вот какой бред написан в [[https://​ru.wikipedia.org/​wiki/​ΜTorrent|русской википедии]] про uTP:\\
 "​Также провайдерам намного сложнее блокировать передачу данных через μTP благодаря отсутствию строгих,​ формализованных отличий UDP пакетов обычного трафика (формируемого,​ к примеру,​ сетевыми играми) от трафика,​ формируемого протоколом μTP, в отличие от TCP пакетов,​ по содержанию полей которых можно делать вывод об их принадлежности к p2p-трафику."​\\ "​Также провайдерам намного сложнее блокировать передачу данных через μTP благодаря отсутствию строгих,​ формализованных отличий UDP пакетов обычного трафика (формируемого,​ к примеру,​ сетевыми играми) от трафика,​ формируемого протоколом μTP, в отличие от TCP пакетов,​ по содержанию полей которых можно делать вывод об их принадлежности к p2p-трафику."​\\
 +[[http://​en.wikipedia.org/​wiki/​Micro_Transport_Protocol|Вики на английском]] более адекватна.\\
  
 ===== Жизнь с uTP ===== ===== Жизнь с uTP =====
Строка 131: Строка 131:
 [[ru:​software:​freebsd:​ng_utp|FreeBSD uTP (udp torrent) netgraph node]]\\ [[ru:​software:​freebsd:​ng_utp|FreeBSD uTP (udp torrent) netgraph node]]\\
 Прошло полтора года, я успел покопаться в ядре FreeBSD и netgraph, лучше узнать как работает сеть и пришла мысль: uTP имеет состояния аналогичные TCP, значит чтобы его 100% определять нужно эти состояния отслеживать.\\ Прошло полтора года, я успел покопаться в ядре FreeBSD и netgraph, лучше узнать как работает сеть и пришла мысль: uTP имеет состояния аналогичные TCP, значит чтобы его 100% определять нужно эти состояния отслеживать.\\
-Заодно я ещё раз заглянул в libuTP и получше посмотрел за что можно зацепится.\\ +Заодно я ещё раз заглянул в [[https://​github.com/​bittorrent/​libutp|libuTP]] и получше посмотрел за что можно зацепится.\\ 
-За сигнатуры ​я решил не цепляться,​ это плохой путь с массой ложных срабатываний и мучениями по их поддержанию - авторы уже несколько раз меняли начальные константы и сигнатуры "​протухали"​ у тех кто их использовал.\\+За сигнатуры решил не цепляться,​ это плохой путь с массой ложных срабатываний и мучениями по их поддержанию - авторы уже несколько раз меняли начальные константы и сигнатуры "​протухали"​ у тех кто их использовал.\\
 Идеальный вариант это свой "​клиент"​ с референсной реализацией uTP который будет выстраивать таблицу соединений на основе пролетающих через него пакетов и уже по данным этой таблицы что то можно делать.\\ Идеальный вариант это свой "​клиент"​ с референсной реализацией uTP который будет выстраивать таблицу соединений на основе пролетающих через него пакетов и уже по данным этой таблицы что то можно делать.\\
  
-В итоге получилась netgraph нода, которую можно подключать к L2 хукам типа ng_ether или L3 хукам, например ng_ipfw. В первом случае можно вообще сделать прозрачный эзернет мост из двух сетевух (не обязательно физических). Ещё можно просто поставить ​тазик ​и зеркалировать на него весь траф, но я сейчас не уверен в работоспособности такой схемы.\\+В итоге получилась netgraph нода, которую можно подключать к L2 хукам типа ng_ether или L3 хукам, например ng_ipfw. В первом случае можно вообще сделать прозрачный эзернет мост из двух сетевух (не обязательно физических). Ещё можно просто поставить ​сервер ​и зеркалировать на него весь траф, но я сейчас не уверен в работоспособности такой схемы.\\
  
-Результатов замеров производительности ​я не сохранил.\\+Результатов замеров производительности не сохранил.\\
 Однако нода без проблем параллелится по ядрам, может выполнятся как контексте ISR так и потоками netgraph, взаимные блокировки потоков сведены к минимуму.\\ Однако нода без проблем параллелится по ядрам, может выполнятся как контексте ISR так и потоками netgraph, взаимные блокировки потоков сведены к минимуму.\\
  
Строка 164: Строка 164:
 <​li>​отправлять uTP - RST пакеты</​li></​ul>​ <​li>​отправлять uTP - RST пакеты</​li></​ul>​
 Чтобы сгенерировать RST пакет все данные есть: src ip:port + dst ip:port, pkt_ver, connid, ack_nr, seq_nr. Чтобы сгенерировать RST пакет все данные есть: src ip:port + dst ip:port, pkt_ver, connid, ack_nr, seq_nr.
-Фактически у IP/UDP пакета заменяются данные,​ пересчитывается контрольная сумма и от отправляется дальше. +Фактически у IP/UDP пакета заменяются данные,​ пересчитывается контрольная сумма и от отправляется дальше.\\
- +
-Подробнее про счётчики - по <a href="​http://​www.netlab.linkpc.net/​forum/​index.php?​topic=804.0">​ссылке</​a>,​ там описание,​ если его мало есть код :)+
  
-Сейчас это всё ещё может быть актуальным для различных беспроводных сетей и офисных сетей, остальные уже обновились и расширились.+Сейчас это всё ещё может быть актуальным для различных беспроводных сетей и офисных сетей, остальные уже обновились и расширились.\\
  
  
Строка 226: Строка 224:
  
 ===== Заключение ===== ===== Заключение =====
-1. То что <a href="​https://​ru.wikipedia.org/​wiki/​ΜTorrent">​написано в вики на русском</​a>​ - полнейший бред: ​uTP имеет достаточно чёткие сигнатуры и легко ловится DPI. +1. uTP имеет достаточно чёткие сигнатуры и легко ловится DPI.\\ 
-Более того, ловить сигнатуры в TCP ощутимо сложнее,​ поскольку для гарантированного обнаружения нужно уметь собирать несколько пакетов вместе и уже потом проверять содержимое:​ клиент может передавать данные по одному байту. +Более того, ловить сигнатуры в TCP ощутимо сложнее,​ поскольку для гарантированного обнаружения нужно уметь собирать несколько пакетов вместе и уже потом проверять содержимое:​ клиент может передавать данные по одному байту.\\ 
-Авторы uTP либо не ставили себе цель сделать протокол без сигнатур либо даже не приблизись к цели. +Авторы uTP либо не ставили себе цель сделать протокол без сигнатур либо даже не приблизись к цели.\\ 
-(На мой взгляд в начале не ставили,​ а потом было уже поздно и рандомизация отдельных полей не помогает). +На мой взгляд в начале не ставили,​ а потом было уже поздно и рандомизация отдельных полей не помогает.\\
-<a href="​http://​en.wikipedia.org/​wiki/​Micro_Transport_Protocol">​Вики на английском</​a>​ более адекватна.+
  
-2. Производители различных DPI уже давно добавили сигнатуры для uTP, вряд ли им это было трудно сделать.+2. Производители различных DPI уже давно добавили сигнатуры для uTP, вряд ли им это было трудно сделать.\\
  
-3. В порядке слухов:​ для линукса вроде бы тоже есть ядерная версия для работы с uTP протоколом на базе ipp2p а может уже отдельно. Но в паблик её не выкладывали. С середины 2012 года.+3. В порядке слухов:​ для линукса вроде бы тоже есть ядерная версия для работы с uTP протоколом на базе ipp2p а может уже отдельно. Но в паблик её не выкладывали. С середины 2012 года.\\
  
-4. Для IPv6 код не писал, на всякий случай ;)+4. Для IPv6 код не писал, на всякий случай ;)\\
  
 5. uTP не лучше TCP для передачи данных,​ вся проблема в том, что TCP можно хоть как то управлять из приложения только на BSD/Linux - setsockopt(...,​ IPPROTO_TCP,​ TCP_CONGESTION,​...) - основное что требуется,​ хотя и там более тонкие параметры congestion control для отдельных сокетов не настраиваются. 5. uTP не лучше TCP для передачи данных,​ вся проблема в том, что TCP можно хоть как то управлять из приложения только на BSD/Linux - setsockopt(...,​ IPPROTO_TCP,​ TCP_CONGESTION,​...) - основное что требуется,​ хотя и там более тонкие параметры congestion control для отдельных сокетов не настраиваются.
ru/software/article/utp_dpi.1432387804.txt.gz · Последние изменения: 2015/05/23 13:30 — root