prod/AWG2_harness
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Пакет: убрать docker.io из metadata и улучшить help/docs layout

Browse Source 
Удалён Recommends: docker.io из control. Ужесточено предупреждение, что --install не является production-path. В .deb docs переведены на repo-like структуру (/usr/share/doc/awg2-harness/repo/...), чтобы не ломались относительные ссылки.
This commit is contained in:
Crimson
2026-05-10 17:36:31 +05:00
parent 9d2d2bc0c2
commit b83f2ee3a9
3 changed files with 17 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ANTI_TORRENT.md
+6 -5
View File
@@ -4,7 +4,7 @@
## 1. Цель
Не детектить BitTorrent как протокол. Цель проще: ограничить количество одновременных conntrack flows на один VPN peer IP. Торрент-клиенты обычно пытаются держать сотни TCP/UDP peer-сессий, DHT/uTP/trackers. Лимит на 200–250 одновременных flows резко ухудшает P2P-поведение, но почти не затрагивает обычные сценарии.
Не детектить BitTorrent как протокол. Цель проще: ограничить количество одновременных conntrack flows на один VPN peer IP. Торрент-клиенты обычно пытаются держать сотни TCP/UDP peer-сессий, DHT/uTP/trackers. Лимит в диапазоне 100–250 одновременных flows заметно ухудшает P2P-поведение, но почти не затрагивает обычные сценарии при корректной настройке.
Это мягкий технический барьер, а не 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 200 } \
meter awg2_peer_connlimit_v4 { ip saddr ct count over 100 } \
counter name antitorrent_dropped_v4 \
drop
}
@@ -76,8 +76,9 @@ max_connections_per_peer = 100
Практические варианты:
- `150` — агрессивнее, больше риск задеть редкие легитимные сценарии.
- `200` — хороший default для VPN peer с лимитом 70 Mbit/s.
- `250` — более осторожный вариант, если хочется минимизировать риск жалоб от тяжёлых браузерных/WebRTC/WebSocket-сценариев.
- `100` — production default.
- `150` — мягче и более permissive при редких жалобах.
- `200/250` — ещё более permissive варианты, если нужно дополнительно снизить риск false positives.
## 5. Почему это должно быть в orchestrator
@@ -91,7 +92,7 @@ max_connections_per_peer = 100
## 6. Conntrack и производительность
`ct count` использует conntrack. На текущем масштабе это нормально: даже 23 peers × 200 flows = около 4600 активных flows до ограничения. Это не выглядит опасно для production-хоста само по себе.
`ct count` использует conntrack. На текущем масштабе это нормально: даже 23 peers × 100 flows = около 2300 активных flows до ограничения. Это не выглядит опасно для production-хоста само по себе.
Что надо мониторить: