# Torrent Blocker — выбор адреса, направления и области распространения блокировки

**URL:** https://f.docs.rw/t/topic/413
**Category:** Предложения
**Created:** 2026-07-18T09:15:57Z
**Posts:** 5

## Post 1 by @Gwynbleidd_YTV — 2026-07-18T09:15:58Z

Здравствуйте.

Просим расширить настройки плагина **Torrent Blocker** и добавить возможность выбирать:

1. Какой адрес из Xray webhook необходимо блокировать: `source`, `destination` или оба.
2. В каком направлении применять блокировку nftables: ingress или egress.
3. На каких 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-конфигурации плагина.

---

## Post 2 by @remnawave — 2026-07-18T23:46:01Z

> [@Gwynbleidd_YTV](#):
>
> ### Каскад 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-пира

С таком случае вам необходимо на первой входной ноде активировать торрент-блокер, до второй никакие пакеты уже не дойдут.

---

## Post 3 by @Gwynbleidd_YTV — 2026-07-19T17:39:56Z

А если это HAproxy? Входящий айпи будет от него. И банится целая нода.

---

## Post 4 by @remnawave — 2026-07-19T20:48:57Z

А это уже совершенно другой случай. Я в цитировани конкретно указал про ситуацию если входной сервер – это тоже Remnawave Node.

---

## Post 5 by @Gwynbleidd_YTV — 2026-07-20T06:14:43Z

В общем если будет возможность рассмотрите улучшение / расширение функционала данного плагина. Я думаю многим полезно будет более тонко настроить его.