Свой VPN на одном заграничном сервере хорош, пока не открываешь российские сайты. Часть из них иностранные адреса просто не пускает - банки, Госуслуги, иногда стриминг. Остальные открываются, но с лишним крюком через заграницу и с чужим IP.
В прошлой статье я показал решение в общих чертах - каскад из двух серверов - и отправил за подробностями в гайд. Вопросы по схеме с тех пор приходят регулярно, так что вот полный разбор по шагам: как я собрал каскад и обо что спотыкался. Суть такая: клиент подключается к одному серверу, российский трафик уходит в интернет напрямую с него, а всё остальное - через второй сервер за границей. Одно подключение на телефоне, вся логика деления живёт на сервере. Это тот же сплит-туннелинг, только серверный: клиентам ничего настраивать не нужно.
Про авторство сразу: идею предложил один из пользователей установщика (glfenix на GitHub) в обсуждении проекта, я собрал схему на двух чистых серверах, погонял, поправил пару мест и довёл до пошаговой инструкции. Спасибо ему за разбор.
Что понадобится
-
Два VPS на чистом Debian 12/13 или Ubuntu 24.04/25.10, root на обоих.
Вход - в России или рядом: к нему подключаются клиенты, и российские сайты открываются с близкого адреса.
Выход - обычный зарубежный VPS.
Реальный публичный IP на обоих. Сервер за провайдерским NAT (CGNAT) на роль входа не годится - снаружи он недоступен. Быстрая проверка: адрес из
curl -s ifconfig.meсовпадает с адресом на интерфейсе (ip -4 addr). Отдельный случай Hetzner с приватным шлюзом разберу ниже, в граблях.IPv6 выключен - установщик так ставит по умолчанию. Каскад работает по IPv4, при включённом IPv6 трафик пойдёт мимо деления.
Разные подсети у серверов. У меня вход -
172.16.17.1/24, выход -172.16.61.1/24.
Как каскад делит трафик
Механику я подробно разбирал в прошлой статье, тут коротко, чтобы шаги были понятны. Сервер-вход смотрит на адрес назначения каждого пакета. Адрес в списке российских сетей - пакет уходит в интернет напрямую с входа. Нет - помечается меткой и уезжает через туннель на сервер-выход. Список российских сетей берётся из открытой зоны ipdeny и грузится в ipset. Клиенты добавляются на вход как обычно, manage add имя, на их стороне настраивать нечего.
Дальше - сборка.
Шаг 1. Ставим установщик на оба сервера
Оба сервера - обычные установки amneziawg-installer (он разворачивает AmneziaWG 2.0 с обфускацией и сразу настраивает файрвол). Ставим по основной инструкции и запускаем неинтерактивно с нужными подсетями:
# на сервере-выходе (заграница) bash install_amneziawg.sh --yes --disallow-ipv6 --route-all --subnet=172.16.61.1/24 # на сервере-входе (Россия или рядом) bash install_amneziawg.sh --yes --disallow-ipv6 --route-all --subnet=172.16.17.1/24
Установщик сам поднимает пересылку и NAT, так что серверный конфиг дальше править не нужно - скрипт маршрутизации добавит только то, чего нет. На входе доставим два пакета, которых может не быть на минимальном образе:
apt update && apt install -y curl ipset
Шаг 2. На выходе - клиент для входа
Сервер-вход будет подключаться к выходу как обычный клиент. Создаём его на выходе:
bash /root/awg/manage_amneziawg.sh add ru_host
Получаем файл /root/awg/ru_host.conf. Копируем его на вход любым способом (scp, буфер). Внутри - обычный клиентский конфиг: Endpoint (внешний IP выхода) и AllowedIPs = 0.0.0.0/0. Endpoint запомните, он понадобится в скрипте.
Шаг 3. На входе - туннель к выходу
Кладём этот конфиг на вход как /etc/amnezia/amneziawg/awg1.conf и правим две строки:
в секцию
[Interface]добавляемTable = off- чтобыawg-quickне прописывал маршруты сам, маршрутизацией займётся наш скрипт;строку
DNS = ...убираем, на сервере она не нужна.
Закрываем права и поднимаем туннель:
chmod 600 /etc/amnezia/amneziawg/awg1.conf systemctl start awg-quick@awg1 awg show awg1
В выводе awg show awg1 должна появиться строка latest handshake - связь с выходом есть. Пинг внутреннего адреса выхода на этом шаге не пройдёт, и это нормально: маршрут к нему появится в отдельной таблице на следующем шаге.
Шаг 4. Скрипт маршрутизации
Вся логика деления - один bash-скрипт на входе, /root/awg/awg-routing.sh. Он идемпотентный: можно запускать повторно, при каждом запуске он заодно обновляет список российских сетей. Целиком тащить его в статью не буду - в гайде по каскаду он лежит готовый и копируется как есть. Разберу суть по кускам.
Список российских сетей заливается в ipset через временный набор с атомарной подменой, чтобы не было окна, когда набор пуст:
ipset create ru hash:net -exist # ... заливаем сети из скачанного списка во временный набор ru_tmp ... ipset swap ru_tmp ru
Отдельная таблица маршрутизации и правило по метке: помеченный трафик уходит через туннель awg1.
ip route replace default dev awg1 table 100 ip rule add fwmark 0x1 table 100 priority 10000
Маркировка трафика клиентов: к российским сетям - напрямую (RETURN до метки), остальное помечаем. Порядок важен, RETURN стоит раньше MARK:
iptables -t mangle -I PREROUTING 1 -i awg0 -s 172.16.17.0/24 -m set --match-set ru dst -j RETURN iptables -t mangle -A PREROUTING -i awg0 -s 172.16.17.0/24 -j MARK --set-mark 0x1
И маршрут к самому выходу держим вне туннеля, иначе пакеты к нему закольцуются в awg1.
Два места в скрипте появились после того, как схема у меня ломалась. Первое: если список российских сетей не скачался и оказался пустым, скрипт останавливается с ошибкой, а не продолжает. Пустой ipset - тихая катастрофа: RETURN не ловит ничего, и весь трафик, включая российский, уходит за границу. Лучше явная ошибка, чем молча сломанное деление. Второе - про /32-шлюз, о нём ниже.
Вписываем в начало скрипта свою клиентскую подсеть и внешний IP выхода, дальше:
chmod +x /root/awg/awg-routing.sh bash /root/awg/awg-routing.sh
Шаг 5. Автозапуск после перезагрузки
Главная боль исходной схемы: после ребута маршруты не вставали, всё приходилось поднимать руками. Лечится одним systemd-юнитом, привязанным к обоим туннелям, - он стартует строго после них.
/etc/systemd/system/awg-routing.service:
[Unit] Description=Каскадный сплит-роутинг After=awg-quick@awg0.service awg-quick@awg1.service network-online.target Requires=awg-quick@awg0.service awg-quick@awg1.service Wants=network-online.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/root/awg/awg-routing.sh [Install] WantedBy=multi-user.target
systemctl daemon-reload systemctl enable awg-quick@awg1 awg-routing
Requires тут жёсткий: не поднялся туннель к выходу - не запустится и маршрутизация (клиенты подключатся, но без раздельного выхода, весь трафик пойдёт напрямую). Я специально ребутнул вход и проверил: туннели, таблица, список - всё встало само, без единого ручного действия.
Список российских сетей со временем меняется, поэтому раз в неделю юнит стоит перезапускать - заодно обновится и список:
echo '0 5 * * 1 root systemctl restart awg-routing' > /etc/cron.d/awg-routing-refresh
Проверка, что деление работает
Проще всего убедиться по счётчикам. На входе обнуляем их, с клиента создаём оба вида трафика и смотрим:
# на входе: обнулить счётчики iptables -t mangle -Z PREROUTING # на клиенте: зарубежный сайт (через выход) и российский адрес (напрямую) curl https://ifconfig.me # покажет внешний IP выхода ping -c3 77.88.55.242 # российский адрес (Яндекс) # на входе: счётчики покажут само деление iptables -t mangle -L PREROUTING -n -v # RETURN (match-set ru dst) <- пакеты к РФ выросли (напрямую) # MARK (MARK set 0x1) <- остальные выросли (через выход)
curl ifconfig.me с клиента показывает IP выхода, а счётчик RETURN растёт на российских адресах - каскад собран правильно. MTU, если что, отдельно занижать не пришлось: двойная инкапсуляция укладывается в стандартные размеры, десятимегабайтная передача через оба туннеля у меня прошла без потерь.
На чём я спотыкался
Тут то, обо что застревал я сам, и то, о чём писали люди, повторившие схему.
Весь трафик, включая российский, идёт через заграницу. Первым делом смотрим список РФ-сетей: ipset list ru | grep "Number of entries", там должно быть несколько тысяч (у меня около 8600). Ноль - список не скачался. На этот случай скрипт и останавливается с ошибкой, а не работает с пустым набором. Если www.ipdeny.com заблокирован у вашего провайдера, скрипт берёт снимок сетей из репозитория проекта.
Какой-то российский сайт всё равно открывается через заграницу. Деление идёт по IP назначения. Я на всякий случай проверил Госуслуги (вместе со входом через ЕСИА) и Сбербанк - их адреса есть в зоне ipdeny, то есть они уходят напрямую через вход и открываются нормально. Утекают через выход обычно сайты, которые физически стоят на зарубежном хостинге или за Cloudflare: их адрес иностранный, в список РФ-сетей не попадает, трафик к нему помечается и уходит на выход - и если сайт не пускает иностранные адреса, он не откроется. Проверить конкретный сайт просто: getent hosts имя.ru, затем по каждому адресу ipset test ru <адрес>. Адрес российский, но его нет в наборе - список у вас неполный или не докачался (см. пункт выше). Адрес зарубежный - это ожидаемо, лечится только на стороне самого сайта.
Google и YouTube тормозят, хотя выход зарубежный. Про это я коротко писал в прошлой статье: часть кэшей Google и YouTube стоит на российских адресах, попадает в список РФ-сетей и уходит напрямую через вход, поэтому Google видит российский IP. Подменой DNS это надёжно не лечится. Если нужно, чтобы Google всегда шёл через выход, его сети гонят на выход мимо RETURN - разбор с командами есть в гайде.
Отдача заметно ниже приёма. Бывает, что приём нормальный, а отдача проседает почти в ноль. На MTU и процессор грешить не спешите: MTU режет пакеты в обе стороны, тогда страдал бы и приём; процессор просадил бы обе стороны разом. Живой приём уже говорит, что вход отдаёт клиенту на скорости, значит узкое место - плечо вход -> выход, по которому уходит отдача наружу; приём это направление не использует. Мерить надо направленно: на выходе iperf3 -s, со входа iperf3 -c <IP выхода> (это отдача) и iperf3 -c <IP выхода> -R (приём). Низкая первая цифра при нормальной второй - душит участок между серверами, а не сами серверы: шейпинг исходящего у хостера входа, кривой пиринг до сети выхода или входной лимит на выходе.
Скрипт падает с Nexthop has invalid gateway. Это про хостеров вроде Hetzner: реальный публичный IP выдан как /32, а шлюз по умолчанию лежит вне подсети сервера (что-то вроде 172.31.1.1). Ядро не считает такой шлюз on-link и отвергает обычный маршрут. Лечится флагом onlink - свежая версия скрипта при такой ошибке сама повторяет добавление маршрута с ним, поэтому на Hetzner каскад просто работает. Но сначала убедитесь, что публичный IP действительно на сервере: адрес из ip -4 addr совпадает с curl -s ifconfig.me. Если на интерфейсе приватный адрес (10.x, 100.64.x), не равный внешнему, - это настоящий CGNAT, и вход снаружи недоступен.
IPv6 идёт мимо деления. Схема работает по IPv4. Если IPv6 включён, IPv6-трафик пойдёт в обход маркировки. Держите его выключенным, установщик так и ставит по умолчанию.
DNS уходит через выход. Клиентский DNS по умолчанию - Cloudflare, адреса зарубежные, поэтому сами DNS-запросы идут через сервер-выход, а уже полученные российские адреса - напрямую. Это штатно и на деление не влияет, просто не пугайтесь при диагностике.
Кому каскад не нужен
Если раздельный выход нужен только вам одному, каскад - перебор: проще задать список AllowedIPs прямо на клиенте (описано в ADVANCED проекта). Каскад оправдан, когда деление хочется держать на сервере и одинаково для всех, кто подключается. В сам установщик каскад намеренно не входит: несколько серверов - другой масштаб, в одном скрипте такому не место. Поэтому и отдельная инструкция.
Итог
Каскад из двух серверов собирается за вечер: две обычные установки, туннель между серверами, один скрипт маршрутизации и один systemd-юнит. Российские сайты после этого открываются напрямую с российского адреса, всё остальное уходит через зарубежный выход, и вся конструкция переживает перезагрузку сама.
Полный скрипт, пошаговый разбор и частые вопросы - в гайде по каскаду: https://github.com/bivlked/amneziawg-installer/blob/main/CASCADE.md
Зачем всё это и что ещё ломается в быту - в прошлой статье: https://habr.com/ru/articles/1051054/
Сам проект (установщик и управление): https://github.com/bivlked/amneziawg-installer
Комментарии (78)
AntonTP
07.07.2026 07:13Спасибо за интересную статью!
Какие преимущества этот вариант имеет перед использованием, например, клиента wgtunnel с включенной опцией App split tunneling и с одним vps?
lked Автор
07.07.2026 07:13Спасибо! Тут вопрос в том, что именно делить. У wgtunnel деление по приложениям: какие приложения пускать в туннель, какие мимо. А внутри одного браузера так уже не разделишь - и российские, и зарубежные сайты пойдут одинаково, либо всё через VPN, либо всё напрямую.
Каскад делит по адресу назначения и делает это на сервере: рунет напрямую, остальное за границу, сразу во всех приложениях и без настройки на каждом устройстве. Список российских подсетей обновляется в одном месте, а не гигантским AllowedIPs на каждом телефоне. И весь трафик уходит в туннель, так что провайдер видит только его.
Если App split с одним VPS закрывает задачу - он проще, тут без вопросов. Каскад берут, когда нужно деление по назначению и сразу на все устройства.
Rebeiro
07.07.2026 07:13неделю гоняю такой, все работает, единственное gateway падал раз в 10 минут, на хостере play2go.cloud, они там udp не очень любят, я особо не разбираюсь) повесил на другого зарубежного хостера, рвет раз в полдня наверно, вечером вчера правда отвалы были, хз с чем связано, с утра полет нормальный, поставил Uptime Kuma, сижу мониторю )))
lked Автор
07.07.2026 07:13Спасибо, что поделился, приятно, что неделю уже держится. Судя по описанию, дело как раз в хостерах и UDP: дешёвые площадки его частенько режут или зажимают, отсюда и отвалы каждые 10 минут на первом. Так что тут хостер под UDP важнее железа. Uptime Kuma в тему, а если рвёт после простоя - помогает PersistentKeepalive на туннелях, чтобы соединение не засыпало.
Hardoman
07.07.2026 07:13Play2go дно. Гарантий никаких, каналы деградирует регулярно, поддержка мертвая
olegtsss
07.07.2026 07:13Подскажите, чем интереснее использовать амнезию по сравнению с vless, который позволяет настроить точно так же все?
lked Автор
07.07.2026 07:13Тут не "интереснее", а разные инструменты под задачу, и VLESS я не принижаю. С Reality он отлично мимикрирует под обычный TLS на 443, часто устойчивее к серьёзному DPI и работает там, где режут UDP. Если он всё закрывает - хороший выбор.
По сути это разные вещи. AmneziaWG - L3-VPN на базе WireGuard: тянет весь трафик устройства, обычно быстрый и лёгкий, а сервер целиком поднимается установщиком. Гео-сплит при этом можно держать на самом сервере, и приложениям ничего настраивать не надо. VLESS чаще используют как прокси, где маршрутизация живёт на клиенте, хотя с TUN он тоже закрывает всё устройство.
Если совсем грубо: работает UDP и нужен простой быстрый VPN на всё устройство - AmneziaWG; давит UDP или важна незаметность под TLS - VLESS/Reality. Многие держат оба.
olegtsss
07.07.2026 07:13Vless позволяет выстроить цепочку прокси и решение по маршрутизации можно принимать на любом узле от клиента и далее. Удобно. Мне кажется, что у прокси решений должен быть меньше overhead. А мы может как-то аппаратно разгружать амнезию на роутере, как например некоторые железки позволяют делать аппаратный aes для VPN проколов?
lked Автор
07.07.2026 07:13Про аппаратную разгрузку тут нюанс. WireGuard, а значит и AmneziaWG, шифрует на ChaCha20, а не на AES. Аппаратные ускорители в роутерах обычно заточены под AES для IPsec и ChaCha не трогают, так что так же разгрузить, как IPsec, не выйдет. Зато ChaCha ровно для того и выбирали, чтобы она быстро считалась на обычном процессоре без спецжелеза, так что на нормальном CPU само шифрование почти ничего не стоит.
В потолок упирается не оно, а обфускация: мусорные пакеты и маскировка заголовков идут поверх и только программно. На слабом железе, что одноядерная VPS, что слабый роутер, это и чувствуется, на приличном незаметно.
Насчёт overhead у прокси тоже не всё так однозначно. WireGuard у нас работает модулем ядра на L3, это обычно очень дёшево, а VLESS крутится в userspace. Где по факту меньше, зависит от нагрузки и реализации.
Маршрутизация на любом узле - честный плюс цепочек. В каскаде я её сознательно увёл на сервер: на клиентах ничего настраивать не надо, зато и гибкости меньше. Так что у прокси тут гибче, у каскада проще.
olegtsss
07.07.2026 07:13Со всем согласен, наблюдаю у людей разные подходы (vless vs амнезия) к этому решению. Пока живы оба варианта, что хорошо.
eskars
07.07.2026 07:13Vless позволяет выстроить цепочку прокси и решение по маршрутизации можно принимать на любом узле от клиента и далее
Vless сам по себе никаких решений не принимает - это просто прокси протокол. Принимает решение ядро, чаще всего xray-core или sing-box, первое при этом даже позволяет поднять некоторое подобие амнезии с работающим сниффингом и маршрутизацией.
Hardoman
07.07.2026 07:13Скорость awg выше, если канал больше 100 Мбит, также vless раньше или позже опять заблочат по фигерпринтам. Это очень ненадолго решение
olegtsss
07.07.2026 07:13А awg в чем сильнее по fingerprint-ам?
Hardoman
07.07.2026 07:13Тем, что у него фингерпринта нет, а пакеты по длине рандомные. В том числе можно указать диапазон значений, который будет при каждом соединении разный.
olegtsss
07.07.2026 07:13Так задача часто выглядит как замаскироваться под легитимный трафик. И получается, что отсутствие фингерпринта это тоже признак. Так shadowsocks очень хорошо ни на что не похож, и лежит уже у многих операторов.
Hardoman
07.07.2026 07:13Легетимный трафик не содержит никакого фингерпринта. В инете ходят террабайты рамдомных udp пакетов, если их тронуть, то весь инет просто отключится.
olegtsss
07.07.2026 07:13Вы все верно говорите, но реализация дропов на последней миле +-1 происходит как раз принципу - не известное, значит в мусор или шейп. Между серверами и shadowsocks ходит.
Hardoman
07.07.2026 07:13Пока такая реализация валидна только для белых списков. А любой машрутизируемый пакет в общем случае чне важно, что у него внутри, будет доставлен в сеть назначения, если он не подходит ни под какое действующее правило. Иначе говоря, если вы напишете свой протокол, который будет прекрасно упаковываться в tcp/udp, то оно будет нормально смаршрутищировано. Когда настанет чебурнет, то будет не так, конечно
olegtsss
07.07.2026 07:13Нет, тут вы не правы. Shadowsocks туннели, которые ни на что не похожи, лежат. На каком точно участке блочат не скажу, между датацентрами все норм. А вот до пользака уже не долетают пакеты.
Hardoman
07.07.2026 07:13Скорее их всё-таки по паттерну адресно блочат :) ss умеет китайский fw блочить, значит и наши должны были слизать.
Я не вижу доказательств пока что, что это именно коверная блокировка всего неизвестного.
olegtsss
07.07.2026 07:13Было бы интересно послушать мнение сообщества, основанное на реальной практике. И в разных регионах и сетях.
eskars
07.07.2026 07:13Вы оба от части правы.
1) SS или vless + raw + encryption не блокируются сами по себе, т.к. не имеют отчетливого фингерпринта (за исключением native x25519, но сообщений о том, что он блокируется - я не встречал).
2) В некоторых случаях - пройдет только TLS. Пример - любая 16-20кб заблокированная ASN. К IP-адресам на этих ASN есть доступ исключительно по TLS с определенным servername, все остальное, включая SS будет отсекаться на 16кб
olegtsss
07.07.2026 07:13А в AGW можно вложить какую-нибудь sip телефонию? Или любой другой прикладной протокол. Потому что с vless это можно сделать, если прикладной протокол умеет проксироваться.
Barnaby
07.07.2026 07:13В реальном мире скорость vless выше, т.к. провайдеры не шейпят трафик и https у ни в приоритете.
Hardoman
07.07.2026 07:13В реальном мире любой udp быстрее tcp.
Barnaby
07.07.2026 07:13Тогда попробуй угадать, где тут xray а где awg 2.0 :)
Скрытый текст
Hardoman
07.07.2026 07:13Вероятно, в твоём случае это так. Но в общем случае - нет. awg 2.0 мне честные 590 Мбит отдает на 600 Мбитном канале. Ну и есть шареные порты на vps, надо не забывать, что там могут быть шумные соседи и вообще куча факторов. Но в этом случае, udp при нешумном канале будет летать, никаких проверок на лету там нет, только при установке сессии, поэтому накладных расходов нет на проверку tls
Barnaby
07.07.2026 07:13Это один и тот же сервер, тестил подряд и он выделенный. У сменя на всех впсках xray-vless+reality или быстрее или столько же, пинг только чуть выше. Я думаю это домашний провайдер так трафик приоритизирует, на 100 мбитах у меня тоже было подозрение, но на 600 оно стало особенно заметно.
Hardoman
07.07.2026 07:13Выделенный, это прям vds? Не vps? На vps порты шареные)
Возможно да, особенности домашнего isp. Ну или на роутере у вас QoS
protogonist
07.07.2026 07:13Единственный момент еще.... уважаемый @lked , а будет оно обновлять Амнезию при выходе новых версий? В родном их варианте, насколько мне известно, обновления не предусмотрены, что бы обновить на новую версию пакета, надо переустанавливать self-hosted, но там нет инструментов бэкапа, и слетают все выданные ключи. Есть вроде стороннее решение для бэкапа, но поставить не удалось.
lked Автор
07.07.2026 07:13Ключи не слетают, да. Само обновление AmneziaWG идёт через репозиторий: apt update && apt upgrade ставит новую версию, модуль DKMS пересобирается сам, а конфиг и ключи при этом не трогаются. После обновления ядра модуль тоже пересобирается автоматически.
Если захочется переустановить поверх рабочего сервера, у установщика есть флаг --force - ключи сервера, список пиров и параметры обфускации сохраняются, а выданные клиенты подтягиваются из бэкапа.
И бэкап тут свой, встроенный, а не сторонний: команда manage_amneziawg.sh backup собирает в один архив серверный конфиг, клиентские конфиги, ключи и сроки, а restore разворачивает обратно. Так что перенос на другую машину или откат - без потери ключей.
Hardoman
07.07.2026 07:13На мой взгляд очень сложно. Я год назад ещё реализовал схему каскада, где все идёт по умолчанию на русском хосте в дефолтный адаптер, а нужные ip диапазоны прописываются в allowedips клиента, котрырй апстримит в иностранный хост и роутинг работает через awg-quick автоматом. В список AllowedIPs адреса попадают баш скрипом.
Работает без нареканий
angelinacernaeva
07.07.2026 07:13Не у всех дома стоит кинетик или openwrt, чтобы там такие каскады городить. Серверная схема банально универсальнее
eskars
07.07.2026 07:13Клиенты уже давно умеют в маршрутизацию, причем сами конфигурации для маршрутизации могут приходить с внешней стороны, без участия пользователя. Спокойно можно отправить клиентам:
Youtube - > К серверу А в РФ с поднятым запретом
Российские ресурсы -> напрямую без туннеля
Все остальное - К серверу Б
Опционально - можно еще и failover прикрутить.
antspopov
07.07.2026 07:13Схема рабочая и уже есть готовый скрипт настройки на российской стороне. Работает georouting по dns. Amnezia при этом на обоих серверах настраивается штатным приложением amneziavpn
https://github.com/antspopov/awg-uplink
Terimoun
07.07.2026 07:13А потом ваш российский VPS хостер решает, что вы слишком много гоняете трафика и прикручивает вам канал до 10 мегабит
Rtttr
07.07.2026 07:13Xray подобные клиенты(v2rayng) умеют получать полный конфиг по ссылке, соответственно можно настроить конфиг с правилами маршрутизации для ru домена и тд.
Так и трафик для оператора будет размывается, а не только к одному узлу.
yuryby
07.07.2026 07:13Возник вопрос: а почему бы не пробросить udp-трафик через промежуточный сервер на зарубежный сервер через iptables (prerouting dnat и postrouting masquerade) на уровне ядра или через rinetd из юзерспейса (он грузит процессор, скорость низкая) без установки второй Амнезии? То есть обойтись только одной, редиректнув её по пути. Вариант с двумя обфускациями хорош, когда используются два разных протокола (например, Amnezia до первого датацентра и vless - от первого до второго), а тут лишь один.
lked Автор
07.07.2026 07:13Хороший вопрос, и всё упирается в то, где решается маршрут. Будь задача просто выгнать весь трафик за границу, хватило бы и DNAT (rinetd тут мимо, он про TCP). Но каскад ради другого: российское идёт напрямую с российского IP, а за границу уходит только остальное. Вот на этом проброс и ломается.
Пробросом клиентский UDP уходит на зарубежный сервер как есть, зашифрованным. На входе внутрь не заглянуть, адресов назначения не видно, и развилку "это русское, это нет" там не сделать. Плюс туннель в итоге терминирует уже зарубежный AWG1, и российские сайты увидят иностранный IP, чего каскад как раз избегает.
Поэтому вход должен сам терминировать туннель. AWG0 расшифровывает трафик и уже по IP назначения решает: адреса из российских сетей (ipset из зоны ipdeny) отдаёт напрямую, остальное метит и заворачивает во второй туннель. Развилка живёт на входе, после расшифровки, а не на пробросе.
И второй узел тут не ради "двойной обфускации" одним протоколом, а как отдельный зарубежный выход для уже отобранного трафика, вместе с обратным путём. Плечо AWG0->AWG1 у меня тоже на AmneziaWG, и не для красоты: оно пересекает границу РФ, а обычный WG там ТСПУ, скорее всего, придушит, а то и заблокирует. Можно взять и другой маскирующий транспорт, тот же vless с reality, но не прямой заменой: по плечу идёт уже расшифрованный трафик, его надо занести в L3-туннель, а vless потребует ещё tun2socks. Одним DNAT это не собрать.
BURAKKu
07.07.2026 07:13После 5 июня началась же борьба с каскадными - регулярно ловлю баны на 2 и 5 минут. Профит только если продаешь. Прозрачное проксирование позволяет не светить лишний раз адрес. Сделал схему специфическую,просто потестить, работает на удивление стабильно: клиент/роутер(запрет+варп прозрачный прокси) -> (сразу на сайты, если работает) / (на заграничный по любому протоколу, оборачиваеся все в MASQUE). Повозиться пришлось с изоляцией запрета, чтобы не ломать другой трафик
Sukesada
07.07.2026 07:13Если, как и я, вы не особо хотите платить за VPS больше необходимого, есть рабочая схема почти за копейки.
Я не из тех, кто пришёл в IT по красивой дорожке с дипломами, стажировками и HR-ангелами на фоне. По основной работе я охранник из “Пятёрочки”, а в инженерку, программирование, серверы и DevOps залез сам, чисто по кайфу. Учусь, пробую, ломаю, чиню, снова ломаю классический путь самоучки, только без глянца и пафосных историй успеха.
В России можно взять бесплатную VPS на Cloud.ru:
2 виртуальных ядра с ограничением до 10% CPU, 4 ГБ ОЗУ и 30 ГБ диска. По факту мне попалась свободная машина, которая спокойно работает 24/7 почти без ограничения по ядрам. Единственная обязательная плата около 150 ₽ в месяц за IP-адрес.Для Европы, США и других локаций можно использовать Oracle Cloud Free Tier. Там дают до 4 ARM-ядер, до 24 ГБ ОЗУ и до 200 ГБ диска. Ресурсы можно распределить как угодно: сделать одну мощную VPS или разделить на несколько машин, вплоть до четырёх. Плюс дают до 10 ТБ исходящего трафика, входящий трафик бесплатный, а ещё доступны два бесплатных IPV4.
В итоге можно собрать вполне приличный каскад из двух локаций, например США и Швейцария, и платить за всё около 150 ₽ в месяц.
Для домашней инфраструктуры, VPN, тестовых сервисов, мониторинга или небольших проектов более чем достаточно. Особенно если вы тоже учитесь сами и хотите не просто смотреть курсы, а руками поднимать реальные сервисы.
Sukesada
07.07.2026 07:13С регистрацией тоже не всё так страшно. За годы в Доте и других играх у меня появилось много знакомых из разных стран, так что при необходимости всегда можно найти человека, который поможет с регистрацией или проверкой сервиса в нужной локации.
Magnum72
Сложно все, я на домашнем роутере поднял VPN с учетом гео зон, на нем же поднял L2TP сервер и подключаюсь к нему со всех остальных устройств вне квартиры.
lked Автор
Хорошая схема, спасибо что поделились. Если дома белый IP и провайдер не режет L2TP - так и правда проще: одна коробка, без аренды, да и рунет видит домашний адрес, а не датацентр. Честный плюс.
Статья скорее для другого старта: серый IP за CGNAT (у нас это сплошь и рядом) или когда нужен туннель, переживающий DPI. L2TP легко опознаётся и его нередко режут, а без IPsec он ещё и не шифрует. AmneziaWG на современном WireGuard, полегче в настройке и с обфускацией под блокировки. Так что не сложнее, а под другую задачу.
Pavel7
Это настолько очевидная схема, что не очень понятно, какие плюсы в том, чтобы использовать какие-либо другие. Если у вас есть домашний роутер/сервер, то вся логика маршрутизации должна реализовываться именно на нём, как для внутренних, так и для внешних клиентов. Любой VPS (российский или зарубежный) - это исключительно выходная нода с минимальным набором сетевых настроек в виде VPN сервера (где клиент только один - домашний сервер) с NAT-ом и пробросом портов на домашний сервер, если у него серый ip. Любой VPS сервер в этой схеме в любой момент можно безболезненно заменить, а вся маршрутизация продолжит прекрасно работать.
Nyanny
А вам не кажется очевидным, что не у всех есть возможность на роутере что-то подобное делать?
Pavel7
Окей, заменим
на
Так пойдёт?
protogonist
Дома - это дома. Но у меня, например, данная схема отлично работает с билайном на телефоне, не надо постоянно тыкать вкл и откл на квн телефонном, что бы скопировать что то на сайте и переслать в телегу. Да, в курсе, что можно и на телефоне настроить, на яблоке даж через команды, что бы автоматом, но мне оказалось проще так.
Pavel7
А как схема с подключением через домашний сервер этому помешает? Имеется в виду, что телефон, попадая в домашнюю сеть, будет продолжать держать VPN туннель до домашнего сервера? Ну, если прям супер лень настроить автоотключение VPN по названию точки доступа, то можно просто сделать VPN сервер доступным и для внутренних клиентов с теми же настройками.
max9
на телефоне еще проще у 100% клиентов есть split tunnel по приложениям
WizarDX
На пк тоже есть. Я просто другой браузер использую для ру сайтов.
max9
холмс, зачем? geodat файлы давно придумали, непонимаю, почему в клиенте амнезии это до сих пор не реализовано
Alvi
на iOS нет сплит туннелинга по приложениям, это не дырявый Андроид, где приложения могут видеть. какие еще приложения запущены. Так что на iOS сплит обычно делают по адресам. Тому же Happ можно с сервера запушить правило маршрутизации по geoip (у меня так сделано, например).
KiddingBanana
Немного подушню, но устройства могут быть не только в домашней сети. Например, телефон на мобильном интернете, ноутбук, который с собой в рюкзаке. Да, можно пробросить туннель до домашней локалки и ходить через нее в интернет, но это звучит еще сложнее
Pavel7
Ну так об этом же я и сказал.
Сложнее по сравнению с вариантом автора? На мой взгляд, нет, это и проще и надёжнее. VPS приходят и уходят, чем меньше на них настроек, тем проще их менять. И это мы ещё не говорим о том, что в домашней локалке часто есть какие-то сервисы, которые нужны и внешним клиентам.
Terimoun
Вся эта битва подходов сводится к одному: у кого какие ресурсы есть под рукой, тот так и строит
E_Eugene
Схема очевидная, но при одном условии - вы живёте в инфраструктуре дата-центра. Как показывает опыт, "отказоустойчивость" квартиры сильно ниже любого дата-центра. Отключили свет, отключили интернет, еще что-то случилось... Да, в любом дата-центре могут тоже случаться форс-мажоры, могут и оборудование вынести. Но в 99% случаев вопросы с восстановлением инфраструктуры дата-центра решаются сильно быстрее вопросов восстановления инфраструктуры какого-нибудь Горсвета или районного провайдера. А для многих наличие стабильного доступа - это не про Ютубчик и рилсики посмотреть, а работа, которая будет простаивать.
А когда это работа, там появляются страховочные пути в виде нескольких протоколов и нескольких fallback-серверов.
Pavel7
С одной стороны, справедливо. С другой стороны, если для вас стабильный доступ критичен, то вы же, наверное, резервируете и линк между вашим рабочим терминалом (тем, где вы физически находитесь) и первым хопом, а в этом вам резервирование дата-центра никак не поможет. Грубо говоря, если вы работаете из дома, вы уже, скорее всего, резервируете и последнюю милю (ИБП на роутер и запасной провайдер). Логично использовать этот резерв и для внешних клиентов.
E_Eugene
А вот здесь есть элементарное решение - раздача мобильного интернета с телефона.
При отключении света, ИБП на роутер и запасной провайдер (если он у вас есть, конечно, у многих провайдер-монополист) вас никак не спасут, т.к. и свитчи провайдера в доме отключаться так же вместе со светом. Ну и всё это "своё родное" в конечном счете финансово будет сильно дороже аренды нескольких VPS.
Pavel7
Это же элементарное решение применимо и для роутера. Только если это для работы - это ни разу не комфортно по сравнению с резервным проводным провайдером, который автоматом поднимется при даунтайме основного.
Не сталкивался с провайдерами, которые не резервируют питание, но допускаю, что такое есть. Оба моих провайдера выдерживают, как минимум, 3 часа после отключения. Не уверен, кстати, что оптоволоконным сплиттерам на уровне подъезда вообще нужно питание, если в квартиру заходит оптика, а не витая пара.
Резервный провайдер - это тысяч 5 в год, ИБП тысяч 20 лет на 5-7. Опять же, если вы уже работаете из дома и канал для вас критичен (как было заявлено) - оно у вас и так будет.
E_Eugene
Вам не кажется, что в поисках "простого" решения вы в итоге максимально его усложняете?! Строить какую-то инфраструктуру уровня дата-центра дома, когда можно за 150 рублей в месяц (а можно и дешевле) арендовать VPS и выстроить независимую систему на готовой инфраструктуре...
К слову о провайдерах, у меня 1 провайдер в доме и он ложится так же вместе с отключением света, при возобновлении - еще несколько минут поднимается. Подключение по витой паре. Делаю вывод, что никакого резервирования питания там нет.
Если вам кажется, что провести еще провайдера плевое дело, то у меня есть свежий кейс: в прошлом году купили квартиру в "сталинке" тёще в центре одного из крупных городов Подмосковья, после покупки только узнали, что в доме нет НИ ОДНОГО ПРОВАЙДЕРА, только ADSL (в 2025 году в 20 км от МКАД, Карл!) от Ростелекома, при том что во всех домах вокруг интернет есть и часто не от одного провайдера. Порядка полугода потребовалось, чтобы уговорить хоть одного провайдера подключить дом. Очень повеселил "Акадо", у которого дом числился подключенным, но при попытке оставить заявку на подключение было сказано "Оборудование есть, но к нему никто не подключен, надо мастера направить его проверить", после визита мастера оказалось "Ой, это не наше оборудование у вас". Чье оборудование установлено так и не получилось узнать.
Pavel7
Не кажется, решение с единой точкой маршрутизации гораздо проще. Но, в целом, готов согласиться, что всё зависит от сценариев. Если рассматривать сценарий "при пропадании электричества/интернета я бегу искать место, где электричество и интернет доступны", то вариант с ДЦ приемлем. Если рассматривать сценарий "мне критично наличие электричества и проводного интернета с VPN вот в этой физической точке", то в этой же точке и должна происходить маршрутизация трафика для всех.
E_Eugene
Вы рассматриваете ситуацию с позиции неизменности недвижимости. Я же за последние 5 лет сменил город проживания, сменил порядка 5 квартир и в течение года регулярно перемещаюсь, оставаясь в рабочем режиме. Тут можно было бы сказать, что это единичный случай, но, во-первых, перемещаюсь я с женой, которая так же пользуется для работы инфраструктурой (и кошкой, но она не работает и ей интернет не нужен), во-вторых, все мои коллеги живут в таком же формате примерно с пандемии и локдаунов. Т.е. в целом даже на небольшой выборке можно сказать, что кейс не уникальный. При этом инфраструктура живет своей жизнью и никак не зависит от моих перемещений, провайдеров и прочего. Да, один VPS пришлось в экстренном режиме переносить из Голландии, но вот это уже единичный случай.
Pavel7
Нет, даже близко. Я рассматриваю ситуацию с точки зрения оптимизации телодвижений, когда домашний роутер уже маршрутизирует трафик для внутренних клиентов и выглядит логичным, чтобы он делал то же самое, по тем же правилам для внешних клиентов.
Моя точка за несколько лет сменила 3 физические локации с единственным даунтаймом на физический перевоз. Естественно, для меня критично, чтобы в конкретной локации был нормальный проводной провайдер с резервом и не потому, что там будет стоять сервер, а потому что я там буду физически работать.
Guerrero77
У меня есть и VPS(несколько штук) и "домашнее" - маршрутизация на роутере, сервер на n150 под Home Assistant, там же отдельная виртуалка с мтпрото, все это сидит на ИБП и инет по оптике... так за последние полгода моя система живет явно лучше чем эти VPS. Сбоев меньше. И блокировок меньше, тот же мтпрото без костылей нормально работает. А на некоторых РФ VPS поотваливалось соединение мтпрото.
Hardoman
Самая очевидная причина не делать ничего на домашней сети - домашние isp чаще всего блокируют гораздо больше протоколов, сервисов и портов, чем ТСПУ в дата-центрах. Например, обычный wg до сих пор работает в русских ДЦ, а на домашних провах чаще нет.
Pavel7
Вы, в любом случае, вынуждены обходить блокировки домашнего или мобильного провайдера, вы же физически в дата-центре не сидите, правильно? И если вы можете с домашнего роутера подключиться к VPS в ДЦ, то какая вам разница что там блокирует домашний провайдер? Публикуете порты сервисов домашнего роутера на VPS и спокойно подключаетесь к нему с внешних клиентов.
Hardoman
К ДЦ напрямую я могу подключиться 5-6 разными способами, а к дому 1-2, и то не всегда стабильно, без гарантии.
Pavel7
Подключитесь с домашнего роутера любым одним (из 5-6) способов к ДЦ, опубликуйте 5-6 портов доступа домашнего роутера на VPS и, готово, теперь вы можете подключаться к дому 5-6 разными способами.
Hardoman
Из дома я НЕ могу подключиться 5-6 способами к ДЦ, потому что на домашнем канале большинство протоколов заблокировано. А вот напрямую не с домашнего инета, а например, с корпоративного могу напрямую в ДЦ. Или с мобильного могу, а с домашнего не могу. В общем, не надо меня убеждать, что домашний инет - это хорошо. Это дно днишное само по себе, которое отъебнет в любой момент. Даже мобильный инет в этом смысле стабильнее - нашёл другую локацию, где работает он или публичный wifi и вот тебе доступ до ДЦ.
Pavel7
5-6 и не надо, как я писал, достаточно одного.
В целом, утверждать, что мобильный интернет (с эпизодическими белыми списками) или корпоративный интернет (где резали порты и протоколы задолго до того, как это стало мейнстримом) менее подвержен блокировкам, чем домашний интернет - это довольно оригинально.
Hardoman
Не достаточно одного, который в любой момент отвалится. И двух не достаточно.. И как реальный пример socks5 и MTProto из корп сети работают, из домашней нет. Фактура текущего дня.
eskars
Для ТСПУ нет никакой разницы кто там под ним - физики или сервера. Я за последние месяцы проверил десятки хостеров и на некоторых ТСПУ в разы сильнее душит, чем на моем домашнем интернете.
Hardoman
Я здесь не буду спорить, у меня нет фактуры, но то, что я вижу, что если брать в определённых ДЦ, то ТСПУ работает совершенно иначе. Из чего можно сделать вывод, но на определённых крупных площадках, правила отличаются. В частности, на cloud.ru моем работает практически все, кроме mtproxy
eskars
Я про это же. На cloud.ru - средний ТСПУ, на селектеле - ниже среднего, таймвеб - можно сказать что его нет вовсе, на ihc.ru - самый жесткий, из которых я видел. Все это хостеры в рамках одной локации (МСК). Некоторые еще и в одних и тех же дц живут.
eskars
Все это реализуется и без платного белого IP. Причем как на vless через reverse, так и на (a)wg через keepalive и корректные настройки маршрутизации.
Hardoman
У большинства l2tp блокируется, как и openvpn и тп