Хороший вопрос, и всё упирается в то, где решается маршрут. Будь задача просто выгнать весь трафик за границу, хватило бы и DNAT (rinetd тут мимо, он про TCP). Но каскад ради другого: российское идёт напрямую с российского IP, а за границу уходит только остальное. Вот на этом проброс и ломается.
Пробросом клиентский UDP уходит на зарубежный сервер как есть, зашифрованным. На входе внутрь не заглянуть, адресов назначения не видно, и развилку "это русское, это нет" там не сделать. Плюс туннель в итоге терминирует уже зарубежный AWG1, и российские сайты увидят иностранный IP, чего каскад как раз избегает.
Поэтому вход должен сам терминировать туннель. AWG0 расшифровывает трафик и уже по IP назначения решает: адреса из российских сетей (ipset из зоны ipdeny) отдаёт напрямую, остальное метит и заворачивает во второй туннель. Развилка живёт на входе, после расшифровки, а не на пробросе.
И второй узел тут не ради "двойной обфускации" одним протоколом, а как отдельный зарубежный выход для уже отобранного трафика, вместе с обратным путём. Плечо AWG0->AWG1 у меня тоже на AmneziaWG, и не для красоты: оно пересекает границу РФ, а обычный WG там ТСПУ, скорее всего, придушит, а то и заблокирует. Можно взять и другой маскирующий транспорт, тот же vless с reality, но не прямой заменой: по плечу идёт уже расшифрованный трафик, его надо занести в L3-туннель, а vless потребует ещё tun2socks. Одним DNAT это не собрать.
Про аппаратную разгрузку тут нюанс. WireGuard, а значит и AmneziaWG, шифрует на ChaCha20, а не на AES. Аппаратные ускорители в роутерах обычно заточены под AES для IPsec и ChaCha не трогают, так что так же разгрузить, как IPsec, не выйдет. Зато ChaCha ровно для того и выбирали, чтобы она быстро считалась на обычном процессоре без спецжелеза, так что на нормальном CPU само шифрование почти ничего не стоит.
В потолок упирается не оно, а обфускация: мусорные пакеты и маскировка заголовков идут поверх и только программно. На слабом железе, что одноядерная VPS, что слабый роутер, это и чувствуется, на приличном незаметно.
Насчёт overhead у прокси тоже не всё так однозначно. WireGuard у нас работает модулем ядра на L3, это обычно очень дёшево, а VLESS крутится в userspace. Где по факту меньше, зависит от нагрузки и реализации.
Маршрутизация на любом узле - честный плюс цепочек. В каскаде я её сознательно увёл на сервер: на клиентах ничего настраивать не надо, зато и гибкости меньше. Так что у прокси тут гибче, у каскада проще.
Тут не "интереснее", а разные инструменты под задачу, и VLESS я не принижаю. С Reality он отлично мимикрирует под обычный TLS на 443, часто устойчивее к серьёзному DPI и работает там, где режут UDP. Если он всё закрывает - хороший выбор.
По сути это разные вещи. AmneziaWG - L3-VPN на базе WireGuard: тянет весь трафик устройства, обычно быстрый и лёгкий, а сервер целиком поднимается установщиком. Гео-сплит при этом можно держать на самом сервере, и приложениям ничего настраивать не надо. VLESS чаще используют как прокси, где маршрутизация живёт на клиенте, хотя с TUN он тоже закрывает всё устройство.
Если совсем грубо: работает UDP и нужен простой быстрый VPN на всё устройство - AmneziaWG; давит UDP или важна незаметность под TLS - VLESS/Reality. Многие держат оба.
Ключи не слетают, да. Само обновление AmneziaWG идёт через репозиторий: apt update && apt upgrade ставит новую версию, модуль DKMS пересобирается сам, а конфиг и ключи при этом не трогаются. После обновления ядра модуль тоже пересобирается автоматически.
Если захочется переустановить поверх рабочего сервера, у установщика есть флаг --force - ключи сервера, список пиров и параметры обфускации сохраняются, а выданные клиенты подтягиваются из бэкапа.
И бэкап тут свой, встроенный, а не сторонний: команда manage_amneziawg.sh backup собирает в один архив серверный конфиг, клиентские конфиги, ключи и сроки, а restore разворачивает обратно. Так что перенос на другую машину или откат - без потери ключей.
Спасибо, что поделился, приятно, что неделю уже держится. Судя по описанию, дело как раз в хостерах и UDP: дешёвые площадки его частенько режут или зажимают, отсюда и отвалы каждые 10 минут на первом. Так что тут хостер под UDP важнее железа. Uptime Kuma в тему, а если рвёт после простоя - помогает PersistentKeepalive на туннелях, чтобы соединение не засыпало.
Спасибо! Тут вопрос в том, что именно делить. У wgtunnel деление по приложениям: какие приложения пускать в туннель, какие мимо. А внутри одного браузера так уже не разделишь - и российские, и зарубежные сайты пойдут одинаково, либо всё через VPN, либо всё напрямую.
Каскад делит по адресу назначения и делает это на сервере: рунет напрямую, остальное за границу, сразу во всех приложениях и без настройки на каждом устройстве. Список российских подсетей обновляется в одном месте, а не гигантским AllowedIPs на каждом телефоне. И весь трафик уходит в туннель, так что провайдер видит только его.
Если App split с одним VPS закрывает задачу - он проще, тут без вопросов. Каскад берут, когда нужно деление по назначению и сразу на все устройства.
Хорошая схема, спасибо что поделились. Если дома белый IP и провайдер не режет L2TP - так и правда проще: одна коробка, без аренды, да и рунет видит домашний адрес, а не датацентр. Честный плюс.
Статья скорее для другого старта: серый IP за CGNAT (у нас это сплошь и рядом) или когда нужен туннель, переживающий DPI. L2TP легко опознаётся и его нередко режут, а без IPsec он ещё и не шифрует. AmneziaWG на современном WireGuard, полегче в настройке и с обфускацией под блокировки. Так что не сложнее, а под другую задачу.
Метод рабочий, добавлю пару мест, где в такой переразметке легко словить сюрприз.
Первое - примонтировал новый диск в /opt/example, а старые данные из каталога не вычистил. Они не исчезнут, а спрячутся под маунтом и продолжат жрать место на корне - потом сидишь и гадаешь, почему / не освободился. И важен порядок: сервис должен стартовать уже после монтирования ФС, иначе успеет насыпать данных в пустой каталог под точкой монтирования. Надёжнее всего повесить в его юнит RequiresMountsFor=/opt/example.
Второе - место не вернулось после переноса. Чаще всего это процесс, который держит открытыми уже удалённые файлы: пока он жив, место не отдастся. lsof +L1 покажет виновника, помогает рестарт сервиса. Реже - снапшоты или зарезервированные под root блоки.
Про Тануки на 8 марта - точный пример: наплыв реальных заказов на графике легко принять за атаку. По логам вы это уже разбираете на уровне L7, добавлю пару сигналов ниже - они за минуту разводят атаку и всплеск нагрузки.
SYN-флуд видно сразу: ss -ntp state syn-recv | wc -l - если полуоткрытых соединений тысячи, это точно не покупатели набежали. Помогает дёшево - net.ipv4.tcp_syncookies=1, но именно от SYN-флуда, не от любого DDoS.
А ещё бывает так, что выглядит как атака, а это переполнение conntrack. conntrack -C против net.netfilter.nf_conntrack_max: таблица забита - новые соединения рубятся, сервер лежит, а трафик смешной. Тут не фильтры нужны, а поднять max и укоротить таймауты. И глянуть поток tcpdump-ом - однородный ли он.
У cron есть подлянка, про которую тут не сказали: он запускает задачу по расписанию, даже если прошлый запуск ещё не закончился. Медленный бэкап или скрипт, который иногда подвисает, за ночь наплодит десяток своих копий - они дерутся за диск и io, load улетает, а выглядит так, будто всё само сломалось.
Оборачиваю такие джобы в flock: flock -n /run/lock/myjob.lock -c ‘команда’ - пока первый не отработал, второй просто не стартует.
Кстати, поэтому systemd-таймеры, о которых выше писали, тут спокойнее: выполняющийся юнит таймер повторно не запустит, наложения нет из коробки. И рядом классика: у cron свой урезанный PATH, так что рабочая команда из crontab нередко падает с command not found, пока не пропишешь полный путь.
Да, 1280 уже низ, тут согласен - я и давал его только как крайний случай, если рвётся под нагрузкой, а не в простое. А keepalive на телефоне крутится в userspace, и если система рубит приложение в фоне, он может вообще не уходить - хоть 5, хоть 25. Так что сперва разрешить фон в настройках батареи, а keepalive уже потом: 25 обычно хватает, 5 - если NAT злой или роутер капризный.
Похоже, это телефон в фоне рубит туннель. На ПК такого нет, он не засыпает, а на телефоне гаснет экран, система режет фоновую работу VPN - связь отваливается и сама не поднимается, пока не переподключишься руками.
Зайди в настройки батареи, разреши приложению (amneziawg/Amnezia) работать без ограничений, и в конфиге поставь PersistentKeepalive = 25. Обычно после этого перестаёт отваливаться.
Если же рвётся не в простое, а сразу когда грузишь что-то тяжёлое - тогда дело не в этом, а в MTU, попробуй сбавить его в конфиге, например с 1280 до 1240.
По кластеру важный момент: RandomizedDelaySec - это рандомизация, а не координация. Задержка случайная и берётся заново при каждом срабатывании таймера, между узлами никак не согласована - два узла спокойно попадут в одно окно, и кворум всё равно уедет. Для кворума это не лечение, а лотерея.
Если надо железно по одному - либо выключить автоприменение и катить своим плейбуком (как выше с ansible), либо развести окна ребута по узлам, чтобы они физически не пересекались. В k8s для этого есть kured: держит кластерный лок и ребутит строго по одному, уважая PodDisruptionBudget (сам по себе PDB ребут ноды не сдержит - выше верно подметили).
А "моргание" одиночного сервера - это needrestart дёргает сервисы после апдейта библиотек. Если внезапный рестарт хуже отложенного, переведи его в list-only ($nrconf{restart} = ‘l’) и перезапускай в своё окно.
Хорошо расписано. На практике, правда, больнее всего не как оно грузится, а когда не грузится - вот пара вещей из жизни.
Классика: систему перенесли на другой гипервизор или сменили дисковый контроллер, и она больше не поднимается - падает в аварийный shell с «cannot mount root». Почти всегда это initramfs без нужного драйвера (virtio-scsi, nvme и подобное): ядро стартануло, а до диска достучаться нечем. Лечится из live или rescue - chroot и пересобрать initramfs (update-initramfs -u или dracut -f), проверив, что модуль реально попал внутрь.
Если грузится, но долго - systemd-analyze blame и critical-chain сразу показывают, какой юнит держит. Обычно какой-нибудь висящий *-wait-online или сетевой маунт, который ждёт таймаут.
Так в том и беда, что постоянного списка нет. Подсети у хостеров кочуют: сегодня диапазон чистый, через месяц уже в банах - потому и старые темы протухают, та с 2022-го на 4pda сейчас мало чем поможет. ntc.party посвежее, но туда ещё попасть надо.
Я бы на старте за списком и не гонялся. Поставить - минут пять, так что проще просто пробовать: поднял сервер, проверил пару минут. Не взлетело - не сиди весь вечер над конфигом, скорее всего дело в самом хостере, бери другую локацию или провайдера. Почасовая оплата у многих есть, попытка стоит копейки. И ещё: чем популярнее облако, тем хуже. Hetzner, OVH, DigitalOcean берут под VPN массово, их диапазоны чаще всего и оказываются в банах. Что-то поменьше и порегиональнее живёт дольше, хотя и внутри Hetzner иногда везёт на чистую подсеть - тут лотерея.
И сразу, чтобы время не терять: обфускация сама по себе бан по IP не лечит, это про другое - проскочить DPI, когда адрес ещё живой. Так что главное найти живую подсеть, а с маскировкой дальше уже скрипт разберётся.
Для одного устройства - да, клиентский AllowedIPs проще, я в статье так и пишу. «Сложно» в серверной схеме не для пользователя: всё один раз делается на сервере, а на клиенте только импортируешь конфиг.
Серверная схема - для семьи, когда устройств несколько. То раздельное туннелирование, про которое ты говоришь, есть в полном приложении Amnezia, а оно тяжёлое - тащит кучу протоколов. Его пришлось бы включать на каждом телефоне и держать список РФ-сетей свежим. На сервере это один раз через ipset, дальше список обновляется сам по расписанию. А устройствам достаётся лёгкий AmneziaWG-клиент (тот же amneziawg-android): импортировал конфиг и пользуешься, ничего не настраивая. То есть не сложнее - просто настройка переезжает с десятка клиентов в одну точку.
Знакомая ситуация. Бан за пару секунд - это не «трафик резали», а блок по хостеру: подсети Hetzner (да и других крупных - OVH, Aruba) давно в списках, новый VPS оттуда режут почти сразу. Выше верно подсказали. Лечится сменой площадки - на ntc.party и 4pda есть живые списки рабочих хостеров, Финляндия с Германией сами по себе ок, если конкретная подсеть чистая.
Для семейного копеечного не усложняй на старте: берёшь один такой сервер, ставишь скрипт одной командой (Linux знать не надо), поднимаешь на нём всех и раздаёшь QR на телефоны - уже рабочий семейный VPN. А деление «ru напрямую, остальное за бугор» живёт на сервере, не на каждом устройстве, так что вручную правила прописывать не нужно - это просто шаг второй, добавишь когда освоишься. Начать: https://github.com/bivlked/amneziawg-installer, про деление отдельно: https://github.com/bivlked/amneziawg-installer/blob/main/CASCADE.md
Апдейт по теме статьи: выкатил v5.17.0. Добавил в фаервол сервера MSS-clamp - он подрезает размер TCP-сегментов под MTU туннеля. Это убирает ровно ту болячку, про которую писал выше: когда на мобильном или в каскаде тяжёлые страницы и закачки виснут из-за того, что где-то по пути режется ICMP.
Спасибо, гляну на досуге. Только у нас разные истории: у вас, судя по Docker с панелью, роутер/файрвол с веб-мордой; у меня наоборот - голый kernel-native установщик под одну задачу, без докера и демонов, чтобы на копеечном VPS ничего лишнего не молотило. Так что не пересекаемся - скорее про разные сценарии. Удачи с проектом.
Прямо внутри LXC - нет. Я ставлю AmneziaWG модулем ядра через DKMS, а контейнер делит ядро с хостом и свой модуль загрузить не даёт. На Proxmox есть два рабочих пути:
Отдать VPN отдельную KVM-виртуалку. Там своё ядро, и скрипт отрабатывает ровно как на обычном VPS, без танцев с бубном. Я бы выбрал этот - проще всего.
Остаться в LXC, но ставить userspace-вариант amneziawg-go: модуль ядра ему не нужен, работает через /dev/net/tun. Мой инсталлятор этот путь не покрывает (он намеренно kernel-native ради скорости), но в ADVANCED.md есть ручной рецепт. Нужен privileged-контейнер либо unprivileged с проброшенным /dev/net/tun и CAP_NET_ADMIN, плюс nesting для iptables. По скорости хуже kernel-native, ориентир +30-50% CPU на гигабите.
Хороший вопрос, и всё упирается в то, где решается маршрут. Будь задача просто выгнать весь трафик за границу, хватило бы и DNAT (rinetd тут мимо, он про TCP). Но каскад ради другого: российское идёт напрямую с российского IP, а за границу уходит только остальное. Вот на этом проброс и ломается.
Пробросом клиентский UDP уходит на зарубежный сервер как есть, зашифрованным. На входе внутрь не заглянуть, адресов назначения не видно, и развилку "это русское, это нет" там не сделать. Плюс туннель в итоге терминирует уже зарубежный AWG1, и российские сайты увидят иностранный IP, чего каскад как раз избегает.
Поэтому вход должен сам терминировать туннель. AWG0 расшифровывает трафик и уже по IP назначения решает: адреса из российских сетей (ipset из зоны ipdeny) отдаёт напрямую, остальное метит и заворачивает во второй туннель. Развилка живёт на входе, после расшифровки, а не на пробросе.
И второй узел тут не ради "двойной обфускации" одним протоколом, а как отдельный зарубежный выход для уже отобранного трафика, вместе с обратным путём. Плечо AWG0->AWG1 у меня тоже на AmneziaWG, и не для красоты: оно пересекает границу РФ, а обычный WG там ТСПУ, скорее всего, придушит, а то и заблокирует. Можно взять и другой маскирующий транспорт, тот же vless с reality, но не прямой заменой: по плечу идёт уже расшифрованный трафик, его надо занести в L3-туннель, а vless потребует ещё tun2socks. Одним DNAT это не собрать.
Про аппаратную разгрузку тут нюанс. WireGuard, а значит и AmneziaWG, шифрует на ChaCha20, а не на AES. Аппаратные ускорители в роутерах обычно заточены под AES для IPsec и ChaCha не трогают, так что так же разгрузить, как IPsec, не выйдет. Зато ChaCha ровно для того и выбирали, чтобы она быстро считалась на обычном процессоре без спецжелеза, так что на нормальном CPU само шифрование почти ничего не стоит.
В потолок упирается не оно, а обфускация: мусорные пакеты и маскировка заголовков идут поверх и только программно. На слабом железе, что одноядерная VPS, что слабый роутер, это и чувствуется, на приличном незаметно.
Насчёт overhead у прокси тоже не всё так однозначно. WireGuard у нас работает модулем ядра на L3, это обычно очень дёшево, а VLESS крутится в userspace. Где по факту меньше, зависит от нагрузки и реализации.
Маршрутизация на любом узле - честный плюс цепочек. В каскаде я её сознательно увёл на сервер: на клиентах ничего настраивать не надо, зато и гибкости меньше. Так что у прокси тут гибче, у каскада проще.
Тут не "интереснее", а разные инструменты под задачу, и VLESS я не принижаю. С Reality он отлично мимикрирует под обычный TLS на 443, часто устойчивее к серьёзному DPI и работает там, где режут UDP. Если он всё закрывает - хороший выбор.
По сути это разные вещи. AmneziaWG - L3-VPN на базе WireGuard: тянет весь трафик устройства, обычно быстрый и лёгкий, а сервер целиком поднимается установщиком. Гео-сплит при этом можно держать на самом сервере, и приложениям ничего настраивать не надо. VLESS чаще используют как прокси, где маршрутизация живёт на клиенте, хотя с TUN он тоже закрывает всё устройство.
Если совсем грубо: работает UDP и нужен простой быстрый VPN на всё устройство - AmneziaWG; давит UDP или важна незаметность под TLS - VLESS/Reality. Многие держат оба.
Ключи не слетают, да. Само обновление AmneziaWG идёт через репозиторий: apt update && apt upgrade ставит новую версию, модуль DKMS пересобирается сам, а конфиг и ключи при этом не трогаются. После обновления ядра модуль тоже пересобирается автоматически.
Если захочется переустановить поверх рабочего сервера, у установщика есть флаг --force - ключи сервера, список пиров и параметры обфускации сохраняются, а выданные клиенты подтягиваются из бэкапа.
И бэкап тут свой, встроенный, а не сторонний: команда manage_amneziawg.sh backup собирает в один архив серверный конфиг, клиентские конфиги, ключи и сроки, а restore разворачивает обратно. Так что перенос на другую машину или откат - без потери ключей.
Спасибо, что поделился, приятно, что неделю уже держится. Судя по описанию, дело как раз в хостерах и UDP: дешёвые площадки его частенько режут или зажимают, отсюда и отвалы каждые 10 минут на первом. Так что тут хостер под UDP важнее железа. Uptime Kuma в тему, а если рвёт после простоя - помогает PersistentKeepalive на туннелях, чтобы соединение не засыпало.
Спасибо! Тут вопрос в том, что именно делить. У wgtunnel деление по приложениям: какие приложения пускать в туннель, какие мимо. А внутри одного браузера так уже не разделишь - и российские, и зарубежные сайты пойдут одинаково, либо всё через VPN, либо всё напрямую.
Каскад делит по адресу назначения и делает это на сервере: рунет напрямую, остальное за границу, сразу во всех приложениях и без настройки на каждом устройстве. Список российских подсетей обновляется в одном месте, а не гигантским AllowedIPs на каждом телефоне. И весь трафик уходит в туннель, так что провайдер видит только его.
Если App split с одним VPS закрывает задачу - он проще, тут без вопросов. Каскад берут, когда нужно деление по назначению и сразу на все устройства.
Хорошая схема, спасибо что поделились. Если дома белый IP и провайдер не режет L2TP - так и правда проще: одна коробка, без аренды, да и рунет видит домашний адрес, а не датацентр. Честный плюс.
Статья скорее для другого старта: серый IP за CGNAT (у нас это сплошь и рядом) или когда нужен туннель, переживающий DPI. L2TP легко опознаётся и его нередко режут, а без IPsec он ещё и не шифрует. AmneziaWG на современном WireGuard, полегче в настройке и с обфускацией под блокировки. Так что не сложнее, а под другую задачу.
Метод рабочий, добавлю пару мест, где в такой переразметке легко словить сюрприз.
Первое - примонтировал новый диск в /opt/example, а старые данные из каталога не вычистил. Они не исчезнут, а спрячутся под маунтом и продолжат жрать место на корне - потом сидишь и гадаешь, почему / не освободился. И важен порядок: сервис должен стартовать уже после монтирования ФС, иначе успеет насыпать данных в пустой каталог под точкой монтирования. Надёжнее всего повесить в его юнит RequiresMountsFor=/opt/example.
Второе - место не вернулось после переноса. Чаще всего это процесс, который держит открытыми уже удалённые файлы: пока он жив, место не отдастся. lsof +L1 покажет виновника, помогает рестарт сервиса. Реже - снапшоты или зарезервированные под root блоки.
Про Тануки на 8 марта - точный пример: наплыв реальных заказов на графике легко принять за атаку. По логам вы это уже разбираете на уровне L7, добавлю пару сигналов ниже - они за минуту разводят атаку и всплеск нагрузки.
SYN-флуд видно сразу: ss -ntp state syn-recv | wc -l - если полуоткрытых соединений тысячи, это точно не покупатели набежали. Помогает дёшево - net.ipv4.tcp_syncookies=1, но именно от SYN-флуда, не от любого DDoS.
А ещё бывает так, что выглядит как атака, а это переполнение conntrack. conntrack -C против net.netfilter.nf_conntrack_max: таблица забита - новые соединения рубятся, сервер лежит, а трафик смешной. Тут не фильтры нужны, а поднять max и укоротить таймауты. И глянуть поток tcpdump-ом - однородный ли он.
У cron есть подлянка, про которую тут не сказали: он запускает задачу по расписанию, даже если прошлый запуск ещё не закончился. Медленный бэкап или скрипт, который иногда подвисает, за ночь наплодит десяток своих копий - они дерутся за диск и io, load улетает, а выглядит так, будто всё само сломалось.
Оборачиваю такие джобы в flock: flock -n /run/lock/myjob.lock -c ‘команда’ - пока первый не отработал, второй просто не стартует.
Кстати, поэтому systemd-таймеры, о которых выше писали, тут спокойнее: выполняющийся юнит таймер повторно не запустит, наложения нет из коробки. И рядом классика: у cron свой урезанный PATH, так что рабочая команда из crontab нередко падает с command not found, пока не пропишешь полный путь.
Да, 1280 уже низ, тут согласен - я и давал его только как крайний случай, если рвётся под нагрузкой, а не в простое. А keepalive на телефоне крутится в userspace, и если система рубит приложение в фоне, он может вообще не уходить - хоть 5, хоть 25. Так что сперва разрешить фон в настройках батареи, а keepalive уже потом: 25 обычно хватает, 5 - если NAT злой или роутер капризный.
Похоже, это телефон в фоне рубит туннель. На ПК такого нет, он не засыпает, а на телефоне гаснет экран, система режет фоновую работу VPN - связь отваливается и сама не поднимается, пока не переподключишься руками.
Зайди в настройки батареи, разреши приложению (amneziawg/Amnezia) работать без ограничений, и в конфиге поставь PersistentKeepalive = 25. Обычно после этого перестаёт отваливаться.
Если же рвётся не в простое, а сразу когда грузишь что-то тяжёлое - тогда дело не в этом, а в MTU, попробуй сбавить его в конфиге, например с 1280 до 1240.
По кластеру важный момент: RandomizedDelaySec - это рандомизация, а не координация. Задержка случайная и берётся заново при каждом срабатывании таймера, между узлами никак не согласована - два узла спокойно попадут в одно окно, и кворум всё равно уедет. Для кворума это не лечение, а лотерея.
Если надо железно по одному - либо выключить автоприменение и катить своим плейбуком (как выше с ansible), либо развести окна ребута по узлам, чтобы они физически не пересекались. В k8s для этого есть kured: держит кластерный лок и ребутит строго по одному, уважая PodDisruptionBudget (сам по себе PDB ребут ноды не сдержит - выше верно подметили).
А "моргание" одиночного сервера - это needrestart дёргает сервисы после апдейта библиотек. Если внезапный рестарт хуже отложенного, переведи его в list-only ($nrconf{restart} = ‘l’) и перезапускай в своё окно.
Хорошо расписано. На практике, правда, больнее всего не как оно грузится, а когда не грузится - вот пара вещей из жизни.
Классика: систему перенесли на другой гипервизор или сменили дисковый контроллер, и она больше не поднимается - падает в аварийный shell с «cannot mount root». Почти всегда это initramfs без нужного драйвера (virtio-scsi, nvme и подобное): ядро стартануло, а до диска достучаться нечем. Лечится из live или rescue - chroot и пересобрать initramfs (update-initramfs -u или dracut -f), проверив, что модуль реально попал внутрь.
Если грузится, но долго - systemd-analyze blame и critical-chain сразу показывают, какой юнит держит. Обычно какой-нибудь висящий *-wait-online или сетевой маунт, который ждёт таймаут.
Так в том и беда, что постоянного списка нет. Подсети у хостеров кочуют: сегодня диапазон чистый, через месяц уже в банах - потому и старые темы протухают, та с 2022-го на 4pda сейчас мало чем поможет. ntc.party посвежее, но туда ещё попасть надо.
Я бы на старте за списком и не гонялся. Поставить - минут пять, так что проще просто пробовать: поднял сервер, проверил пару минут. Не взлетело - не сиди весь вечер над конфигом, скорее всего дело в самом хостере, бери другую локацию или провайдера. Почасовая оплата у многих есть, попытка стоит копейки. И ещё: чем популярнее облако, тем хуже. Hetzner, OVH, DigitalOcean берут под VPN массово, их диапазоны чаще всего и оказываются в банах. Что-то поменьше и порегиональнее живёт дольше, хотя и внутри Hetzner иногда везёт на чистую подсеть - тут лотерея.
И сразу, чтобы время не терять: обфускация сама по себе бан по IP не лечит, это про другое - проскочить DPI, когда адрес ещё живой. Так что главное найти живую подсеть, а с маскировкой дальше уже скрипт разберётся.
Для одного устройства - да, клиентский AllowedIPs проще, я в статье так и пишу. «Сложно» в серверной схеме не для пользователя: всё один раз делается на сервере, а на клиенте только импортируешь конфиг.
Серверная схема - для семьи, когда устройств несколько. То раздельное туннелирование, про которое ты говоришь, есть в полном приложении Amnezia, а оно тяжёлое - тащит кучу протоколов. Его пришлось бы включать на каждом телефоне и держать список РФ-сетей свежим. На сервере это один раз через ipset, дальше список обновляется сам по расписанию. А устройствам достаётся лёгкий AmneziaWG-клиент (тот же amneziawg-android): импортировал конфиг и пользуешься, ничего не настраивая. То есть не сложнее - просто настройка переезжает с десятка клиентов в одну точку.
Подробнее про серверную часть: https://github.com/bivlked/amneziawg-installer/blob/main/CASCADE.md
Знакомая ситуация. Бан за пару секунд - это не «трафик резали», а блок по хостеру: подсети Hetzner (да и других крупных - OVH, Aruba) давно в списках, новый VPS оттуда режут почти сразу. Выше верно подсказали. Лечится сменой площадки - на ntc.party и 4pda есть живые списки рабочих хостеров, Финляндия с Германией сами по себе ок, если конкретная подсеть чистая.
Для семейного копеечного не усложняй на старте: берёшь один такой сервер, ставишь скрипт одной командой (Linux знать не надо), поднимаешь на нём всех и раздаёшь QR на телефоны - уже рабочий семейный VPN. А деление «ru напрямую, остальное за бугор» живёт на сервере, не на каждом устройстве, так что вручную правила прописывать не нужно - это просто шаг второй, добавишь когда освоишься. Начать: https://github.com/bivlked/amneziawg-installer, про деление отдельно: https://github.com/bivlked/amneziawg-installer/blob/main/CASCADE.md
Апдейт по теме статьи: выкатил v5.17.0. Добавил в фаервол сервера MSS-clamp - он подрезает размер TCP-сегментов под MTU туннеля. Это убирает ровно ту болячку, про которую писал выше: когда на мобильном или в каскаде тяжёлые страницы и закачки виснут из-за того, что где-то по пути режется ICMP.
Всё на стороне сервера, клиентам ничего переделывать не надо. Подробности в релизе: https://github.com/bivlked/amneziawg-installer/releases/tag/v5.17.0
Спасибо, гляну на досуге. Только у нас разные истории: у вас, судя по Docker с панелью, роутер/файрвол с веб-мордой; у меня наоборот - голый kernel-native установщик под одну задачу, без докера и демонов, чтобы на копеечном VPS ничего лишнего не молотило. Так что не пересекаемся - скорее про разные сценарии. Удачи с проектом.
Прямо внутри LXC - нет. Я ставлю AmneziaWG модулем ядра через DKMS, а контейнер делит ядро с хостом и свой модуль загрузить не даёт. На Proxmox есть два рабочих пути:
Отдать VPN отдельную KVM-виртуалку. Там своё ядро, и скрипт отрабатывает ровно как на обычном VPS, без танцев с бубном. Я бы выбрал этот - проще всего.
Остаться в LXC, но ставить userspace-вариант amneziawg-go: модуль ядра ему не нужен, работает через /dev/net/tun. Мой инсталлятор этот путь не покрывает (он намеренно kernel-native ради скорости), но в ADVANCED.md есть ручной рецепт. Нужен privileged-контейнер либо unprivileged с проброшенным /dev/net/tun и CAP_NET_ADMIN, плюс nesting для iptables. По скорости хуже kernel-native, ориентир +30-50% CPU на гигабите.
Раздел про LXC: https://github.com/bivlked/amneziawg-installer/blob/main/ADVANCED.md#lxc-userspace-adv
Если пойдёте по userspace и упрётесь - заходите в Issues, разберёмся.