Симптом «российские сайты идут, западные нет» бывает от нескольких разных поломок, и различаются они простыми проверками. Я бы шёл по порядку.
Сначала то, что стоит исключить первым: туннель на телефоне вообще поднят? Без VPN картина на мобильном выглядит ровно так же - российские сайты открываются, заблокированные нет. Проверяется за минуту: при включённом туннеле откройте любой сервис, показывающий ваш адрес. Видите адрес входного сервера - идём дальше. Видите адрес оператора - разбираться надо с клиентом, до серверов очередь ещё не дошла.
Если туннель поднят, следующий подозреваемый - плечо от входного сервера к выходному: по нему уходит всё, что не попало в список российских сетей. На входном сервере это awg show awg1. Нет свежего рукопожатия - копать здесь.
Теперь про ваш главный тезис. Вы пишете, что российского хостера обязали фильтровать не хуже мобильного оператора, и видите это на себе. Если зарубежный выход у вас сейчас не работает, а на это похоже, то вы и наблюдаете картину без него: трафик наружу остаётся в российском сегменте. И тут стоит уточнить, чего каскад не обещает. Он не выводит из-под фильтрации весь путь: и плечо от клиента ко входу, и связь между серверами идут по российской инфраструктуре. Он прячет от оператора то, куда вы в итоге идёте.
Про Hetzner я бы не спешил обобщать. У меня самого стенд на Hetzner, в Нюрнберге, тот же AmneziaWG, и он работает. На днях в обсуждении на гитхабе человек написал, что из семи развёрнутых серверов сразу заработали пять, и что лучше всего заходят немецкие адреса. Причину разброса он не показывал, так что доказательством это не назовёшь, но при одинаковой установке разница где-то в самих адресах или в маршрутах до них.
В двух вещах вы правы. Менять серверы утомительно, и это честная цена схемы. И если заблокирован сам выходной адрес, каскад его не спасёт: он делит трафик по назначению, прятать адрес выхода он не умеет.
Списка живых серверов у меня нет, и мне кажется, такой список протухнет быстрее, чем разойдётся по людям. Хотя мысль не пустая: полезнее был бы не перечень адресов, а наблюдения по хостерам с датами, чтобы видеть тенденцию.
Про платный VPN спорить не стану. Работает у вас с марта, значит работает.
Коротко по прямому вопросу: подтверждённого рецепта под МТС в Москве у меня нет, и мне такого никто не присылал.
Но, судя по описанию, вы чините не то. Авиарежим не трогает сервер: на его стороне за эти пару дней ничего не менялось. Он пересоздаёт подключение с вашей стороны, то есть даёт новый адрес и новую NAT-привязку у оператора.
Такое я уже видел в полевом тесте на МТС. Туннель на мобильном интернете отваливался, и лечился он не настройками, а как раз пересозданием подключения, тем же режимом полёта. Причина была не в DPI: у оператора истекает NAT-привязка для UDP, а телефон к этому моменту успел придушить фоновое приложение, и поддерживающие пакеты перестали идти. «Пара дней» на это похожа, примерно за такое время телефон убирает в спячку приложения, которыми не пользуются.
Не скажу, что параметры обфускации тут совсем ни при чём, от них может зависеть, сколько вы продержитесь. Но объяснить одними ими то, что лечится авиарежимом, не выходит.
Может, я и мимо. Но проверил бы сначала телефон, а не сервер. Если у вас Android: снять с клиента AmneziaWG ограничения батареи (в настройках приложения «Батарея» -> «Без ограничений») и проверить, не попал ли он в список усыпляемых. Если iPhone, скажите, там настройки другие. И в любом случае посмотрите в своём конфиге строку PersistentKeepalive: она должна быть, установщик по умолчанию ставит 33.
А чтобы понять, что вообще происходит, в момент, когда «умерло», зайдите на сервер и посмотрите:
sudo bash /root/awg/manage_amneziawg.sh stats
В своей строке смотрите на два поля: «Последний handshake» и счётчики «Получено»/«Отправлено». Это сильно сужает поиск:
рукопожатие старое и не обновляется - дело в самом подключении;
рукопожатие свежее, а счётчики стоят - подключение живо, а трафик не проходит. Это другая история.
Снаружи оба случая выглядят одинаково, «перестало работать», а чинятся по-разному. Поэтому сначала посмотреть, потом крутить.
Теперь про вашу оговорку, что с I1 = <r 48> не запускается даже с домашнего Wi-Fi. Дома мобильного DPI нет. Значит дело почти наверняка в самом изменении или в клиенте, а не в сети.
Первый вопрос, и он самый важный: какой у вас клиент на ПК и какой версии, приложение AmneziaVPN или отдельный AmneziaWG для Windows?
Поддержка I1 у клиентов разная. Про десктопный AmneziaVPN на macOS известно, что он I1 не понимает и виснет при подключении, а вот про сборку под Windows у меня данных нет вовсе. При этом судя по вашему же описанию, ваш клиент I1 в каком-то виде понимает: с длинной DNS-строкой он подключается. Значит интересна не поддержка вообще, а разница между двумя конкретными значениями.
Заодно три вещи, которые стоит проверить. Ни одна из них не роняет подключение, но тихо оставляет вас без маскировки, а это как раз то, за чем вы гоняетесь:
где вы правили I1 - в /etc/amnezia/amneziawg/awg0.conf или в /root/awg/awgsetup_cfg.init? Второй файл читается только при первой установке, дальше правка в нём молча ни на что не влияет;
регистр верхний? I1, не i1. Сам AmneziaWG строчную примет и будет работать, а вот перегенерация конфигов в установщике её не увидит, и клиенты получат конфиг вообще без I1;
после правки был systemctl restart awg-quick@awg0, потом sudo bash /root/awg/manage_amneziawg.sh regen <имя>, и переимпорт конфига на самом устройстве? Без последнего шага меняется только сервер, а устройство продолжает слать по-старому.
Если всё это соблюдено, а оно всё равно не поднимается на домашнем Wi-Fi, приложите обе строки I1, из awg0.conf и из клиентского конфига, и назовите клиент. Вот это интересно уже мне.
По вашему пункту (а), про подбор параметров. В установщике семь профилей операторов для diagnose --carrier, и МТС среди них нет вовсе. В таблице в ADVANCED строка про МТС есть, но она про Приморье и датирована маем, на Москву её переносить не стал бы.
Что по МТС всё-таки задокументировано, так это порт. МТС глушит нестандартный UDP, а 443/udp пропускает стабильно, потому что он выглядит как QUIC. Я это замерял в поле. Строго говоря, лечит оно другой симптом, «не подключается вообще», а не ваш, но проверить дёшево, и по МТС это единственное, что подтверждено.
Из свежего: в обсуждении #38 на гитхабе идёт живая проверка. Человек в соседней теме прислал параметры из официального приложения, которое у него проходит на Мегафоне в Москве, и I1 там оказался не случайными байтами, а собранным вручную DNS-ответом. Дальше по обратной связи. Один подставил это значение, и у него на Мегафоне стало подключаться за 20-30 секунд вместо никак, Билайн у него заработал раньше, как раз после переезда на 443. Другой пишет, что ему помогает I1 = <r 48>, оператора не называет. По МТС не отписался никто. И там же есть человек, у которого не помогло ни одно значение I1, а в итоге выяснилось, что с тем же конфигом не работает на Kamatera и работает на TimeWeb.
По пункту (б), про второй локальный сервер. Каскад делит трафик по назначению: российские сайты идут напрямую, остальное через заграницу. На то, как оператор видит канал до первого сервера, он не влияет, так что от вашей проблемы он сам по себе не лечит.
Если первый сервер ставить в России, для оператора картина меняется только в одном случае: если его адрес попадает в белый список оператора. Это конкретные сети и CDN, а не любой российский хостинг, и произвольный VPS в России вам тут ничего не даст. Это отдельная история, к обычному DPI она отношения не имеет, и на МТС я её не проверял.
Отвечайте лучше здесь, а не в личку: судя по обсуждениям, МТС в Москве сейчас не только у вас.
Хорошо, что вы про Legacy-совместимость конфигов прямо в статье написали. Добавлю, к чему это на практике - тем более выше уже про уникальность сигнатуры заговорили.
Обфускация в вашем Legacy-профиле (Jc/Jmin/Jmax, S1-S2, H1-H4) меняет форму и заголовки пакетов. Пассивный DPI, который ищет чистый WireGuard по сигнатуре, на такой профиль уже не среагирует. Но рукопожатие остаётся рукопожатием, просто в другой обёртке. А DPI умеет ещё и активно щупать: шлёт пробу и смотрит, как ответит сервер. Вот от этого и защищает CPS, параметры I1-I5, которых в Legacy-наборе нет. CPS подмешивает перед рукопожатием пакеты, снятые с настоящего протокола вроде QUIC или DNS, и прячет хендшейк за них. Причём это даже не 2.0: сам CPS появился ещё в 1.5, а 2.0 сверху доложил S3/S4 (паддинг cookie и data).
Докрутить CPS можно прямо в вашей схеме, awg-easy его поддерживает, просто сам не заполняет. I1-I5 прописывают руками в конфиге, сигнатуру снимают по инструкции Amnezia (new-amneziawg-selfhosted). Одна тонкость с регистром: именно I1, а не i1 - в wg-easy на этом был отдельный баг. И совпадать на сервере и клиенте I1-I5 не обязаны, это пакеты-обманки перед рукопожатием, а не его часть - для Legacy-сервера их вообще ставят только на клиенте, так в официальной инструкции и показано. WireSock, кстати, и 2.0, и CPS понимает, так что на клиенте затыка не будет.
Я сам делаю kernel-native установщик под Ubuntu и Debian, в том числе с ARM-сборками. Весь набор параметров AmneziaWG 2.0 он генерит сам на каждую установку, включая CPS: I1 ставится автоматически, а осмысленную сигнатуру под конкретный протокол при желании добавляют сверху. https://github.com/bivlked/amneziawg-installer . Подход другой, не панель в докере, просто ещё один вариант.
olegtsss, а тут и вкладывать ничего не нужно. AmneziaWG - это L3-VPN, обычный сетевой интерфейс: что в него попало, то и ушло в туннель, хоть SIP, хоть RTP. Под конкретный протокол ничего настраивать не надо. vless это тоже умеет - через dokodemo-door или tproxy заворачивает и произвольный TCP/UDP, только там это уже прокси-ядро с правилами маршрутизации, а у L3-туннеля всё прозрачно сразу.
Спасибо, полезный опыт. Баны эти обычно ловятся не потому, что схема каскадная, а потому, что сам туннель палится на открытом плече. Голый WireGuard или AWG без обфускации ТСПУ вычисляет и придушивает - а в каскаде он при этом или нет, уже неважно. Поэтому на входной сервер и ставится AmneziaWG 2.0 с обфускацией и рандомизацией длин, а не чистый WG. Панацеи это не даёт, известный IP российского VPS всё равно может примелькаться - и вот тут ваше прозрачное проксирование заходит уже с другой стороны, тоже рабочей.
Насчёт "профит только если продаёшь" не соглашусь. Каскад и для себя удобен: рунет идёт напрямую с российского IP (банки, госуслуги, всё что косо смотрит на заграничные адреса), а наружу уходит только остальное.
Хороший вопрос, и всё упирается в то, где решается маршрут. Будь задача просто выгнать весь трафик за границу, хватило бы и 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, когда адрес ещё живой. Так что главное найти живую подсеть, а с маскировкой дальше уже скрипт разберётся.
Симптом «российские сайты идут, западные нет» бывает от нескольких разных поломок, и различаются они простыми проверками. Я бы шёл по порядку.
Сначала то, что стоит исключить первым: туннель на телефоне вообще поднят? Без VPN картина на мобильном выглядит ровно так же - российские сайты открываются, заблокированные нет. Проверяется за минуту: при включённом туннеле откройте любой сервис, показывающий ваш адрес. Видите адрес входного сервера - идём дальше. Видите адрес оператора - разбираться надо с клиентом, до серверов очередь ещё не дошла.
Если туннель поднят, следующий подозреваемый - плечо от входного сервера к выходному: по нему уходит всё, что не попало в список российских сетей. На входном сервере это
awg show awg1. Нет свежего рукопожатия - копать здесь.Если и оно живо, дальше вариантов хватает: список российских подсетей мог не загрузиться, правила маркировки и маршрутизации не примениться, плюс MTU, NAT, DNS. Типовые случаи с проверками собраны тут: https://github.com/bivlked/amneziawg-installer/blob/main/CASCADE.md#trouble
Теперь про ваш главный тезис. Вы пишете, что российского хостера обязали фильтровать не хуже мобильного оператора, и видите это на себе. Если зарубежный выход у вас сейчас не работает, а на это похоже, то вы и наблюдаете картину без него: трафик наружу остаётся в российском сегменте. И тут стоит уточнить, чего каскад не обещает. Он не выводит из-под фильтрации весь путь: и плечо от клиента ко входу, и связь между серверами идут по российской инфраструктуре. Он прячет от оператора то, куда вы в итоге идёте.
Про Hetzner я бы не спешил обобщать. У меня самого стенд на Hetzner, в Нюрнберге, тот же AmneziaWG, и он работает. На днях в обсуждении на гитхабе человек написал, что из семи развёрнутых серверов сразу заработали пять, и что лучше всего заходят немецкие адреса. Причину разброса он не показывал, так что доказательством это не назовёшь, но при одинаковой установке разница где-то в самих адресах или в маршрутах до них.
В двух вещах вы правы. Менять серверы утомительно, и это честная цена схемы. И если заблокирован сам выходной адрес, каскад его не спасёт: он делит трафик по назначению, прятать адрес выхода он не умеет.
Списка живых серверов у меня нет, и мне кажется, такой список протухнет быстрее, чем разойдётся по людям. Хотя мысль не пустая: полезнее был бы не перечень адресов, а наблюдения по хостерам с датами, чтобы видеть тенденцию.
Про платный VPN спорить не стану. Работает у вас с марта, значит работает.
Добрый день.
Коротко по прямому вопросу: подтверждённого рецепта под МТС в Москве у меня нет, и мне такого никто не присылал.
Но, судя по описанию, вы чините не то. Авиарежим не трогает сервер: на его стороне за эти пару дней ничего не менялось. Он пересоздаёт подключение с вашей стороны, то есть даёт новый адрес и новую NAT-привязку у оператора.
Такое я уже видел в полевом тесте на МТС. Туннель на мобильном интернете отваливался, и лечился он не настройками, а как раз пересозданием подключения, тем же режимом полёта. Причина была не в DPI: у оператора истекает NAT-привязка для UDP, а телефон к этому моменту успел придушить фоновое приложение, и поддерживающие пакеты перестали идти. «Пара дней» на это похожа, примерно за такое время телефон убирает в спячку приложения, которыми не пользуются.
Не скажу, что параметры обфускации тут совсем ни при чём, от них может зависеть, сколько вы продержитесь. Но объяснить одними ими то, что лечится авиарежимом, не выходит.
Может, я и мимо. Но проверил бы сначала телефон, а не сервер. Если у вас Android: снять с клиента AmneziaWG ограничения батареи (в настройках приложения «Батарея» -> «Без ограничений») и проверить, не попал ли он в список усыпляемых. Если iPhone, скажите, там настройки другие. И в любом случае посмотрите в своём конфиге строку PersistentKeepalive: она должна быть, установщик по умолчанию ставит 33.
А чтобы понять, что вообще происходит, в момент, когда «умерло», зайдите на сервер и посмотрите:
sudo bash /root/awg/manage_amneziawg.sh statsВ своей строке смотрите на два поля: «Последний handshake» и счётчики «Получено»/«Отправлено». Это сильно сужает поиск:
рукопожатие старое и не обновляется - дело в самом подключении;
рукопожатие свежее, а счётчики стоят - подключение живо, а трафик не проходит. Это другая история.
Снаружи оба случая выглядят одинаково, «перестало работать», а чинятся по-разному. Поэтому сначала посмотреть, потом крутить.
Теперь про вашу оговорку, что с I1 = <r 48> не запускается даже с домашнего Wi-Fi. Дома мобильного DPI нет. Значит дело почти наверняка в самом изменении или в клиенте, а не в сети.
Первый вопрос, и он самый важный: какой у вас клиент на ПК и какой версии, приложение AmneziaVPN или отдельный AmneziaWG для Windows?
Поддержка I1 у клиентов разная. Про десктопный AmneziaVPN на macOS известно, что он I1 не понимает и виснет при подключении, а вот про сборку под Windows у меня данных нет вовсе. При этом судя по вашему же описанию, ваш клиент I1 в каком-то виде понимает: с длинной DNS-строкой он подключается. Значит интересна не поддержка вообще, а разница между двумя конкретными значениями.
Заодно три вещи, которые стоит проверить. Ни одна из них не роняет подключение, но тихо оставляет вас без маскировки, а это как раз то, за чем вы гоняетесь:
где вы правили I1 - в /etc/amnezia/amneziawg/awg0.conf или в /root/awg/awgsetup_cfg.init? Второй файл читается только при первой установке, дальше правка в нём молча ни на что не влияет;
регистр верхний? I1, не i1. Сам AmneziaWG строчную примет и будет работать, а вот перегенерация конфигов в установщике её не увидит, и клиенты получат конфиг вообще без I1;
после правки был systemctl restart awg-quick@awg0, потом
sudo bash /root/awg/manage_amneziawg.sh regen <имя>, и переимпорт конфига на самом устройстве? Без последнего шага меняется только сервер, а устройство продолжает слать по-старому.Если всё это соблюдено, а оно всё равно не поднимается на домашнем Wi-Fi, приложите обе строки I1, из awg0.conf и из клиентского конфига, и назовите клиент. Вот это интересно уже мне.
По вашему пункту (а), про подбор параметров. В установщике семь профилей операторов для diagnose --carrier, и МТС среди них нет вовсе. В таблице в ADVANCED строка про МТС есть, но она про Приморье и датирована маем, на Москву её переносить не стал бы.
Что по МТС всё-таки задокументировано, так это порт. МТС глушит нестандартный UDP, а 443/udp пропускает стабильно, потому что он выглядит как QUIC. Я это замерял в поле. Строго говоря, лечит оно другой симптом, «не подключается вообще», а не ваш, но проверить дёшево, и по МТС это единственное, что подтверждено.
Из свежего: в обсуждении #38 на гитхабе идёт живая проверка. Человек в соседней теме прислал параметры из официального приложения, которое у него проходит на Мегафоне в Москве, и I1 там оказался не случайными байтами, а собранным вручную DNS-ответом. Дальше по обратной связи. Один подставил это значение, и у него на Мегафоне стало подключаться за 20-30 секунд вместо никак, Билайн у него заработал раньше, как раз после переезда на 443. Другой пишет, что ему помогает I1 = <r 48>, оператора не называет. По МТС не отписался никто. И там же есть человек, у которого не помогло ни одно значение I1, а в итоге выяснилось, что с тем же конфигом не работает на Kamatera и работает на TimeWeb.
По пункту (б), про второй локальный сервер. Каскад делит трафик по назначению: российские сайты идут напрямую, остальное через заграницу. На то, как оператор видит канал до первого сервера, он не влияет, так что от вашей проблемы он сам по себе не лечит.
Если первый сервер ставить в России, для оператора картина меняется только в одном случае: если его адрес попадает в белый список оператора. Это конкретные сети и CDN, а не любой российский хостинг, и произвольный VPS в России вам тут ничего не даст. Это отдельная история, к обычному DPI она отношения не имеет, и на МТС я её не проверял.
Отвечайте лучше здесь, а не в личку: судя по обсуждениям, МТС в Москве сейчас не только у вас.
Хорошо, что вы про Legacy-совместимость конфигов прямо в статье написали. Добавлю, к чему это на практике - тем более выше уже про уникальность сигнатуры заговорили.
Обфускация в вашем Legacy-профиле (Jc/Jmin/Jmax, S1-S2, H1-H4) меняет форму и заголовки пакетов. Пассивный DPI, который ищет чистый WireGuard по сигнатуре, на такой профиль уже не среагирует. Но рукопожатие остаётся рукопожатием, просто в другой обёртке. А DPI умеет ещё и активно щупать: шлёт пробу и смотрит, как ответит сервер. Вот от этого и защищает CPS, параметры I1-I5, которых в Legacy-наборе нет. CPS подмешивает перед рукопожатием пакеты, снятые с настоящего протокола вроде QUIC или DNS, и прячет хендшейк за них. Причём это даже не 2.0: сам CPS появился ещё в 1.5, а 2.0 сверху доложил S3/S4 (паддинг cookie и data).
Докрутить CPS можно прямо в вашей схеме, awg-easy его поддерживает, просто сам не заполняет. I1-I5 прописывают руками в конфиге, сигнатуру снимают по инструкции Amnezia (new-amneziawg-selfhosted). Одна тонкость с регистром: именно I1, а не i1 - в wg-easy на этом был отдельный баг. И совпадать на сервере и клиенте I1-I5 не обязаны, это пакеты-обманки перед рукопожатием, а не его часть - для Legacy-сервера их вообще ставят только на клиенте, так в официальной инструкции и показано. WireSock, кстати, и 2.0, и CPS понимает, так что на клиенте затыка не будет.
Я сам делаю kernel-native установщик под Ubuntu и Debian, в том числе с ARM-сборками. Весь набор параметров AmneziaWG 2.0 он генерит сам на каждую установку, включая CPS: I1 ставится автоматически, а осмысленную сигнатуру под конкретный протокол при желании добавляют сверху. https://github.com/bivlked/amneziawg-installer . Подход другой, не панель в докере, просто ещё один вариант.
olegtsss, а тут и вкладывать ничего не нужно. AmneziaWG - это L3-VPN, обычный сетевой интерфейс: что в него попало, то и ушло в туннель, хоть SIP, хоть RTP. Под конкретный протокол ничего настраивать не надо. vless это тоже умеет - через dokodemo-door или tproxy заворачивает и произвольный TCP/UDP, только там это уже прокси-ядро с правилами маршрутизации, а у L3-туннеля всё прозрачно сразу.
Спасибо, полезный опыт. Баны эти обычно ловятся не потому, что схема каскадная, а потому, что сам туннель палится на открытом плече. Голый WireGuard или AWG без обфускации ТСПУ вычисляет и придушивает - а в каскаде он при этом или нет, уже неважно. Поэтому на входной сервер и ставится AmneziaWG 2.0 с обфускацией и рандомизацией длин, а не чистый WG. Панацеи это не даёт, известный IP российского VPS всё равно может примелькаться - и вот тут ваше прозрачное проксирование заходит уже с другой стороны, тоже рабочей.
Насчёт "профит только если продаёшь" не соглашусь. Каскад и для себя удобен: рунет идёт напрямую с российского IP (банки, госуслуги, всё что косо смотрит на заграничные адреса), а наружу уходит только остальное.
Хороший вопрос, и всё упирается в то, где решается маршрут. Будь задача просто выгнать весь трафик за границу, хватило бы и 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, когда адрес ещё живой. Так что главное найти живую подсеть, а с маскировкой дальше уже скрипт разберётся.