Детект торрентов
Источников два, и они разной твёрдости.
Тег роутинга Xray. Правило с "protocol": ["bittorrent"] вешает на соединение тег TORRENT, агент видит его в логе и отправляет событие. Работает без всяких дополнений, но ловит немногое: Xray опознаёт BitTorrent по открытому рукопожатию в начале соединения, а современные клиенты по умолчанию шифруют поток (MSE/PE) и живут в DHT и uTP поверх UDP. До рукопожатия дело обычно не доходит — попадаются в основном старые клиенты с выключенным шифрованием.
Вердикты nDPI. У nDPI есть эвристики на зашифрованный BitTorrent, на DHT-пакеты и на uTP. Это разбор трафика, а не чтение метаданных из лога, поэтому видит он заметно больше.
Как включить
Тумблер «Детект торрентов через nDPI»: Настройки → Нарушения.
Больше ничего делать не нужно — ни ставить пакеты на ноду, ни править .env. Демон nDPId едет внутри образа агента, включение сводится к запуску пары процессов. Слушать интерфейс агент может потому, что и так работает в сети хоста с privileged — без этого не собирались бы сетевые метрики. Интерфейс выбирается по маршруту по умолчанию, а не «все подряд»: разбирать собственный трафик агента незачем.
Состояние тумблера рассылается всем подключённым агентам сразу, а при подключении агента отправляется ему заново — после перезапуска ноды настройка не теряется.
Агент должен быть не старше 1.5.0
Демон появился в образе агента, начиная с версии 1.5.0. Агент постарше честно ответит, что бинарников у него нет, и панель это покажет — тумблер не будет врать, что всё включилось.
Как вердикт превращается в нарушение
nDPI видит трафик уже после NAT, от имени ноды, и о том, чей это клиент, не знает ничего. Зато адрес назначения у него и у Xray один и тот же — по нему агент и связывает вердикт со строкой лога, в которой есть пользователь.
В событии есть поле detected_by:
| Значение | Что означает |
|---|---|
xray_routing | сработал тег роутинга Xray |
ndpi | вердикт разбора трафика |
Разбирая жалобу «за что заблокировали», по этому полю видно, на чём именно попался человек. События, записанные до появления второго источника, помечены xray_routing — другого у них и не было.
Тонкая настройка
Обычно не нужна, всё управляется тумблером. Но если хочется:
AGENT_NDPI_ENABLED=true # включить, не дожидаясь команды из панели
AGENT_NDPI_MANAGE_DAEMON=true # false, если демон уже поднят на ноде снаружи
AGENT_NDPI_INTERFACE=eth0 # пусто — интерфейс маршрута по умолчанию
AGENT_NDPI_SOCKET_PATH=/tmp/ndpid-distributor.sock
AGENT_NDPI_WINDOW_SECONDS=120 # сколько вердикт считается свежимЕсли сокет по указанному пути уже отвечает, агент считает, что демон подняли снаружи, и своих процессов не плодит.
О чём стоит подумать заранее
Это разбор трафика
Чтение лога Xray — это метаданные, которые нода и так пишет. nDPI разбирает трафик на интерфейсе. Шаг заметно более серьёзный, и включать его стоит осознанно, понимая, что вы делаете и зачем.
Нагрузка небольшая: демон работает с эвристиками по первым пакетам потока, а пакетные события агент велит не слать вовсе — они не несут вердикта и только грузили сокет.
Что агент прижимает у демона
Дефолты nDPId рассчитаны на отдельную машину-сенсор, а не на ноду, и на VPN-ноде обходятся дорого: десять потоков разбора делят одну работу и съедают до половины CPU, а мёртвый TCP-поток висит в таблице 7440 секунд — таблицы растут весь uptime, и со стороны это выглядит утечкой памяти. Агент выставляет своё:
| Что | Дефолт nDPId | У нас |
|---|---|---|
| Потоков разбора | 10 | 4 |
| Жизнь мёртвого TCP-потока | 124 минуты | 5 минут |
| Жизнь UDP-потока | 3 минуты | 2 минуты |
| Уборка таблицы | раз в 10 с | раз в 5 с |
| Что вообще разбирается | весь трафик | всё, кроме портов 80, 443, 8443, 5222 |
Последняя строка снимает основную часть нагрузки: клиентский трафик ноды идёт на 443, а вердикты с этих портов детектор всё равно выбрасывает — разбирать их значило платить процессором за заведомо ненужный результат. DHT и uTP живут на случайных высоких портах и под фильтр не попадают.
Пороги, чтобы не ловить лишнее
Вердикт nDPI говорит о протоколе, а не о намерении, поэтому нарушение заводится не по первому событию. В Настройки → Нарушения четыре порога:
- Порог событий — сколько срабатываний должно набраться за полчаса. Настоящий обмен даёт сотни за минуты.
- Порог разных адресов (рой) — со сколькими различными пирами шёл обмен. Торрент это рой из десятков адресов; события по одному и тому же адресу набивает обычное долгое соединение.
- Событий на адрес (глубина обмена) — сколько событий в среднем приходится на один адрес, по умолчанию 1,5. Торрент-клиент подолгу качает с одних и тех же пиров, а игровой лаунчер и опрос DHT касаются каждого адреса по разу. На живых данных окна War Thunder давали 1,0–1,5 события на адрес, окна торрент-клиентов — обычно 5–9.
- Кого не считать торрентом — список организаций-владельцев адреса.
Всё, кроме порога событий, появилось после разбора живых ложных срабатываний. Антивирус Kaspersky на порту 1443 дал восемь событий с одним адресом — по счётчику событий это выглядело нарушением, по числу пиров очевидно нет. А лаунчер Gaijin (War Thunder) раздаёт обновления настоящим BitTorrent: вердикт по нему верный, отличается только адресат. По владельцу адреса отсекаются серверы издателя, но остальной рой — это адреса других игроков. Зато весь он сидит на порту лаунчера (у War Thunder это 27032), тогда как у обычного торрент-клиента порты пиров разбросаны. Если на этом порту больше половины разных пиров за окно, детектор считает обмен раздачей игры и нарушение не заводит. Смешанный случай (игра плюс торрент-клиент) по-прежнему ловится. Убрать игровой трафик из VPN совсем можно только правилом по процессу или по папке игры в VPN-клиенте, домены игры тут не помогут.
Разобранное не считается заново. Окно в полчаса начинается с момента, когда оператор аннулировал или иначе разобрал прошлое торрент-нарушение клиента. Иначе окно тут же снова набирало бы те же события, и новое нарушение приходило бы через минуты. Нарушение в панели и карточка в Telegram строятся по одному окну: то же число событий и пиров, тот же список адресов.
Заодно подняли планку по портам: пиры живут либо в классическом диапазоне 6881–6999, либо на эфемерных портах выше 10000. Промежуток 1024–10000 — это почти сплошь серверные сервисы, и ловилось там не то.