Как заблокировать торренты на своём VPN или прокси

Если вы раздаёте доступ к своему VPS через VPN или прокси, торрент-трафик ваших пользователей уходит в интернет с вашего IP — и жалобы правообладателей приходят вам. В этой статье вы разберётесь, почему полностью отфильтровать торренты нельзя и почему это не мешает решить задачу, настроите блокировку на уровне Xray (Remnawave, 3x-ui, Marzban) или на уровне netfilter для WireGuard и OpenVPN, и соберёте из этого рабочую схему в три слоя.

Что понадобится

  • VPS ForestsNet Cloud с доступом по SSH под root или пользователем с sudo.
  • Понимание, что именно у вас стоит: панель на Xray (Remnawave, 3x-ui, Marzban) или классический VPN (WireGuard, OpenVPN). От этого зависит вся дальнейшая настройка — способы не взаимозаменяемы.
  • Базовое знакомство с файрволом: «Основы iptables» или «Файрвол ufw».

Сначала о честных пределах

Торрент-клиенты умеют прятаться, и прячутся хорошо. Вот как меняется доля распознанных соединений при глубоком анализе трафика (DPI) в зависимости от того, что включил пользователь:

  • Открытый протокол, без шифрования — распознаётся 98,3% соединений, в среднем за 3,2 секунды.
  • MSE, встроенное шифрование протокола — 41,7%.
  • MSE + uTP, при выключенном DHT — 7,1%.

Похожая картина у прокси: по документации Remnawave, встроенный в Xray сниффинг опознаёт BitTorrent примерно в 10–30% случаев.

Увидев «7%», легко решить, что затея бессмысленная. Это не так, и вот почему.

Вам не нужно отфильтровать каждый пакет — достаточно поймать один. Дальше работает не фильтр, а санкция: источник отправляется в бан на время. Пользователь, который начал раздачу, за первые же секунды сделает сотни обращений к пирам и трекерам. Даже при 10% распознавания он попадётся почти сразу — и его отключит не фильтр, а бан.

Поэтому дальше речь идёт о схеме «поймал → забанил на время», а не о попытке построить непроницаемую стену. Стены не получится ни у кого.

ℹ️ Совет: прежде чем настраивать блокировки, предупредите своих пользователей. Молча оборвавшийся торрент выглядит как поломка вашего сервиса, и разбираться с этим придётся вам же.

Вариант A. Панель на Xray: Remnawave, 3x-ui, Marzban

Если у вас прокси-панель, начинать нужно отсюда — и только отсюда.

Трафик от пользователя до вашего VPS уже зашифрован клиентом, поэтому файрвол на сервере видит не торренты, а шум. Любые правила iptables из второй половины статьи здесь просто ни на что не посмотрят. Резать нужно внутри самого Xray, там, где трафик уже расшифрован.

Шаг 1. Включите сниффинг — без него не работает ничего

В настройках inbound добавьте:

"sniffing": {
  "enabled": true,
  "destOverride": ["http", "tls", "quic"]
}

Это не опциональная оптимизация. Без включённого сниффинга Xray-Core не определяет протокол трафика, в том числе BitTorrent, и правило блокировки не срабатывает вообще. Правило по доменам без сниффинга тоже мёртвое: прокси видит только IP-адрес назначения, а не имя домена, к которому обращается клиент.

Если вы настроите всё остальное, но забудете этот блок — блокировка будет выглядеть настроенной и не будет работать. Это самая частая причина «я всё сделал, а торренты идут».

Шаг 2. Добавьте правила маршрутизации

В основном профиле Xray, в разделе routing rules:

{
  "protocol": ["bittorrent"],
  "outboundTag": "TORRENT"
},
{
  "domain": ["geosite:category-public-tracker"],
  "ruleTag": "TORRENT_BY_DOMAIN",
  "outboundTag": "TORRENT"
},
{
  "port": "6881-6889,6969,9696,51413,21413,17417,37305",
  "ruleTag": "TORRENT_BY_PORT",
  "outboundTag": "TORRENT"
}

Три правила ловят разное: первое — распознанный протокол, второе — обращения к публичным трекерам по доменному имени, третье — стандартные торрент-порты.

Зачем правило по портам, если порт меняется в две секунды. Справедливое возражение — но здесь порт работает не фильтром, а растяжкой. Тег TORRENT_BY_PORT дальше попадёт в список для блокировщика, поэтому одного пакета на 6881 хватит, чтобы источник ушёл в бан. Пользователь может сменить порт у себя, но рано или поздно постучится к чужому пиру или трекеру, который сидит на стандартном, — и этого достаточно.

Шаг 3. Заведите outbound, куда всё это ведёт

Про этот блок забывают чаще всего, и тогда правила выше указывают в пустоту:

{
  "tag": "TORRENT",
  "protocol": "blackhole"
}

blackhole — это «выбросить». Без него outboundTag: "TORRENT" не на что ссылаться.

Шаг 4. Включите блокировщик в ноде Remnawave

Сами по себе правила выше только отбрасывают пакеты. Чтобы источник получал временный бан, в ноде включается плагин:

{
  "torrentBlocker": {
    "enabled": true,
    "ignoreLists": { "ip": [] },
    "blockDuration": 3600,
    "includeRuleTags": ["TORRENT_BY_DOMAIN", "TORRENT_BY_PORT"]
  },
  "sharedLists": []
}

Схема работы: Xray ловит пакет, подходящий под правило из includeRuleTags, дёргает вебхук, нода добавляет IP в nftables и рвёт уже установленные соединения через conntrack -D. blockDuration: 3600 — бан на час.

Что важно знать заранее:

  • Нужен Xray-Core версии 26.3.27 или новее — в более старых вебхука просто нет.
  • Плагин включается в ноде отдельно, установки панели недостаточно.
  • В ignoreLists.ip перечисляются отдельные адреса; диапазоны в формате CIDR там не поддерживаются.

Если у вас 3x-ui или Marzban

Штатного плагина с такой логикой там нет. Его роль выполняет отдельный сервис kutovoys/xray-torrent-blocker — программа на Go, которая читает access.log Xray, находит записи с нужным тегом и банит источник. Правила маршрутизации и сниффинг настраиваются так же, как выше.

Вариант B. WireGuard и OpenVPN: фильтруем в netfilter

Здесь ситуация обратная: после расшифровки на сервере трафик идёт в открытом виде, и DPI применим. Правила вешаются в цепочку FORWARD с указанием интерфейса туннеля — wg0 для WireGuard, tun0 для OpenVPN. Дальше в примерах wg0, подставьте свой.

Шаг 1. Закройте DHT и UDP-трекеры

Это самый дешёвый шаг и самый болезненный для торрента: DHT не шифруется никогда, это слабое место протокола. Клиент, потерявший DHT и трекеры, теряет способность находить пиров.

Матчить нужно бенкод — с префиксом длины строки, а не голые слова:

sudo iptables -A FORWARD -i wg0 -p udp -m string --algo bm --string "9:find_node" -j DROP
sudo iptables -A FORWARD -i wg0 -p udp -m string --algo bm --string "9:get_peers" -j DROP
sudo iptables -A FORWARD -i wg0 -p udp -m string --algo bm --hex-string "|3a 61 6e 6e 6f 75 6e 63 65 5f 70 65 65 72|" -j DROP
sudo iptables -A FORWARD -i wg0 -p udp -m string --algo bm --hex-string "|0000041727101980|" -j DROP

Первые три — запросы протокола DHT (find_node, get_peers, announce_peer) в бенкод-представлении. Последнее правило — магическая константа connect-запроса к UDP-трекеру; она фиксирована спецификацией и ложных срабатываний не даёт вообще.

Не забудьте сохранить правила, иначе они не переживут перезагрузку:

sudo netfilter-persistent save
ℹ️ Осторожно с готовыми скриптами из интернета. Самый растиражированный набор правил (shopeevpn/Block-Bittorrent и его многочисленные копии) блокирует голые строки announce, torrent, info_hash — без префикса длины. Такие правила рвут обычный веб-сёрфинг: слово announce встречается в совершенно посторонних запросах. В тех же скриптах до сих пор лежат правила на .exe?/c+dir и /default.ida? — это сигнатуры сетевого червя Code Red 2001 года, попавшие туда копипастой и к торрентам отношения не имеющие. Прежде чем запускать чужой скрипт, прочитайте, что именно он добавляет.

Шаг 2. Если нужен серьёзный разбор — xt_ndpi

Модуль ядра xt_ndpi даёт полноценный DPI прямо в iptables. Два момента, на которых спотыкаются чаще всего:

Берите живой форк. Почти все руководства ведут на betolj/ndpi-netfilter — этот репозиторий заброшен, последний коммит 2017 года. Поддерживаемая версия: vel21ripn/nDPI, ветка flow_info-4.

Разбор DHT выключен по умолчанию. Именно он нужен, чтобы ловить зашифрованные сессии, и именно его забывают включить. В README форка это сказано прямо: возможность разбирать DHT-сообщения добавлена для детекта шифрованных соединений, но по умолчанию анализ DHT отключён. Отсюда же берутся регулярные жалобы «bittorrent matching is not working properly»: модуль ставят, DHT-анализ не включают, ловят только открытый BitTorrent и делают вывод, что модуль не работает.

Включается параметрами модуля:

sudo modprobe xt_ndpi bt_hash_size=64 bt_hash_timeout=900
sudo iptables -A FORWARD -i wg0 -m ndpi --bittorrent -j DROP

Модуль собирается для ядер начиная с 4.4. Для ядра 5.18 и новее потребуется либо ядро с CONFIG_LIVEPATCH=y (в Ubuntu и AlmaLinux он включён), либо патч ядра.

Шаг 3. Альтернатива без сборки модулей — Suricata inline

Если возиться с модулями ядра не хочется, ту же работу делает Suricata в режиме inline через NFQUEUE. Берутся готовые правила ET Open — набор emerging-p2p.rules, где уже есть сигнатуры на DHT, — и действие в них меняется с alert на drop.

Одна деталь, которую нельзя пропускать: в правиле передачи трафика в очередь обязателен --queue-bypass. Без него падение или перезапуск Suricata оборвёт весь транзитный трафик ваших пользователей, а не только торренты.

Шаг 4. Поведенческое ограничение на добивку

Торрент-клиент держит сотни одновременных соединений — обычный трафик так себя не ведёт. Этому признаку всё равно, какой у клиента порт и включено ли шифрование:

sudo iptables -A FORWARD -i wg0 -p tcp --syn -m connlimit --connlimit-above 150 --connlimit-mask 32 -j DROP

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

Что дальше

Собирайте защиту слоями, начиная с того, что даёт больше всего при наименьших усилиях:

  1. DHT и UDP-трекеры — двадцать минут работы, ложных срабатываний нет, эффект сразу заметный.
  2. Детект с временным баном — ключевой слой. Он не фильтрует трафик, он наказывает источник, и поэтому работает даже при низкой доле распознавания.
  3. connlimit — сверху, как подчистка остатков.

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

Дальше имеет смысл свериться с «Чек-листом безопасности сервера», а если правил в файрволе стало много — навести в них порядок по статьям «Основы iptables» и «Файрвол ufw». Настройка самих туннелей разобрана в «WireGuard VPN» и «OpenVPN».

Источники

Похожие статьи

← НазадОсновы iptables