feat: support AmneziaWG 3.1

docs/ANTI_TORRENT.md

@@ -4,7 +4,7 @@
 
 ## 1. Цель
 
-Не детектить BitTorrent как протокол. Цель проще: ограничить количество одновременных conntrack flows на один VPN peer IP. Торрент-клиенты обычно пытаются держать сотни TCP/UDP peer-сессий, DHT/uTP/trackers. Лимит в диапазоне 100–250 одновременных flows заметно ухудшает P2P-поведение, но почти не затрагивает обычные сценарии при корректной настройке.
+Не детектить BitTorrent как протокол. Цель проще: ограничить количество одновременных conntrack flows на один VPN peer IP. Торрент-клиенты обычно пытаются держать сотни TCP/UDP peer-сессий, DHT/uTP/trackers. Штатный baseline `500` сохраняет мягкий connection guard, не вмешиваясь в нормальный повседневный профиль по результатам эксплуатационных измерений проекта.
 
 Это мягкий технический барьер, а не abuse-система со страйками.
 
@@ -54,7 +54,7 @@ table inet awg2_harness {
     type filter hook forward priority filter; policy accept;
 
     ip saddr 10.8.1.0/24 ct state new \
-      meter awg2_peer_connlimit_v4 { ip saddr ct count over 100 } \
+      meter awg2_peer_connlimit_v4 { ip saddr ct count over 500 } \
       counter name antitorrent_dropped_v4 \
       drop
   }
@@ -70,15 +70,10 @@ table inet awg2_harness {
 ```toml
 [anti_torrent]
 enabled = true
-max_connections_per_peer = 150
+max_connections_per_peer = 500
 ```
 
-Практические варианты:
-
-- `100` — более строгий режим.
-- `150` — текущий рекомендуемый стартовый baseline, мягче к обычному browsing/mobile traffic.
-- `200/250` — ещё более permissive варианты.
-- `70` — агрессивный режим только после наблюдения реального трафика.
+`500` — production baseline, выбранный по прикладным и нагрузочным измерениям проекта. Connection guard остаётся включённым, но порог не должен мешать обычному browsing/mobile/application traffic. Любое значение ниже `500` является более агрессивной операторской политикой и требует отдельной проверки на реальных клиентах. Значение остаётся конфигурируемым и не зашито в алгоритм.
 
 ## 5. Почему это должно быть в orchestrator
 
@@ -92,7 +87,7 @@ max_connections_per_peer = 150
 
 ## 6. Conntrack и производительность
 
-`ct count` использует conntrack. На текущем масштабе это нормально: даже 23 peers × 100 flows = около 2300 активных flows до ограничения. Это не выглядит опасно для production-хоста само по себе.
+`ct count` использует conntrack. Для примера 23 peers × 500 flows дают до 11 500 потенциальных flow slots перед ограничением каждого peer. Само по себе это не является доказательством достаточной ёмкости конкретного хоста, поэтому фактическое состояние conntrack обязательно наблюдается.
 
 Что надо мониторить: