# Что взять из новых репозиториев (разбор 2026-11-02) Рабочий журнал: разбираем список сторонних проектов и сравниваем с `rebuild/`. Ничего из этого ещё не внедрено — это решения «брать / не брать / почему». Формат по каждому проекту: что это, чем лучше нас, чем мы лучше, что взять в `rebuild` по приоритету, что не брать. Пересечения с `docs/repos.md` отмечены явно: там уже разобраны 36 проектов, и повторять одно и то же дважды не нужно. Обозначения приоритета: - **P1** — закрывает реальный риск (доступ, потеря данных, молчаливая авария). - **P2** — заметно улучшает эксплуатацию, но не горит. - **P3** — идея на будущее или отдельный продукт. - **—** — не берём. ## Список (не терять) | № | Проект | Лицензия | Вердикт | Приоритет | |---|---|---|---|---| | 1 | jestivald/node-accelerator | MIT | взять 4 идеи | P1–P2 | | 2 | lib4u/vnm | MIT | взять 2 идеи | P1–P2 | | 3 | nuver-labs/vps-audit | MIT | взять 2 проверки | P2 | | 4 | NNN706/M3T | нет | только данные, позже | P3 | | 5 | gorecvpn/gorecshit | MIT | взять 3 идеи | P2 | | 6 | DigneZzZ/routing | нет | только данные | — | | 7 | DigneZzZ/remnawave-scripts | MIT | взять UX меню | P2 | | 8 | evgmahov-blip/remna-node-scripts | нет | взять 2 идеи | P2 | | 9 | FrI3nd7/skipit-vps-node | MIT | уже разобран | — | | 10 | wasteprince/remnanode-xhttp-cleaner | MIT | не нужно сейчас | P3 | | 11 | g1tx/vpn-node-tuner | MIT | только цифры | P3 | | 12 | nektona/vpn-node-tuner | MIT | взять A/B-режим | P2 | | 13 | beqwes/begleq-autorwnode | нет | взять MOTD | P2 | | 14 | xdeptu5/geo-routing-server | MIT | отдельный продукт | P3 | | 15 | raywari/ru-blocklist | нет | только данные | — | | 16 | UnRKN/ru-blocklist | нет | только данные | — | | 17 | anfixit/routerus | MIT | взять 4 идеи | P1–P2 | | 18 | prettyleaf/remnanode-exporter | MIT | отдельный продукт | P3 | | 19 | syvlech/remnawave-limiter | GPL-3.0 | уже разобран | — | | 20 | kabebon/traffic-limiter | нет | только идея | P3 | | 21 | lifeindarkside/Remnawave-Routing-update | нет | только идея | P3 | | 22 | Balbuto/safe-remnanode-setup | нет | взять GeoIP | P3 | | 23 | princeofscale/ru-remna-utils | MIT | уже разобран | — | | 24 | DenFiord/remnascripts | MIT | уже разобран | — | | 25 | HikaruApps/remnanode-antiscan | MIT | уже разобран | — | | 26 | win64exe/remnawave-server-protect | MIT | уже разобран | — | | 27 | Flecksis/rkn-guard | MIT | взять 1 идею | P2 | --- # 1. jestivald/node-accelerator **Что это.** Три модуля на одну уже работающую ноду: `optimize.sh` (XanMod/BBRv3 + sysctl + RPS + swap + логи), `protect.sh` (nftables + CrowdSec + анти-скан + автобаны), `diagnose.sh` + `na-report.sh` (read-only диагностика и форензика), `rollback.sh` (откат). Около 14,6 тыс. строк, 18 тестовых скриптов, CI, minisign-подписи модулей. Ставится поверх готовой ноды, свои контейнеры и сертификаты не трогает. Пересечение с нами примерно на треть: и там, и тут есть XanMod, sysctl по профилям, ZRAM+swap, nftables в своей таблице, анти-скан, блоклисты, `--check`. ## Чем они лучше 1. **Тесты проверяют поведение, а не строки.** `tests/nft-behavior.sh` и `cs-scope-nft.sh` поднимают правила в network namespace и смотрят, что реально дропается и что пропускается. Наши 80 ассертов — в основном «функция вернула 0/1» и «в конфиге есть строка». Наши правила файрвола ни разу не проверены как правила. 2. **Anti-lockout по SSH сделан по-настоящему.** Порт берётся из `sshd -T` и socket-юнита (Ubuntu 24.04 слушает `ssh.socket`, где `Port` из конфига игнорируется), порт текущей SSH-сессии всегда добавляется в allow, есть `SAFETY_DELAY=300`: не подтвердил доступ из новой сессии — правила и автозагрузка снимаются сами. У нас `initial_setup.sh` меняет порт и закрывает 22 без таймера отката. Это единственное место, где наша ошибка стоит доступа к серверу. 3. **Пер-IP лимиты.** У них SYN/UDP/ICMP/connlimit считаются на адрес, а не глобально. У нас в `firewall.sh` только `meter pscan*` (дроп сканера) и общий `limit rate 5/second` на ping. Флуд с одного адреса у нас не режется, пока не попадёт в скан-метр. 4. **MSS clamp к PMTU и пол `tcp_min_snd_mss`.** У нас весь трафик идёт через туннели (Xray → decoy, WARP, NetBird), а PMTU-провалы лечатся только `tcp_mtu_probing=1`. Их пара sysctl закрывает случай, когда клиент застревает на 1400-байтных пакетах. 5. **`rp_filter=2` + `tcp_ecn=2` + syncookies** — у нас нет ни одного. Для ноды с асимметричным роутингом (WARP сбоку) `rp_filter=1` может рубить легитимные ответы. 6. **Логи.** У нас нет ни `logrotate` на `access.log` ноды/nginx, ни капа journald. На боевой ноде это ровно их сценарий: диск забит, certbot не может обновить сертификат, клиенты отваливаются молча. У нас есть `--check` на сертификат, но не на диск. 7. **Откат тюнинга.** Они снимают исходные sysctl/THP/RPS при первом прогоне и умеют `rollback optimize`. У нас бэкапятся только конфиг-файлы в `/var/backups/remnawave`, sysctl вернуть нечем. 8. **Диагностика как датчики, а не как таблица.** `--json` с дельтами между запусками, сенсор «порт node-агента не совпадает с правилом файрвола», `SPAWN_ERROR` в контейнере, сроки сертов, дрейф whitelist в четырёх слоях. Наш `--check` печатает состояние. Их сенсор «агент слушает 3000, а firewall держит 2222» — буквально наш будущий баг: мы разрешаем `NODE_PORT` из конфига и не сверяем его с фактом. 9. **`na-fw allow/unban`** — одна команда правит живой сет, файл правил, конфиг и CrowdSec. У нас разбан — руками в трёх местах. ## Чем мы лучше - Мы ставим ноду целиком: decoy, сертификаты, Docker, регистрация в панели, NetBird. Они предполагают, что всё это уже есть. - Наш профиль-подход по RAM проще и безопаснее для 1 vCPU / 2 ГБ, чем их tier-машина с RPS/XPS/irqbalance, которая на мелкой VPS ничего не даёт. - У нас нет CrowdSec-демона, второго bouncer'а и внешнего APT-репозитория — меньше поверхности и меньше зависимостей. Их же выбор `CROWDSEC_SCOPE=ssh` по умолчанию это подтверждает: на ноде он и так смотрит только sshd. - `protect.sh` с `FW_MODE=open` для 3x-ui — компромисс под чужую архитектуру. Нам он не нужен, ослаблять catch-all drop не надо. ## Что взять в rebuild (по приоритету) 1. **P1. Safety-таймер на SSH** в `initial_setup.sh`: применить, потребовать подтверждение из новой сессии, иначе вернуть старый drop-in и правила. ~40 строк, снимает единственный сценарий полной потери доступа. 2. **P1. Детект SSH-порта через `sshd -T` + `ssh.socket` + порт текущей сессии.** У нас `current_ssh_ports` уже есть, не хватает socket-юнита и правила «сессию всегда пускать». 3. **P2. logrotate на логи ноды + `SystemMaxUse` для journald.** Два маленьких файла, без нового кода. 4. **P2. MSS clamp + `rp_filter`/ecn** в `render_sysctl_profile`, за флагом. 5. **P2. Пер-IP лимиты** в `lib/firewall.sh` по образцу их `CONN_LIMIT`/`SYN_RATE` — но только как opt-in: на VPN-ноде легитимный клиент за CGNAT легко даёт тысячи коннектов. 6. **P2. Один сенсор в `check_state`**: фактический LISTEN-порт агента против разрешённого в правилах. Дешево и ловит реальный класс аварий. 7. **P2. Тест поведения nft-правил** в network namespace (или хотя бы прогон сгенерированного ruleset через `nft -f` в отдельном namespace). Этого нашей тестовой базе не хватает больше всего. **Не брать:** CrowdSec, SYNPROXY (они сами пишут «на VPN-relay избыточен»), fleet-sync через токен панели (у нас NetBird), anti-amplification, XPS/irqbalance, minisign (мы не раздаём `curl | bash`). --- # 2. lib4u/vnm **Что это.** Go-демон (14 тыс. строк без тестов, 85 файлов) — «базовый слой» ноды, независимый от того, какой VPN на ней крутится. Он не ставит Xray. Он решает три вещи на уровне ядра: - **egress-политика**: списки IP/доменов → `exit:warp` / `block` / `direct`, с fail-closed (умер WARP — трафик отклоняется, а не уходит напрямую); - **guard**: входящие с блок-листов режутся в `prerouting` до DNAT, то есть до Docker и до ufw; - **p2p**: блок торрентов сигнатурами (uTP SYN, DHT, UDP-tracker, BT-handshake) и опционально nDPId для шифрованного. Плюс свой DNS-резолвер, который кладёт адреса доменных списков в nft-наборы в момент ответа, режимы `observe → enforce` с `-auto-rollback 5m`, сверка ядра с планом (дрейф), метрики Prometheus. ## Чем они лучше нас — заметно 1. **Доменный роутинг, а не только CIDR.** У нас `remna_guard.py` и блоклисты — это IP-сети. У них `geosite:category-ru` + собственный резолвер, и правило срабатывает, даже когда сайт переехал на новый IP. Это принципиально другой уровень. 2. **Egress с проверкой здоровья.** Наш `warp.sh` ставит wgcf, один раз проверяет `warp=on` и всё. У них health-check каждые N секунд, перевыпуск регистрации при мёртвом выходе, fail-closed по умолчанию и `ip rule` в зарезервированном диапазоне приоритетов с уборкой за собой. 3. **Torrent-блок на уровне сети.** У нас в README честно написано: `protocol: bittorrent` руками не добавлять, это делает плагин панели. Но плагин видит только Xray. Если на ноде появится AmneziaWG или клиент пойдёт мимо прокси — у нас дырки нет вообще. Их слой режет и исходящее процессов ноды, и клиентов туннелей, и входящее от пиров. 4. **`observe` перед `enforce` + авто-откат по неподтверждению.** Это правильная схема для всего, что может отрезать доступ. У нас такого нет ни для файрвола, ни для SSH. 5. **Валидация списков.** У них `checksum` (или `checksum: none` **только** вместе с `bounds`), `max_change`, `refresh`, отказ принимать обрезанный файл или страницу ошибки. У нас в `remna_guard.py` есть кэш и «не применять, если пусто», но нет границ размера и процента изменения — то есть список, который внезапно пришёл на 3 записи, мы применим. 6. **Дрейф и метрики.** Агент каждые несколько секунд возвращает то, что кто-то поправил руками, и показывает это в `status`. Наш guard применяется таймером раз в сутки и молча живёт с тем, что осталось. 7. **Атомарная замена таблицы** одной транзакцией + `vnm-boot` восстанавливает состояние до подъёма сети. У нас при ребуте правила поднимает systemd-юнит — нормально, но при сбое применения состояние и таблица могут разъехаться (мы это как раз чинили в `remna_guard.py`). ## Чем мы лучше - Мы ставим ноду: decoy, nginx, сертификаты, ACME, Docker, регистрация в панели, NetBird. vnm этого не делает вообще и не собирается. - У нас shell + один Python-файл, читается и правится на сервере. У них 14 тыс. строк Go, которые надо собирать и обновлять бинарником (они это признают: «сначала бинарник, потом конфиг»). - Их guard не знает про SSH-порты и allowlist так, как наш: у них `exempt` — ручной список адресов. Наш `collect_allow` собирает SSH-порты и панель сам. - Их `p2p` требует отдельно собранный nDPId под GPL-3.0, которого в репозитории нет. Без него — только сигнатуры. ## Что взять в rebuild 1. **P1. Проверку здоровья WARP + перевыпуск.** Самое ценное. Наш `warp_install` проверяет один раз; если Cloudflare отозвал ключ, нода тихо ходит напрямую. Минимум: таймер раз в 5 минут, `curl --interface warp`, при провале — `wgcf` re-register и запись в лог. ~30 строк. 2. **P2. Границы и `max_change` для блоклистов** в `remna_guard.py`: `min/max` записей и «не применять, если изменилось больше N%». Это 10 строк и закрывает тихий сценарий «источник отдал заглушку». 3. **P2. `observe`-режим для guard** (считать, но не дропать) и только потом `enforce`. У нас блоклист либо включён, либо нет — проверить, что он не режет живых клиентов, нечем. 4. **P3. Torrent-блок как отдельный opt-in слой** — хотя бы сигнатуры `bt_handshake` + `utp_syn` + `dht` в `prerouting`/`output`. Это дешевле, чем nDPId, и закрывает претензии хостера, которые плагин панели не закрывает. 5. **P2. `exempt`-список** (панель, мониторинг, NetBird-адреса) как единая точка для guard, файрвола и p2p. У нас это размазано по трём местам. 6. **P3. Метрики в textfile-формате для node_exporter** — если/когда появится мониторинг. **Не брать:** собственный DNS-резолвер и доменный роутинг (это отдельный продукт, у нас роутинг живёт в панели), nDPId, WARP+ лицензии, миграцию чужого WARP (нам нечего мигрировать), Go-демон целиком. --- # 3. nuver-labs/vps-audit **Что это.** Один bash-скрипт на 812 строк, MIT, read-only аудит Debian/Ubuntu. Проверяет SSH (root login, пароль, нестандартный порт), файрвол (ufw/firewalld/iptables/nftables), fail2ban/CrowdSec, неудачные входы, обновления, запущенные сервисы, открытые порты, sudo-логирование, политику паролей (`pwquality.conf`), SUID-файлы, диск/память/CPU/соединения и печатает отчёт с рекомендациями. ## Чем они лучше - **Сверка порта jail'а fail2ban с фактическим SSH-портом.** Это ловит классику: порт сменили, jail остался на 22, баны не работают, а статус «fail2ban active». У нас такой проверки нет — мы пишем jail при установке и больше не сверяем. - **sudo-логирование и SUID-файлы** — две вещи, которых у нас нет вообще. SUID-дрифт полезен как дешёвый датчик компрометации. - Отчёт отдельным действием, без побочных эффектов. У нас `--check` частично лезет в конфиг и зависит от роли. ## Чем мы лучше - Мы знаем Remnawave: проверяем контейнеры, сертификаты, decoy, порт ноды. Они проверяют только ОС и ничего не понимают про наш стек. - У нас есть исправление, у них только отчёт. - У нас тесты, у них их нет. ## Что взять 1. **P2. В `check_state` (host):** фактический порт в `jail.d/remnawave.local` против `sshd -T`, и «jail включён» против «jail реально работает» (`fail2ban-client status sshd`). 2. **P3. Проверку SUID-дрифта** относительно снимка, сделанного при установке. Дешево, но требует хранения снимка — отдельная задача. **Не брать:** весь скрипт, `pwquality`, «нестандартный порт» как рекомендацию (у нас порт задаётся явно). --- # 4. NNN706/M3T **Что это.** Не скрипты, а набор шаблонов и данных (1,8 тыс. строк): Xray-профили `VLESS-RAW-Reality(Selfsteal)`, `Balancer`, `Routing-(RU-Direct)`, `DNS`, `YouTube without ADS`, плюс исходные списки (`ASN.txt`, `IP.txt`, `domains.txt`, `sites.txt`) и `SubnetResolve.sh`. **Лицензии нет.** Копировать код нельзя. Сами списки — данные, но и на них явного разрешения нет. ## Чем полезно - Наши `templates/xray/` — это серверные профили для панели. M3T даёт то, чего у нас нет: примеры клиентского/панельного роутинга (RU-direct, YouTube без рекламы), DNS-конфиг и балансировщик. - `SubnetResolve.sh` — идея резолва доменных списков в CIDR. Это ровно то, чего не хватает нашему guard'у, если когда-нибудь понадобятся домены. ## Чем хуже - Нет ни установщика, ни проверок, ни документации по применению. - Часть профилей завязана на конкретную версию Xray и панели. ## Что взять **P3.** Держать как справочник, когда будем собирать библиотеку панельных профилей. Ничего не копировать до выяснения лицензии; идеи (`RU-direct` отдельным профилем, DNS-объект, балансировщик) можно реализовать самостоятельно. --- # 5. gorecvpn/gorecshit **Что это.** MIT, 6,6 тыс. строк в двух файлах. Hardening ноды Remnawave: UFW + ipset, fail2ban (sshd + recidive), анти-скан, блоклист сканеров, sysctl/BBR, SSH-drop-in, стелс-хостнейм, `--check/--status/--rollback/ --refresh-lists/--dpi-check`, интерактивное меню. Сильные места реализации: - **Автодетект портов**: `NODE_PORT`/`APP_PORT` из `/opt/remnanode/.env`, клиентские TCP и UDP порты — из живых `inbounds` Xray, fallback на `ss`. - **Порт ноды только с IP панели**, остальное DROP. У нас так же (`fw_allow_from`), это подтверждение, что подход верный. - **Anti-probing только на NEW**, `ESTABLISHED,RELATED` всегда в обход — чтобы не убить датаплейн лимитами. У нас established тоже в обход, но лимитов на NEW нет. - **DOCKER-USER** для bridge-publish, без перезапуска Docker. - **Генерируемый `rollback.sh`** и бэкап всех файлов в `/root/hardening-backups//`. - **Зеркала блок-листов** (`raw.githubusercontent.com` → jsDelivr/Fastly) и never-block для панели, релеев, `$SSH_CLIENT`, private/bogon. - Перед включением файрвола показывает, **какие порты чужих программ закроются**. ## Чем хуже - UFW + iptables + ipset — legacy-стек. У нас nftables-native, это объективно чище и быстрее на больших наборах. - По умолчанию **не отключает** парольный и root-логин (сознательно, но слабее нашего drop-in). - Буферы фиксированные 64 МБ независимо от RAM — у нас профили, это лучше для 1 ГБ. - Нет сертификатов, decoy, панели, Docker-стека. Только защита. ## Что взять 1. **P2. Зеркала для источников блок-листов** и never-block панели/SSH — в `lib/guard.sh` и `remna_guard.py`. 2. **P2. Генерируемый `rollback.sh`** рядом с бэкапом: одна команда возвращает все изменённые файлы. У нас `backup_file` есть, команды отката нет. 3. **P3. `--dpi-check`** (проверка, не режет ли провайдер/хостинг нужные направления) — полезная диагностика, но не для установщика. 4. **P3. Показ «что закроется»** перед применением файрвола. У нас catch-all drop, и предупреждение о чужих слушателях было бы честным. **Не брать:** UFW/ipset-стек, фиксированные буферы, отказ от key-only. --- # 6. DigneZzZ/routing **Что это.** Не серверный проект. Готовые наборы правил маршрутизации для клиентов: mihomo (Clash.Meta), Xray/V2Ray, Happ, INCY, V2RayTUN. 32 тыс. строк YAML/JSON плюс `geoip.dat`/`geosite.dat`. Это результат сборки; скрипты лежат в отдельном `routing-build`. Лицензии нет. ## Чем полезно - Хорошее объяснение разницы `lite` и `full`: в `full` есть выжимка реестра РКН, без неё правило «все `.ru` напрямую» ломает заблокированные сайты в зоне `.ru`. - Мобильные профили: `find-process-mode: off` и rule-provider в формате `mrs` (двоичное дерево) вместо текста — меньше памяти на телефоне. - Готовые диплинки для Happ/INCY. ## Чем хуже / почему не нам - Это клиентская сторона. Наш `rebuild/` ставит панель и ноду; клиентские профили — не его работа. - Нет лицензии, копировать нельзя. - Нет скриптов сборки, только артефакты. ## Что взять **—.** Только как справка, если будем генерировать клиентские профили или заголовок `routing` в подписке. Для серверного репозитория — ничего. --- # 7. DigneZzZ/remnawave-scripts Подробный разбор — `repos.md` §32. Здесь только то, что важно для меню и приложения (см. приложение в конце). **Что это.** MIT, около 34 тыс. строк. Три глобальные команды: `remnawave`, `remnanode`, `selfsteal`. Ставятся одной строкой, дальше работают как CLI с подкомандами (`@ install`, `@ install-script`) и интерактивным меню. Есть самообновление, зеркала jsDelivr, EN/RU, бэкапы и миграция. ## Чем лучше нас - **Одна команда на роль**, а не «зайди в каталог и запусти скрипт». `remnanode status`, `remnanode update`, `remnanode logs` — это удобно и безопасно, потому что исключает запуск не того файла. - **Подкоманды + меню одновременно.** Скрипту можно сказать, что делать, а можно открыть меню. У нас `remna.sh` — только меню, автоматизации нет. - **Самообновление и зеркала.** На сервере, где GitHub недоступен, это спасает. - **Бэкап перед обновлением и проверка совместимости версий при восстановлении** — у нас бэкапа панели нет вообще. ## Чем мы лучше - Мы не монолит и не `curl | bash`: дерево файлов, которое можно прочитать и проверить. - У нас нет TLS-ALPN через `iptables REDIRECT 443 → 8443` (рвёт живые соединения), нет OCSP (Let's Encrypt его закрыл), Caddy не по умолчанию. - Наши cert-пути и decoy уже проверены тестами. ## Что взять 1. **P2. Обёртки-команды**: `remna host|panel|node|cert|kernel|status` как тонкие вызовы существующих скриптов, с меню при запуске без аргументов. Это переделка `remna.sh`, а не новый продукт. 2. **P2. Бэкап панели перед обновлением** (дамп Postgres + `.env` + compose) и команда восстановления с проверкой версии. 3. **P3. Зеркало для самообновления** — только если мы вообще начнём раздавать toolkit по URL. **Не брать:** монолит, `curl | bash` как основной путь, ALPN-redirect, OCSP, Caddy по умолчанию, бэкапы чужих продуктов (NetBird, WARP+Tor) как часть установщика. --- # 8. evgmahov-blip/remna-node-scripts **Что это.** Крупный установщик ноды (14,3 тыс. строк), основная цепочка — «REMNANODE NEXT». Умеет: нода + nginx, SelfSteal через общий `/dev/shm/nginx.sock`, VLESS Reality XHTTP и RAW на 443, **Hysteria2 на UDP/443**, комбинированный профиль, генерацию Config Profile и Host для панели, стабильную per-node XHTTP-подпись, RKN SAFE guard с rollback и self-heal (включён по умолчанию), BBR SAFE/HIGHLOAD, маскировочный сайт, backup/clean/reinstall, восстановление legacy-нод. Лицензии нет; внутри лежит `vendor/remna-next-source.tar.gz`. ## Чем лучше нас - **Hysteria2** — протокол, которого у нас нет вообще. - **Генерация Config Profile + Host для панели** — мы регистрируем ноду через API, но профиль/хост оператор создаёт руками. - **Списки закреплены на commit SHA + Git blob SHA**, проходят санитизацию CIDR, и при ошибке/пустом результате **не заменяют последний рабочий набор**. Это лучшая реализация из всего списка. - **Runtime repair**: починить отвалившийся cert-mount или guard, не переустанавливая ноду. - Чистка legacy-хвостов (Caddy, старые Remnanode, RKN) перед установкой. ## Чем хуже - Нет лицензии → код брать нельзя, только идеи. - `curl | bash` на конкретный commit, внутри — vendored tarball. Тяжело проверять. - Guard включается по умолчанию и тянет внешние списки — мы сознательно так не делаем. - Caddy-ветка legacy, много условной логики. ## Что взять 1. **P2. Закрепление списков по commit + digest и «keep last good»** — перенести в `remna_guard.py` вместе с `max_change`. 2. **P3. Runtime repair** как отдельную подкоманду (`remna node repair`): пересоздать сокет, проверить mount сертификата, перезапустить nginx, не трогая остальное. 3. **P3. Hysteria2** — только если появится запрос от клиентов. Это отдельный inbound, UDP/443, и он меняет профиль нагрузки. **Не брать:** vendored-код, Caddy, guard по умолчанию, автоприменение внешних списков без ревью. --- # 9. FrI3nd7/skipit-vps-node Уже разобран в `repos.md` §02. Добавить нечего: идеи сертификатных линий, переиспользования по покрытию/сроку, временного открытия 80 с маркером и `checkhost` мы уже забрали. Гигантский один файл — не наш путь. **Вердикт:** справочник, ничего нового. --- # 10. wasteprince/remnanode-xhttp-cleaner **Ответ на вопрос «нам нужно это или кастомное ядро уже пофикшено?»** Нет, не пофикшено. Это разные вещи: - Наш «кастомный» вариант — `ghcr.io/legiz-ru/remnanode-smux`, это **smux-мультиплексирование**, а не патчи памяти Xray. - Cleaner патчит **внутренности Xray**: очередь `uploadQueue` у XHTTP и закрытие UDP-сессий Hysteria. Пересобирает ядро из точного upstream-тега, подменяет бинарник **внутри уже существующего контейнера** и один раз перезапускает его. Compose/env/mounts/ports не меняет. **Что это лечит.** При ~18 тыс. соединений смешанного XHTTP+TCP Xray занимал 2,4–2,9 ГиБ RSS при 50 МиБ TCP-памяти cgroup: мусор в Go heap. Один Hysteria-listener с `udpIdleTimeout=600` держит тысячи коротких сессий достижимыми 10 минут. **Нужно ли нам.** При нашей заявленной нагрузке (~100 устройств на ноду) нет. Проблема начинается на порядок выше. Плюс цена: поддержка патча, привязка к версии Xray (≥26.6.x), перезапуск контейнера при установке и откате, compatibility gate на каждую новую версию. **Если понадобится:** брать не патч-пайплайн, а готовый образ/артефакт с фиксированным тегом, как мы уже делаем с `NODE_IMAGE`. Держать патч самим — худший вариант. **Что взять (P3):** идею compatibility gate — перед любой подменой ядра проверять структурные якоря и останавливаться **до первой записи**. --- # 11. g1tx/vpn-node-tuner **Что это.** MIT, 8,8 тыс. строк вместе с документацией. Bash-тюнер sysctl для Ubuntu 24.04, целевая машина — 1 vCPU / 1–2 ГБ. Профиль «balanced» по умолчанию, сохраняет текущие congestion control и qdisc (`fq`/`fq_codel`), включает pacing, MTU probing, `--diagnose`, `--revert`, тесты и **папку `docs/evidence` с JSON до/после** на чистом хосте. ## Чем лучше - **Измерения, а не только цифры.** У них лежат результаты замеров (burst, clean-host before/after), по которым видно, что дало эффект. Наши профили подобраны по расчёту, но не имеют такого журнала. - `--revert` возвращает состояние до первого применения. - CI гоняет тесты скрипта. ## Чем хуже - Только sysctl/очереди. Нет ZRAM/swap-логики, файрвола, сертификатов. - Одна ОС и один сценарий. - Меньше ручек, чем у нас (conntrack, reserved ports, IPv6 и т.д.). ## Что взять **P3.** Использовать их замеры как валидацию наших профилей: если на 1 vCPU/1 ГБ их буферы и `somaxconn` дают тот же результат, что наши, — значит мы не переразмерены. Скопировать структуру `docs/evidence` в наш репозиторий, если начнём мерить. --- # 12. nektona/vpn-node-tuner **Что это.** MIT, 3 тыс. строк. Интерактивное меню тюнинга sysctl для VPN-ноды: 4 профиля по RAM, ручной режим, swap, лимиты FD, диагностика, бэкапы и откат, RU/EN. Отдельно — **режим A/B**: профиль включается на время теста, сервер сам меряет соединение, показывает таблицу и спрашивает «вернуть / оставить», с автооткатом при Ctrl+C и обрыве SSH. ## Чем лучше - **A/B с автооткатом** — лучшая UX-идея из всех тюнеров. Это ровно то, чего не хватает нашей смене профиля: применил, проверил, не подтвердил — вернулось само. - Перед записью показывает таблицу «сейчас → станет». - Ключи, которые ядро не приняло, **удаляет из конфига**, а не оставляет мёртвыми. ## Чем хуже - Пишет в `/etc/sysctl.conf`, а не в `sysctl.d` — грязнее и конфликтует с чужими файлами. - Только sysctl/swap/FD; нет файрвола, cert, decoy. ## Что взять 1. **P2. A/B-режим для профилей** (в том числе для XanMod): применить, показать метрики, через N минут откатить, если не подтвердили. Ложится на `lib/profile.sh` и `remna.sh`. 2. **P2. Удаление отвергнутых ядром ключей** при применении sysctl — у нас `apply_sysctl_file` проверяет результат, но файл остаётся с мёртвой строкой. --- # 13. beqwes/begleq-autorwnode **Что это.** Один bash-скрипт (5,9 тыс. строк, лицензии нет): пакеты, swap, BBR, лимиты, Docker, UFW, fail2ban, Let's Encrypt, нода + nginx с заглушкой, проверка результата и **отчёт о состоянии при входе по SSH**. Помнит IP панели в `/opt/remnanode/panel_ip`, при повторном запуске предлагает оставить. ## Чем лучше - **MOTD-отчёт при логине**: состояние ноды видно сразу, без запуска команды. У нас такого нет. - Перед включением UFW показывает, **какие порты других программ закроются**. - Автооткрытие портов живых inbound'ов Xray при повторном запуске. - IP панели как состояние, а не как повторный вопрос. ## Чем хуже - UFW вместо nftables, менее строгая модель. - Нет тестов, нет лицензии. - Меньше проверок сертификата и decoy, чем у нас. ## Что взять 1. **P2. MOTD/SSH-баннер со статусом** (нода, сертификат, firewall, guard) — 20 строк, высокая польза для эксплуатации. 2. **P3. Предупреждение о чужих слушателях** перед применением catch-all drop. 3. **P3. Хранить IP панели в состоянии**, чтобы повторный запуск не требовал флага. У нас `PANEL_IP` обязателен каждый раз. **Не брать:** UFW-стек. --- # 14. xdeptu5/geo-routing-server **Что это.** MIT, 11,3 тыс. строк (с тестами), Python 3.12 в Docker. Сервер правил маршрутизации и гео-баз для Happ/Incy: по расписанию забирает свежие правила и `geoip.dat`/`geosite.dat`, подставляет ссылки на базы со своего домена, раздаёт по секретной HTTPS-ссылке и **обновляет правила в сквадах Remnawave через API**. ## Чем лучше - Закрывает клиентскую часть, которой у нас нет: доставка routing-правил и гео-баз. - Планировщик, кеш, подпись ссылки, интеграция с панелью. - Есть тесты процессоров. ## Чем хуже / почему не нам - Это отдельный сервис, не установщик ноды. - Требует домен, TLS, панельный токен, постоянного внимания. - Python-рантайм и своя БД/кеш. ## Что взять **P3.** Если когда-нибудь будем раздавать клиентам routing-профили — это готовый референс. В `rebuild/` не тащить: у панели уже есть subscription page и заголовок `routing`. --- # 15. raywari/ru-blocklist **Что это.** Только данные, 145 тыс. строк: доменные группы (Meta, Google, RU-Media, RU-unblocked, Streaming) в `.lst/.clash/.srs/.json` плюс Go-скрипты сборки. README нет, лицензии нет. ## Чем полезно - Готовые доменные группы для клиентского роутинга. - Формат `.srs` (двоичный) — то, что читает mihomo на слабых устройствах. ## Почему не нам - Домены не подходят для нашего inbound-guard: ему нужны IP/CIDR. - Нет лицензии. - Нет серверной части. **Вердикт: —.** Только как источник данных для клиентских профилей, и только после выяснения лицензии. --- # 16. UnRKN/ru-blocklist **Что это.** Доменные списки российских сервисов, «сливающих информацию об использовании VPN»: `.txt`, `.dat` (geoip/geosite), `happ-routing.json`, еженедельный `new_wl_domains_weekly.txt`. Лицензии нет. ## Чем полезно - Хороший источник для правила «эти домены — напрямую» на клиенте. - `.dat` можно подключить как `geosite`-категорию. ## Почему не нам - То же: домены, не IP. Для guard'а нужен резолвер (как у vnm) — это отдельный продукт. - Нет лицензии. - Списки меняются, нужен контроль размера и «keep last good». **Вердикт: —.** Данные для клиентской стороны, не для серверного установщика. --- # 17. anfixit/routerus **Что это.** MIT, 5 тыс. строк. Самый близкий к нашему `node_setup.sh` проект: `deploy-remnanode.sh`, `update-node.sh`, `check-node.sh`, `update-bot.sh`. VLESS Reality в трёх режимах (TCP/Vision, XHTTP `packet-up`, оба), `steal_oneself` через свой nginx, **детерминированный фейк-сайт от хэша домена**, случайный SSH-порт на флот, `ssh.socket` замаскирован, Docker из подписанного репозитория, секреты 600, zero-downtime SSL с renewal-hook, **watchdog реального inbound на 443**, ротация логов, UFW, генерация `config-profile.json`, набор панельных утилит (`panel-new-node.py`, `panel-remove-node.py`, `nodes-status.py`, `sub-check.py`, `happ-check.py`, `prom-add.py`, `install-node-exporter.sh`). ## Чем лучше нас - **Генерация Config Profile** для вставки в панель, с правами 600 и без приватного ключа в логе. У нас профиль создаёт оператор. - **Watchdog реального inbound**: коннект на 443, а не «контейнер жив». Наш `verify_node` проверяет сокет, сертификат, redirect и self-steal, но не делает полноценный TLS-хендшейк через Xray после старта. - **Детерминированный фейк-сайт**: одинаковый на ре-ране, разный между нодами (имена классов, порядок секций, шрифт). Наш decoy статичен. - **Случайный SSH-порт на флот** вместо константы — меньше фингерпринта. - **`update-node.sh`** — отдельная команда обновления уже развёрнутой ноды. - **Панельные утилиты** для флота: добавить/удалить ноду, статус, проверка подписки и Happ, Prometheus. ## Чем хуже - UFW вместо nftables. - Нет установщика панели и cert-менеджера нашего уровня. - Один большой скрипт на роль, тестов меньше. ## Что взять 1. **P1. End-to-end watchdog ноды**: после старта проверить TLS-хендшейк на 443 (и на порту XHTTP, если есть), а не только сокет и сертификат. Это ловит «контейнер жив, панель зелёная, Xray мёртв». 2. **P2. Генерация `config-profile.json`** (0600) при установке ноды — чтобы оператор вставлял готовый JSON, а не собирал вручную. 3. **P2. `update-node.sh`** как подкоманда: пересобрать compose/конфиг, не переустанавливая ноду. 4. **P3. Детерминированный decoy** от хэша домена — если захотим уйти от одинакового сайта на всех нодах. 5. **P3. Случайный SSH-порт** по умолчанию (с safety-таймером из п.1). **Не брать:** UFW, `curl | bash`, монолитный deploy. --- # 18. prettyleaf/remnanode-exporter **Что это.** MIT, Go, 8,6 тыс. строк. Читает Redis Streams панели (`EXPORT_TO_STREAM_ENABLED=true`), добирает из API то, чего в стримах нет (отчёты Torrent Blocker, HWID, справочники), обогащает IP через MaxMind GeoIP, складывает в ClickHouse и показывает в Grafana. Отвечает на вопрос «кто грузит ноду»: история по аккаунтам, страна/ASN, хостинг. ## Чем лучше - Поведенческая аналитика, которой у нас нет вообще. - Torrent Blocker отчёты и HWID в одном месте. - Готовые SQL-схемы, rollup'ы и дашборды. ## Чем хуже / почему не нам - Требует ClickHouse + Grafana + включённые стримы. Это отдельный инфраструктурный сервис. - Не про здоровье ноды: железо и порты — это другой экспортёр. ## Что взять **P3.** Только если появится мониторинг: это отдельный продукт, не часть установщика. Контракт стримов полезно знать (минимум панели 3.1.0). --- # 19. syvlech/remnawave-limiter Уже разобран в `repos.md` §20. GPL-3.0, Go, ограничение числа устройств через webhook панели. **Ответ на вопрос «18 и 19 различаются?»** Да, это разные классы: - **18 (exporter)** — аналитика: кто, откуда и сколько потребляет, история в ClickHouse, дашборды. - **19 (limiter)** — enforcement: не пустить больше N устройств на аккаунт, через webhook панели. Ни один не ставится на ноду. Для нас полезнее 19 (ограничение устройств — частая боль), но код GPL-3.0 брать нельзя; идеи уже зафиксированы в `repos.md`. **Вердикт:** справочник, ничего нового. --- # 20. kabebon/traffic-limiter **Что это.** Go-сервис поверх панели Remnawave, без лицензии. Даёт тарификацию «только белых нод»: при исчерпании белого лимита отрубаются только whitelist-ноды, обычные продолжают работать как fallback. Опционально лимит на basic-ноды. Работает самостоятельно, бота не модифицирует, может пересылать события в его webhook. HMAC-SHA256, poller, SQLite-состояние, ретраи. ## Может пригодиться? Только если появится продукт с тарифами «белые/обычные ноды». К установщику ноды отношения не имеет. Идеи, которые стоит запомнить: - HMAC на webhook + timestamp (у нас панельный API без webhook'ов). - Отдельное состояние (SQLite) и poller как fallback, если webhook потерялся. - «Не трогать код бота» — обновления не затирают правки. **Вердикт: P3.** Не сейчас; нет лицензии. --- # 21. lifeindarkside/Remnawave-Routing-update **Что это.** 475 строк Python, без лицензии. Микросервис: по интервалу или cron забирает routing-файл с GitHub и обновляет кастомный заголовок `routing` в настройках подписки и в каждом внешнем скваде панели. Кеш на каждый сквад отдельно, при отсутствии изменений ничего не делает. ## Чем полезно - Автоматическая свежесть заголовка `routing` — руками это забывается. - Независимое отслеживание подписки и сквадов. ## Чем хуже - Один источник, нет валидации содержимого (что это вообще deeplink, а не страница ошибки). - Нет лицензии. - Маленький сервис, который надо хостить и обновлять. **Вердикт: P3.** Идея на будущее, если начнём вести routing-заголовки. В `rebuild/` не тащить. --- # 22. Balbuto/safe-remnanode-setup **Что это.** Один скрипт (4,9 тыс. строк, без лицензии), три модуля: настройка сервера (BBR+Cake, профили SAFE/HIGHLOAD/AUTO, Docker, IPv6, UFW-менеджер), установка ноды (выбор версии Xray, SSL Cloudflare/Gcore/ standalone, selfsteal, логи + logrotate), RKN-Watcher (iptables+ipset, TSPUBLOCK/GOVIPS, **GeoIP-фильтрация по странам**, allow/deny IP и порты, systemd timer). Меню со статусом модулей в шапке. ## Чем лучше - **GeoIP-фильтрация по странам** — у нас нет. Полезно, если ноду атакуют из конкретных стран или нужно резать весь регион. - **logrotate** на логи ноды (у нас нет). - **Статус модулей в шапке меню** — дешёвая и понятная UX-деталь. - Выбор версии Xray при установке. - IPv6-выключатель с restore-скриптом. ## Чем хуже - UFW + iptables + ipset, а не nftables. - Нет лицензии. - Смешаны три чужих проекта, тестов нет. - Блоклисты применяются автоматически. ## Что взять 1. **P3. GeoIP allow/deny по странам** как opt-in в файрволе (nftables `meta iifname` + geoip-набор). Требует регулярного обновления баз — поэтому не P1. 2. **P2. logrotate** — уже есть в п.1 (node-accelerator), здесь подтверждение. 3. **P2. Статус в шапке меню** — при переделке `remna.sh`. **Не брать:** UFW/ipset, автоблоклисты. --- # 23. princeofscale/ru-remna-utils Уже разобран в `repos.md` §07. MIT, Python-сервисы подготовки VPS. Полезное — архитектура `BaseService` + `Executor(dry_run)` + `is_configured`: каждый шаг можно показать, пропустить и повторить. Вредное — SSH-hardening без запасного входа, UFW с ранним выходом, fail2ban на `auth.log`, Docker-репозиторий Debian на Ubuntu. **Вердикт:** справочник, ничего нового. Идея dry-run у нас уже есть. --- # 24. DenFiord/remnascripts Уже разобран в `repos.md` §06. MIT, 266 файлов: в основном **Bash + bats-тесты** (85 `.sh`, 44 `.bats`), Python только в части утилит — то есть «не на питоне» это как раз про него, меню можно смотреть спокойно. Самый качественный MIT-референс по сертификатам: SAN + цепочка + ключ, атомарный симлинк, откат при неудачном reload, проверка что таймер/хук включён, транзакционный firewall. **Вердикт:** справочник. Для меню — см. приложение. --- # 25. HikaruApps/remnanode-antiscan Уже разобран в `repos.md` §22. MIT, набор скриптов с `confirm.sh`, `rollback.sh`, `state.sh`, `rules.py`. Главное, что мы до сих пор **не** внедрили: - **safety timer + подтверждение доступности из другого канала**, иначе автоматический откат; - **shrink-guard для внешних списков** (внезапно укороченный список не принимается); - проверка эффективного состояния (`nginx -t` + реальный TLS-handshake), а не факта записи. **Вердикт:** P1 для safety timer, P2 для shrink-guard. Ничего нового относительно `repos.md`, но это второй независимый проект, который делает таймер — значит, пора. --- # 26. win64exe/remnawave-server-protect Уже разобран в `repos.md` §03. MIT, nftables + SSH + fail2ban, без сертификатов. Полезное — «не трогать чужое»: отдельная таблица, отдельный `jail.d`, бэкап, проверка фактического результата, явный отказ от рискованной настройки с записанной причиной. **Вердикт:** справочник, ничего нового. Мы уже в отдельной таблице. --- # 27. Flecksis/rkn-guard **Что это.** MIT, Go, 7,2 тыс. строк. Блокировка подсетей сканеров через `ipset` + `iptables`, с интеграцией в UFW (jump-правила, которые не теряются после `ufw reload`), статистикой, журналом, ручной блокировкой, обновлением списков, самообновлением, удалением и интерактивным меню. Есть тесты на ufw-jumps и ipset-команды, блокировки, атомарная запись. ## Чем лучше - **Аккуратная работа с UFW**: добавление/восстановление jump-правил после перезагрузки ufw. Это классическая ловушка, и они её закрыли. - Ручная блокировка IP из меню. - Статистика заблокированных подключений. - Полноценный uninstaller. ## Чем хуже - iptables + ipset — legacy. Наш guard уже nftables-native и в `prerouting`, то есть покрывает Docker. - IPv4-фокус. - Нет границ размера списков. ## Что взять 1. **P2. Ручная блокировка в нашем guard**: `remna-guard block ` / `unblock`, с отдельным набором, который переживает обновление списков. Сейчас есть только allow/allowlist. 2. **P3. Статистика дропов по источникам** в `status` (у нас есть счётчик таблицы, но не разбивка). **Не брать:** iptables/ipset, UFW-интеграцию (нам не нужна). --- # Приложение: меню и «приложение-управлялка» Вопрос был: переделать меню как у DigneZzZ, но не на Python, и вообще сделать приложение для управления сервером. ## Что я думаю про приложение **Не делать вторую панель.** Remnawave уже управляет пользователями, нодами, хостами и подписками. Приложение, которое редактирует то же состояние, будет с ним расходиться: два источника правды, гонки, непонятно, кто прав после сбоя. И это ещё один вход, который надо защищать. **Что реально отсутствует — консоль оператора хоста**, а не веб-панель: - установить/обновить панель и ноду; - показать статус: контейнеры, сертификат, файрвол, guard, диск, логи; - выпустить/продлить сертификат, разбанить IP; - сделать бэкап и восстановить; - обойти флот: «на всех нодах версия X». Это CLI/TUI. Ему не нужны ни БД, ни auth, ни свой TLS. Он работает по SSH и не может «утечь» как веб-приложение. **Если всё-таки веб:** начинать с read-only дашборда (статус + срок сертификата + последние логи) за существующей панельной аутентификацией, а действия оставить CLI. Полноценная управлялка с записью — отдельный продукт с своей моделью угроз; для парка из нескольких нод это не оправдано. ## Что сделать с меню (без Python) Взять UX-идеи, не код: 1. **Одна команда `remna`** с подкомандами: `remna host|panel|node|cert| kernel|status|backup`. Без аргументов — текущее меню. 2. **Статус в шапке**: роль, версия, сертификат (дней), firewall, guard, диск. Один вызов `--check --short`. 3. **Неинтерактивный режим** для каждой подкоманды — чтобы то же самое можно было вызвать из cron/Ansible. 4. **Меню на whiptail + текстовый fallback** у нас уже есть; добавить `fzf`, если установлен, — не обязательно. 5. **A/B и подтверждение для опасных действий** (SSH-порт, профиль, firewall): применил → проверил → подтвердил, иначе откат. Технически это остаётся Bash. `dialog`/`whiptail`/`fzf` — обёртки, не рантайм. Python не нужен; наш единственный Python-файл (`remna_guard.py`) оправдан тем, что делает то, что на shell писать больно (CIDR, HTTP, JSON). ## Чего не делать - Не тащить монолит DigneZzZ и `curl | bash`. - Не делать «панель поверх панели». - Не добавлять БД и веб-сервер ради статуса. --- # Итоговый список для rebuild ## P1 — закрыть риск 1. **Safety-таймер на SSH** (node-accelerator, antiscan, vnm): применить → подтвердить из новой сессии → иначе откат. **Готово:** `lib/ssh.sh`, `--confirm-ssh` / `--revert-ssh`. 2. **Детект SSH-порта** через `sshd -T`, `ssh.socket` и порт текущей сессии. **Готово:** `current_ssh_ports`, `ssh_socket_configure`. Ветка выбирается по состоянию юнита, а не по дистрибутиву: на Debian и Ubuntu 22.04 сокет неактивен и работает `sshd -T`. 3. **Здоровье WARP + перевыпуск** (vnm): таймер, проверка выхода, re-register (не чаще раза в час, чтобы заблокированный UDP не плодил аккаунты Cloudflare). Endpoint прибивается к IPv4: на dual-stack хосте `wg-quick` выбирает AAAA, а IPv6-UDP до WARP часто не работает. **Готово:** `lib/warp.sh`, `lib/warp_health.sh`, `--warp-health`. 4. **End-to-end watchdog ноды** (routerus): TLS-хендшейк на 443, а не «контейнер жив». **Готово:** `verify_node` + `check_state` проверяют HTTP-ответ API ноды, а не только открытый порт. ## P2 — эксплуатация 5. **logrotate + кап journald** (node-accelerator, Balbuto). **Готово:** `lib/logs.sh`, `JOURNALD_MAX_USE`. 6. **Границы и `max_change` для списков** (vnm, evgmahov) + keep last good. **Готово:** лимиты `MAX_SOURCES`/`MAX_BYTES`/`MAX_ENTRIES`, `MAX_BAD_RATIO`, отказ при сжатии больше чем вдвое (обход `--force`), атомарная замена только после `nft -c`. 7. **`observe`-режим guard** (vnm). **Готово:** `remna-guard mode observe`. 8. **MSS clamp, `rp_filter`, ecn** в sysctl-профиле. **Готово:** `--mss-clamp`, `--tunnel-tuning`. 9. **Пер-IP лимиты** как opt-in. **Готово:** `--conn-limit N`, `--syn-rate N`. 10. **Сенсор «порт агента vs правило файрвола»** в `check_state`. **Готово:** `lib/checks.sh`, `node_port_firewall_check`. 11. **Тест поведения nft-правил** в netns. **Готово:** `tests/test_nft.sh` (`unshare -n nft -c`; под обычным пользователем сам перезапускается через `unshare -rn`). 12. **Генерируемый `rollback.sh`** (gorecshit). **Готово:** `write_rollback_script` в `lib/common.sh`. 13. **MOTD со статусом** (begleq). **Готово:** `templates/motd.sh`, `lib/motd.sh`. 14. **Бэкап панели перед обновлением** (remnawave-scripts). Отложено вместе с обновлениями. 15. **A/B-режим профилей** (nektona). **Готово:** `lib/ab.sh`, `remna --ab-confirm|--ab-revert`. 16. **Подкоманды `remna` + статус в шапке** (remnawave-scripts, Balbuto). **Готово:** `remna host|panel|node|cert|kernel|status`, MOTD в шапке. 17. **Ручная блокировка IP** в guard (rkn-guard). **Готово:** `remna-guard block|unblock`, список `manual.list`. 18. **Проверка fail2ban jail vs SSH-порт** (vps-audit). **Готово:** `ssh_fail2ban_check`, валит `--check` при расхождении. 19. **Генерация `config-profile.json`** (routerus). Отложено до панели: зависит от схемы профиля и генерации REALITY-ключей. 20. **`update-node.sh`** как подкоманда. Отложено вместе с обновлениями. ## P3 — позже / отдельный продукт - Hysteria2, GeoIP по странам, torrent-блок, доменный роутинг, exporter/limiter, routing-сервер, клиентские профили, Xray-патчи памяти, A/B-метрики, зеркала самообновления. ## Не брать - UFW/iptables/ipset-стек, CrowdSec, SYNPROXY, nDPId, Go-демон vnm, vendored-код, `curl | bash`, вторую панель, Python ради меню.