Здравствуйте.
Просим расширить настройки плагина Torrent Blocker и добавить возможность выбирать:
- Какой адрес из Xray webhook необходимо блокировать:
source,destinationили оба. - В каком направлении применять блокировку nftables: ingress или egress.
- На каких Remnawave Node должна действовать обнаруженная блокировка.
Проблема
Текущая логика корректно работает только в том случае, когда поле source в Xray webhook содержит реальный IP конечного пользователя.
Однако существуют схемы, в которых пользователь подключается к выходной Remnawave Node через промежуточную точку.
Вариант с HAProxy
Пользователь
→ HAProxy в режиме TCP
→ Remnawave Node / Xray
→ интернет
HAProxy в TCP-режиме не обрабатывает прикладное содержимое трафика, но принимает клиентское TCP-соединение и создаёт отдельное соединение с backend.
Поэтому без PROXY Protocol или transparent proxying Remnawave Node видит в качестве source IP HAProxy, а не IP конечного пользователя.
Каскад Remnawave Node
Пользователь
→ первая Remnawave Node / Xray
→ VLESS-мост
→ выходная Remnawave Node / Xray
→ интернет
При обычном VLESS-мосте выходная нода также видит новое соединение от первой ноды. В результате в source находится IP предыдущей Remnawave Node, а не IP конечного пользователя.
Таким образом, при использовании промежуточной точки webhook содержит:
- source = IP непосредственной предыдущей точки (HAProxy, L4-прокси или первой Remnawave Node)
- destination = IP конечного BitTorrent-пира
Текущее поведение
Сейчас Torrent Blocker всегда извлекает IP из поля source и добавляет его во входной набор nftables.
В результате блокируется непосредственный источник TCP-соединения:
При прямом подключении
→ блокируется IP пользователя
При подключении через промежуточную точку
→ блокируется IP HAProxy или предыдущей Remnawave Node
→ отключаются все пользователи, проходящие через эту точку
Добавление адреса промежуточной точки в ignoreLists проблему не решает. В таком случае событие полностью игнорируется, и никакое полезное действие с destination не выполняется.
Использование PROXY Protocol может сохранить исходный IP пользователя в отдельных схемах с HAProxy, но не решает задачу каскадных Remnawave Node и не предоставляет более мягкую стратегию блокировки только конечного направления.
Предлагаемое решение
Добавить возможность выбирать стратегию Torrent Blocker:
| Режим | Блокируемый адрес | Направление nftables |
|---|---|---|
source |
source из webhook |
ingress |
destination |
destination из webhook |
egress |
both |
source и destination |
ingress + egress |
connection-only |
адрес не добавляется в nftables | блокируется только текущая сессия |
Режим destination
Для схем с промежуточными точками необходим следующий сценарий:
BitTorrent обнаружен
→ текущая сессия направляется в RW_TB_OUTBOUND_BLOCK
→ IP из destination добавляется во временный egress-набор nftables
→ source-адрес пользователя или промежуточной точки не блокируется
Пример простой конфигурации:
{
"torrentBlocker": {
"enabled": true,
"blockDuration": 86400,
"blockTarget": "destination"
}
}
Более гибкий вариант:
{
"torrentBlocker": {
"enabled": true,
"blockDuration": 86400,
"nftAction": {
"addressField": "destination",
"direction": "egress",
"dropConnections": true
}
}
}
При выборе destination желательно, чтобы:
- из webhook извлекался IP без порта;
- IPv4 и IPv6 обрабатывались раздельно;
- адрес добавлялся во временный egress-набор с
timeout; - в отчёте отображался фактически заблокированный адрес;
- завершались соединения к заблокированному destination;
- соединения source-адреса не уничтожались;
- повторное событие могло обновлять или продлевать срок существующей блокировки;
- функциональность работала штатно без необходимости собирать собственный образ Remnawave Node.
Более мягкая стратегия блокировки
Режим destination будет полезен не только при использовании HAProxy или каскадных нод.
Он позволяет применять более мягкую реакцию на обнаружение BitTorrent:
source mode
→ пользователь полностью теряет доступ к ноде
→ при наличии прокси может блокироваться сразу группа пользователей
destination mode
→ блокируется только обнаруженный конечный адрес
→ пользователь и промежуточная точка сохраняют доступ
→ остальные соединения продолжают работать
Текущая BitTorrent-сессия уже направляется в RW_TB_OUTBOUND_BLOCK. Дополнительное помещение destination IP в egress-набор предотвращает повторные подключения к обнаруженному пиру в течение заданного времени.
Это не обязательно заменяет строгий режим блокировки пользователя, но предоставляет администратору выбор между полной блокировкой source и точечной блокировкой обнаруженных направлений.
Распространение блокировок между нодами
Дополнительно предлагается реализовать возможность распространять обнаруженные блокировки через центральную Remnawave Panel.
При локальной реализации режима destination адрес будет заблокирован только на ноде, где произошло обнаружение. При наличии нескольких выходных нод тот же destination может оставаться доступным через другие ноды.
Центральная Panel могла бы получать событие от ноды обнаружения и передавать блокировку:
- только на текущую ноду;
- на все активные ноды;
- только на выбранные ноды по UUID;
- на все ноды, кроме указанных UUID.
Предлагаемые режимы:
| Режим | Поведение |
|---|---|
local |
блокировка применяется только на ноде обнаружения |
all |
блокировка передаётся на все активные ноды |
include |
блокировка передаётся только на указанные UUID нод |
exclude |
блокировка передаётся на все ноды, кроме указанных UUID |
Все ноды
{
"torrentBlocker": {
"enabled": true,
"blockDuration": 86400,
"nftAction": {
"addressField": "destination",
"direction": "egress",
"dropConnections": true
},
"distribution": {
"mode": "all"
}
}
}
Только выбранные ноды
{
"torrentBlocker": {
"enabled": true,
"blockDuration": 86400,
"nftAction": {
"addressField": "destination",
"direction": "egress",
"dropConnections": true
},
"distribution": {
"mode": "include",
"nodeUuids": [
"NODE_UUID_1",
"NODE_UUID_2"
]
}
}
}
Все ноды, кроме указанных
{
"torrentBlocker": {
"enabled": true,
"blockDuration": 86400,
"nftAction": {
"addressField": "destination",
"direction": "egress",
"dropConnections": true
},
"distribution": {
"mode": "exclude",
"nodeUuids": [
"EXCLUDED_NODE_UUID_1",
"EXCLUDED_NODE_UUID_2"
]
}
}
}
Предполагаемая централизованная логика
Нода обнаруживает BitTorrent
→ блокирует текущую сессию
→ отправляет отчёт в Remnawave Panel
→ Panel определяет целевые ноды по JSON-конфигурации
→ передаёт им IP, направление и время завершения блокировки
→ целевые ноды добавляют адрес в локальный nftables-набор
Желательно передавать не новый полный blockDuration, а единый willUnblockAt. Тогда на всех нодах блокировка завершится одновременно, даже если доставка команды заняла некоторое время.
Также желательно предусмотреть политику обработки повторного события, например:
{
"repeatPolicy": "extend"
}
Возможные варианты:
keep— не изменять уже существующий срок;extend— продлевать блокировку от момента повторного события;max— сохранять наиболее позднийwillUnblockAt;replace— заменять срок значением нового события.
Итог
Текущая логика блокировки source подходит только тогда, когда source действительно соответствует IP конечного пользователя.
При использовании:
- HAProxy;
- L4-балансировщиков;
- TCP-прокси;
- каскадных Remnawave Node;
- схем
Remnawave Node → Remnawave Node;
поле source может содержать адрес общей промежуточной точки. Блокировка такого адреса затрагивает множество непричастных пользователей.
Возможность выбирать destination как цель egress-блокировки:
- решит проблему промежуточных точек;
- позволит не отключать пользователя полностью;
- обеспечит более точечную реакцию на обнаруженный трафик;
- даст возможность централизованно распространять блокировки на всю инфраструктуру или выбранные ноды.
Все параметры желательно задавать непосредственно в JSON-конфигурации плагина.