Site Tools


software:article:utp_dpi

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
software:article:utp_dpi [2015/05/23 13:30]
– [Сигнатуры] root
software:article:utp_dpi [2015/05/27 23:28]
– [Torrent/uTP — о протоколе и самодельных DPI] root
Line 10: Line 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-трафику."\\
 +[[href="http://en.wikipedia.org/wiki/Micro_Transport_Protocol|Вики на английском]] более адекватна.\\
  
 ===== Жизнь с uTP ===== ===== Жизнь с uTP =====
Line 131: Line 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, взаимные блокировки потоков сведены к минимуму.\\
  
Line 164: Line 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>, там описание, если его мало есть код :)+
  
-Сейчас это всё ещё может быть актуальным для различных беспроводных сетей и офисных сетей, остальные уже обновились и расширились.+Сейчас это всё ещё может быть актуальным для различных беспроводных сетей и офисных сетей, остальные уже обновились и расширились.\\
  
  
Line 226: Line 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 для отдельных сокетов не настраиваются.
software/article/utp_dpi.txt · Last modified: 2022/02/05 04:27 by root