amneziawg-installer/WARP-RU.md

Российский сегмент через Cloudflare WARP: выборочная маршрутизация по BGP-фиду

English version · Документация · Сайт проекта

Эта инструкция добавляет к обычной установке amneziawg-installer второй выход в интернет. Трафик клиентов к российским сетям уходит через Cloudflare WARP, весь остальной - напрямую с вашего сервера, как и раньше. Список российских сетей сервер получает автоматически по BGP от сервиса antifilter.network, поэтому руками его вести не нужно.

Схему предложил @alexfiu4-cyber в issue #103. Я её проверил на стенде, поправил пару мест и оформил в инструкцию. Спасибо за разбор.

Это надстройка поверх обычной установки. В сам установщик она не входит: второй выход и BGP-демон - другой класс задач, держать их в одном скрипте неправильно. Поэтому здесь отдельная пошаговая инструкция.

Содержание

• Что это даёт и когда нужно
• Как это работает
• Что понадобится
• Шаг 1. Профиль WARP через wgcf
• Шаг 2. Интерфейс warp и правило маршрутизации
• Шаг 3. Подписка на BGP-фид
• Шаг 4. Установка и настройка BIRD
• Проверка
• Что происходит при сбоях
• Диагностика
• Безопасность
• Ограничения и нюансы
• Как убрать

Что это даёт и когда нужно

Обычная установка отправляет в туннель весь трафик клиента, и наружу он выходит с IP вашего сервера. Для зарубежных сайтов это хорошо. С российскими сложнее: многие из них закрывают доступ адресам зарубежных дата-центров целыми диапазонами, поэтому банк, госуслуги или маркетплейс могут не открыться, показать капчу или отказать в операции.

Смежная, но другая проблема - когда по автономной системе хостера рубят сам туннель на подходе к серверу; она разобрана отдельно в ADVANCED.md и этой схемой не лечится.

Схема делит трафик по адресу назначения:

• трафик к российским сетям уходит через Cloudflare WARP, и российские сайты видят адрес Cloudflare вместо адреса дата-центра;
• весь остальной трафик идёт напрямую с вашего сервера, как и до этого.

Почему не завернуть в WARP вообще всё: адреса WARP общие на множество пользователей, и часть зарубежных сервисов встречает их капчами и гео-ограничениями. Выборочная схема оставляет зарубежному трафику ваш собственный чистый выход.

Когда это НЕ нужно:

• если российские сайты и так открываются, ничего чинить не надо;
• если у вас есть второй сервер в России, каскад даст российским сайтам настоящий российский IP, а не адрес Cloudflare - см. CASCADE.md;
• если достаточно исключить российские адреса из туннеля на самом клиенте, проще задать это списком AllowedIPs (split-tunnel в ADVANCED.md). Тогда российский трафик пойдёт мимо VPN с домашнего адреса.

Как это работает

Четыре независимые части:

1. Второй интерфейс warp. Cloudflare WARP - это обычный WireGuard. Конфиг для него выпускает утилита wgcf. Отдельный пакет wireguard-tools ставить не нужно: amneziawg-tools, который уже стоит на сервере, понимает и голый WireGuard, поэтому интерфейс поднимается тем же awg-quick.
2. Отдельная таблица маршрутизации 200. В неё складываются маршруты к российским сетям, и все они ведут в интерфейс warp.
3. Правило policy-routing. ip rule заставляет трафик, пришедший в интерфейс awg0 (то есть трафик ваших клиентов), сначала смотреть в таблицу 200. Если адрес назначения там нашёлся - пакет уходит в WARP. Если нет - правило не сработало, и пакет идёт обычным путём в таблицу main, то есть прямо в интернет.
4. BIRD. BGP-демон подписывается на фид antifilter.network и наполняет таблицу 200 списком российских сетей. На момент проверки это примерно 11800 префиксов, и они обновляются сами.

Ключевое следствие устройства: таблица 200 не содержит маршрута по умолчанию. Поэтому всё, что в ней не нашлось, автоматически уходит прежним путём. Разбор этого поведения - в разделе Что происходит при сбоях.

Что понадобится

• Работающая установка amneziawg-installer с поднятым awg0 и подключающимися клиентами. Интерфейс warp - обычный WireGuard и с параметрами awg0 не связан, поэтому схема рассчитана на сервер любого поколения, 3.1 или 2.0 (проверялась на 2.0, см. ниже).
• Root-доступ по SSH.
• Свободные примерно 100 МБ на диске и немного памяти под BIRD, порядка 11800 маршрутов помещаются без затруднений.
• Готовность зарегистрировать внешний IP сервера в сервисе antifilter.network - без этого BGP-сессия не поднимется.
• Свободная таблица маршрутизации 200 и не занятый другими задачами BIRD. Инструкция исходит из того, что и то, и другое на сервере не используется.

Проверьте это до начала, обе команды должны ответить пусто:

ip rule show | grep 200          # правил на таблицу 200 быть не должно
ip route show table 200          # таблица должна быть пуста

Если таблица 200 у вас занята, возьмите другой свободный номер и подставляйте его везде вместо 200. Это важнее, чем кажется: если в таблице уже лежит чужой маршрут по умолчанию, правило из шага 2 немедленно уведёт туда весь трафик клиентов.

Если на сервере уже работает BIRD под другую задачу, не заменяйте его конфиг целиком - в шаге 4 добавьте нужные блоки к существующему и сделайте резервную копию. Раздел Как убрать в этом случае тоже не подходит: он удаляет BIRD вместе с пакетом.

Проверено на Ubuntu 24.04 LTS (ядро 6.8), сервер AmneziaWG 2.0 (до v6.0.0), с amneziawg-tools v1.0.20260618-2, wgcf 2.2.32 и BIRD 2.14. На сервере 3.1 с утилитами третьей линии рецепт пока не перепроверялся.

Шаг 1. Профиль WARP через wgcf

wgcf регистрирует бесплатный аккаунт WARP и выдаёт готовый WireGuard-конфиг. Возьмите бинарь со страницы релизов под свою архитектуру (amd64 или arm64):

mkdir -p /root/warp && cd /root/warp
ARCH=amd64; [ "$(uname -m)" = "aarch64" ] && ARCH=arm64
F="wgcf_2.2.32_linux_${ARCH}"
rm -f wgcf
curl -fsSLO "https://github.com/ViRb3/wgcf/releases/download/v2.2.32/$F" \
  && curl -fsSLO "https://github.com/ViRb3/wgcf/releases/download/v2.2.32/checksums.txt" \
  && grep " $F\$" checksums.txt | sha256sum -c - \
  && mv "$F" wgcf && chmod +x wgcf \
  && ./wgcf register --accept-tos && ./wgcf generate

Получится файл wgcf-profile.conf. Из него понадобятся три значения: PrivateKey, Address и PublicKey. Строку Endpoint подставлять не нужно: у WARP она одна и та же (engage.cloudflareclient.com:2408), она уже стоит в шаблоне ниже.

Шаг 2. Интерфейс warp и правило маршрутизации

Создайте /etc/amnezia/amneziawg/warp.conf. Подставьте значения из wgcf-profile.conf:

[Interface]
PrivateKey = <PrivateKey из wgcf-profile.conf>
Address = <Address из wgcf-profile.conf, только IPv4-адрес>
MTU = 1280
Table = off

PostUp = ip rule add iif awg0 lookup 200
PostUp = iptables -t nat -A POSTROUTING -o %i -j MASQUERADE
PostUp = iptables -I FORWARD -i awg0 -o %i -j ACCEPT
PostUp = iptables -I FORWARD -i %i -o awg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

PostDown = ip rule del iif awg0 lookup 200
PostDown = iptables -t nat -D POSTROUTING -o %i -j MASQUERADE
PostDown = iptables -D FORWARD -i awg0 -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -o awg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

[Peer]
PublicKey = <PublicKey из wgcf-profile.conf>
AllowedIPs = 0.0.0.0/0
Endpoint = engage.cloudflareclient.com:2408

Что здесь важно и почему:

• Table = off обязателен. Без него awg-quick пропишет WARP маршрутом по умолчанию для всего сервера, включая ваш SSH. С ним основная таблица маршрутизации не меняется вовсе.
• Из профиля переносится только IPv4-адрес. Строка Address в wgcf-profile.conf содержит ещё и IPv6; он тут не нужен и только добавит путей утечки.
• Строку DNS из профиля не переносим. Она предназначена клиентскому применению профиля. На сервере awg-quick вызвал бы из-за неё resolvconf и повесил резолвер на интерфейс - лишняя зависимость и лишняя движущаяся часть, менять системный резолвер ради второго выхода незачем.
• Правило iif awg0 не зависит от подсети клиентов. Вариант from 10.9.9.0/24 пришлось бы править при смене подсети, а iif привязан к интерфейсу и переживает такие правки.
• Правила FORWARD вставляются через -I, то есть в начало цепочки. Так они стоят выше цепочек UFW и не зависят от того, что в них появится позже. Политика цепочки на сервере с UFW - запрет, но применяется она уже после всех правил, поэтому дело не в том, что добавленное в конец правило «не сработает», а в том, что его судьба будет зависеть от чужих правил. Установщик по той же причине вставляет своё правило для awg0 тоже через -I.

Поднимите интерфейс и включите автозапуск:

chmod 600 /etc/amnezia/amneziawg/warp.conf
systemctl enable --now awg-quick@warp

Теперь проверьте, что второй выход действительно работает. Просто посмотреть awg show warp недостаточно: WireGuard начинает рукопожатие, только когда есть что отправлять, а отправлять пока нечего - таблица 200 ещё пуста. Поэтому сгенерируйте трафик явно и посмотрите результат:

curl --interface warp https://api.ipify.org; echo
awg show warp

Первая команда должна вернуть адрес Cloudflare, отличный от адреса вашего сервера. После неё в awg show warp появятся latest handshake и ненулевой transfer. Если адрес не вернулся, дальше идти бессмысленно - разбирайтесь с WARP, а не с BGP.

Про MSS. В исходном рецепте была ещё строка с TCPMSS --clamp-mss-to-pmtu для трафика в warp. На установке из этого репозитория она ничего не меняет: установщик с версии 5.17.0 уже режет MSS до 1240 в обе стороны для awg0, а при MTU интерфейса warp 1280 для IPv4 получается ровно столько же. Строка нужна, только если вы понижаете MTU WARP или собираете схему поверх чужой установки без MSS-клампа.

Где держать правило ip rule. Выше оно живёт в warp.conf с явным именем awg0. Можно наоборот, положить в awg0.conf строку PostUp = ip rule add iif %i lookup 200 - там %i раскроется в awg0, и оба конфига станут универсальными. Оба варианта рабочие, проверено, что такая строка в awg0.conf переживает команды add, regen и remove скрипта управления. Переустановку с --force она не переживает: установщик собирает [Interface] заново и переносит только пиры, так что после неё строку придётся вернуть (прежний файл остаётся рядом как awg0.conf.bak-<дата>). Вариант с правилом в warp.conf от этого не зависит. А вот в warp.conf писать iif %i нельзя: там %i раскроется в warp, и правило поймает не тот трафик.

Шаг 3. Подписка на BGP-фид

Список российских сетей отдаёт сервис antifilter.network. Чтобы он начал анонсировать маршруты вашему серверу, его нужно зарегистрировать на странице https://antifilter.network/bgp:

• Ваш IP адрес - внешний адрес вашего сервера;
• Номер автономной системы (ASN) - 64999;
• из списка анонсов отметьте только адреса сетей российского сегмента.

Форма закрыта капчей, поэтому заполнить её можно только вручную в браузере.

⚠️ Поле IP страница подставляет сама, и подставляет она адрес, с которого вы её открыли. Если вы смотрите страницу через свой же VPN, там окажется адрес выходного узла, а не сервера, который вы настраиваете. Впишите нужный адрес руками и перепроверьте перед отправкой.

Параметры подписки после отправки: сосед 45.148.244.55, его AS 65444, ваша AS 64999. Сервис рекомендует hold timer 240 секунд. Российский сегмент помечается BGP-community 65444:900 и 65445:643, второго достаточно, чтобы отобрать нужные маршруты.

Шаг 4. Установка и настройка BIRD

apt update && apt install -y bird2

Пакет bird2 есть и в Ubuntu, и в Debian 12, и в Debian 13. В Debian 13 рядом лежит ещё и bird3, но конфиг ниже написан под синтаксис BIRD 2 - ставьте именно bird2.

Замените /etc/bird/bird.conf целиком. Единственное, что нужно подставить, - внешний IP сервера в строке router id:

log syslog all;
router id 203.0.113.10;              # внешний IP вашего сервера

define COUNTRY_RU = (65445,643);

# Таблица маршрутов, которые уедут в ядро (таблица 200).
ipv4 table warp_table;
# Отдельная таблица для резолвинга адреса соседа: сессия multihop.
ipv4 table igp4;

filter warp_route {
    # Адрес самого сервиса не должен уехать в WARP.
    if 45.148.244.55 ~ net then reject;
    # Маршрут по умолчанию с нужным community увёл бы в WARP весь трафик клиентов.
    if net = 0.0.0.0/0 then reject;
    if (COUNTRY_RU ~ bgp_community) then accept;
    reject;
}

filter warp_kernel {
    ifname = "warp";
    accept;
}

protocol device { scan time 10; }

# Маршруты ядра нужны только для резолвинга адреса соседа.
# В основную таблицу BIRD не пишет ничего: export none.
protocol kernel kernel_main {
    learn;
    ipv4 { table igp4; import all; export none; };
}

protocol pipe main_to_warp {
    table master4;
    peer table warp_table;
    import none;
    export all;
}

protocol kernel kernel_warp {
    ipv4 { table warp_table; import none; export filter warp_kernel; };
    kernel table 200;
}

protocol bgp antifilter {
    ipv4 {
        import filter warp_route;
        export none;
        igp table igp4;
        import limit 50000 action block;
    };
    local as 64999;
    neighbor 45.148.244.55 as 65444;
    multihop;
    hold time 240;
}

Проверьте конфиг и запустите демон:

bird -p -c /etc/bird/bird.conf && echo "конфиг корректен"
systemctl enable bird
systemctl restart bird

Именно restart, а не enable --now: если BIRD на сервере уже был запущен, --now ничего не сделает, демон продолжит работать со старым конфигом, а новый подхватится только при следующей перезагрузке - и вы будете проверять не то, что настроили.

Несколько решений в этом конфиге стоит пояснить, иначе они выглядят произвольными:

• import filter warp_route на самой сессии, а не на pipe. Отбор по community сделан как можно раньше: маршруты чужих групп вообще не попадают в память BIRD. Если вы позже добавите в подписку другие наборы, они не расползутся по таблицам сами собой.
• Две защиты в фильтре. Отброс 0.0.0.0/0 не даёт увести в WARP вообще весь трафик клиентов, если маршрут по умолчанию когда-нибудь придёт с нужным community. Отброс сети с адресом сервиса нужен для другого: сама BGP-сессия в WARP уехать не может (она идёт от сервера, а правило ловит только транзит с awg0), но клиентский трафик к этой сети - вполне, и заворачивать его туда незачем. Сейчас в фиде нет ни того, ни другого - проверено, - но обе строки стоят копейки.
• import limit 50000 action block ограничивает размер аварии, если фид однажды отдаст на порядок больше ожидаемого. Порог взят с запасом примерно вчетверо к нынешним 11800.
• Отдельная таблица igp4 с learn. Сессия с сервисом multihop, и BIRD резолвит адрес соседа рекурсивно. Без маршрутов ядра резолвить не через что, и полученные маршруты помечаются как unreachable. На конечный результат это, как ни странно, не влияет: фильтр warp_kernel всё равно перебивает next-hop на интерфейс warp, и маршруты встают в таблицу 200 корректно. Но диагностировать такую установку неудобно - birdc show route показывает unreachable вместо нормального состояния. С igp4 маршруты имеют тип unicast, и всё видно как есть.
• ifname = "warp" в warp_kernel - это именно присвоение, а не сравнение. Оно заменяет next-hop маршрута на интерфейс и даёт в ядре ровно то же, что ip route add <сеть> dev warp table 200.

Проверка

На сервере. Сессия должна быть Established, а таблица 200 - непустой:

birdc show protocols antifilter          # ожидается Established
ip route show table 200 | wc -l          # ожидается порядка 11800
ip route show table 200 | head -3        # все строки вида "... dev warp"

Как ядро решит вести пакет клиента к российскому адресу, можно спросить напрямую, не гоняя трафик. Подставьте адрес клиента из своей подсети:

ip route get 5.255.255.242 from 10.9.9.2 iif awg0

Ожидаемый ответ содержит dev warp table 200. Для зарубежного адреса та же команда должна показать обычный внешний интерфейс сервера:

ip route get 8.8.8.8 from 10.9.9.2 iif awg0

С клиента. Подключитесь к VPN и сравните, каким вас видят российский и зарубежный сервисы:

• российский, например https://yandex.ru/internet или 2ip.ru, должен показать адрес Cloudflare;
• зарубежный, например ifconfig.me, должен показать адрес вашего сервера.

⚠️ Проверять curl-ом на самом сервере бесполезно, и это не придирка к методике. Правило маршрутизации написано как iif awg0, то есть срабатывает только на транзитном трафике, пришедшем от клиентов. Запросы, которые сервер делает от себя, под него не подпадают никогда и уходят прямым путём. Единственная честная проверка - с клиента за туннелем.

Что происходит при сбоях

Здесь важно не обольщаться словом «fail-open». Отказы делятся на две группы, и ведут они себя по-разному. Всё в таблице проверено на стенде.

Отказы фида - трафик возвращается на прямой выход, связь не теряется:

Событие	Что происходит
BIRD остановлен командой	Маршруты сняты, таблица 200 пуста, российский трафик идёт напрямую с сервера
BGP-сессия отвалилась	То же самое: BIRD снимает маршруты, российские сайты снова видят адрес дата-центра
Перезапущен интерфейс warp	Таблица 200 пустеет сразу - ядро сносит маршруты вместе с исчезнувшим устройством. BIRD возвращает их примерно за 20 секунд при очередном сканировании ядра, вмешательства не требуется
Сервер перезагружен	Оба интерфейса поднимаются сами, правила восстанавливаются из PostUp

Отказы, при которых российский трафик встаёт:

Событие	Что происходит
🔴 Пир WARP перестал отвечать, а интерфейс остался поднят	Маршруты в таблице 200 никуда не делись и продолжают вести в warp, но выхода за ним больше нет. Российские адреса перестают открываться совсем, зарубежные работают как ни в чём не бывало. Автоматического возврата на прямой выход в этом случае НЕТ
⚠️ BIRD убит аварийно (SIGKILL, OOM, паника)	Маршруты остаются в таблице 200: ядро не связывает их с жизнью процесса, а снять их некому. Пока warp жив, российский трафик продолжает идти через него, то есть схема работает, но список сетей застывает и перестаёт обновляться. Systemd поднимает демон заново, и тот пересинхронизирует таблицу

Отсюда практический вывод про мониторинг. Состояния BGP-сессии и числа маршрутов недостаточно: в самом неприятном сценарии сессия жива, маршруты на месте, а российские сайты не открываются, потому что мёртв сам WARP. Если схема для вас не эксперимент, следите ещё и за проходимостью второго выхода - например, периодическим запросом curl --interface warp с проверкой, что ответ вообще пришёл.

Диагностика

• awg show warp без latest handshake. Само по себе это ещё не поломка: простаивающий WireGuard-интерфейс рукопожатие не инициирует. Сначала дайте трафик - curl --interface warp https://api.ipify.org - и посмотрите снова. Вот если после этого адрес не вернулся и рукопожатия по-прежнему нет, WARP действительно не поднялся: проверьте, что исходящий 2408/udp не закрыт, и что в warp.conf подставлены значения именно из wgcf-profile.conf.
• 🔴 Российские сайты перестали открываться совсем, зарубежные работают. Похоже на мёртвый второй выход при живых маршрутах. Проверьте его напрямую: curl --interface warp https://api.ipify.org. Если ответа нет, дело в WARP, а не в фиде, и таблица 200 сейчас уводит российский трафик в никуда. Быстрое лечение - systemctl stop awg-quick@warp: маршруты уйдут вместе с интерфейсом, и российский трафик вернётся на прямой выход, пока вы разбираетесь.
• BGP-сессия в состоянии Active с ошибкой Connection reset by peer. Сервис не знает вашего адреса: либо форма не отправилась, либо в ней указан не тот IP. Именно так выглядит незарегистрированный сервер.
• Сессия Established, но таблица 200 пуста. Смотрите счётчики: birdc show protocols all antifilter. Если imported нулевой, значит маршруты не проходят фильтр - проверьте, что в подписке отмечен российский сегмент. Если imported есть, а в ядре пусто, дело в экспорте: birdc show protocols all kernel_warp.
• Российский сайт всё равно открывается с адреса дата-центра. Скорее всего он размещён не на российском IP: за зарубежным CDN или у зарубежного хостера. Деление идёт по адресу назначения, поэтому такой сайт уходит прямым выходом, и это ожидаемо.
• Российский сайт открывается через WARP, но ведёт себя так, будто видит адрес дата-центра. Возможно, так и есть, только узнал он его не из соединения. На странице может работать скрипт, который спрашивает адрес у стороннего сервиса определения IP, а почти все проверенные мной сервисы такого рода оказались зарубежными - и если конкретного в фиде нет, запрос к нему уйдёт не через warp, а прямым выходом. Тогда скрипт сообщит сайту адрес самого сервера, ровно тот, от которого схема уводила. Есть ли адрес в фиде, видно сразу: ip route show table 200 match 77.88.55.242 - пусто значит мимо WARP. Прописывать такие сервисы в таблицу 200 руками - путь ненадёжный: их адреса зависят от резолвера и меняются сами. Разбор с цифрами - в ADVANCED.md; мерилось там против снимка сетей, которым пользуется каскад, а у фида список свой.
• Работает, а после перезагрузки нет. Проверьте автозапуск всех трёх юнитов: systemctl is-enabled awg-quick@awg0 awg-quick@warp bird.
• Handshake есть, трафик к российским адресам не идёт. Проверьте sysctl net.ipv4.conf.all.rp_filter. При строгом режиме (значение 1) ответы, пришедшие через warp, молча отбрасываются: обратный маршрут к российскому адресу ведёт на основной аплинк, а пакет пришёл с другого интерфейса. Установщик из этого репозитория ставит 2, но на сервере, настроенном не им, это стоит проверить.
• Правили PostUp/PostDown и перезапустили интерфейс - в цепочках висят лишние правила. При перезапуске awg-quick выполняет PostDown уже из НОВОЙ редакции конфига, поэтому правила, добавленные прежней, снять некому. Снимите их разово руками (iptables -D ... с текстом старого правила) или перезагрузите сервер.
• Полезные сырые команды. birdc show route table warp_table count - сколько маршрутов отобрано; birdc show route for <адрес> table master4 all - пришёл ли конкретный адрес и с какими community.

Безопасность

• Правила FORWARD выше сужены до пары awg0 и warp. В исходном рецепте они были шире и принимали в warp трафик с любого интерфейса. На типовой установке разницы не видно, потому что в таблицу 200 попадает только трафик клиентов, но узкое правило точнее описывает намерение.
• Cloudflare видит содержимое ваших соединений ровно в том же объёме, в каком его видел бы любой другой выходной провайдер. Это смена того, кому вы доверяете выход, а не добавление шифрования.
• Аккаунт WARP, который выпускает wgcf, бесплатный и анонимный, но это всё же отдельный аккаунт: файлы wgcf-account.toml и wgcf-profile.conf содержат ключи, держите их с правами 600 и не выкладывайте.
• wgcf - сторонняя программа, и запускаете вы её от root. Команды выше сверяют её с checksums.txt того же релиза и запускают только после успешной сверки. Это ловит битую или оборванную загрузку и не тот файл, но не взлом проекта или его страницы релизов: бинарь и контрольные суммы приходят из одного места. Профиль можно выпустить и на другой машине, а на сервер перенести только wgcf-profile.conf.
• BGP-фид - внешний источник, который влияет на вашу маршрутизацию. Ограничение import limit и два отбрасывающих правила в фильтре стоят как раз на этот случай.

Ограничения и нюансы

• Схема не входит в установщик и им не управляется. Обновление скриптов её не тронет, но и не восстановит, если вы её сломаете.
• Работает по IPv4: и фид, и таблица 200 содержат только IPv4-маршруты. Установщик по умолчанию держит IPv6 выключенным на сервере; если вы его включили, серверный IPv6-трафик пойдёт мимо деления.
• IPv6 на клиентском устройстве - отдельный уровень, и схема его не касается. Эта инструкция ставится поверх готовой установки и режим клиента не меняет. Куда пойдёт IPv6, решает AllowedIPs клиента. Профили полного туннеля (режимы «Весь трафик» и «Amnezia») по умолчанию уводят публичный IPv6 в туннель, где он гаснет; с --allow-ipv6-tunnel IPv6 идёт через туннель в интернет, если у VPS есть свой IPv6 (иначе работает только IPv6 внутри туннеля), а с --client-ipv6-direct режим «Amnezia» намеренно пускает его мимо. Раздельная маршрутизация (--route-custom) IPv6-маршрута не получает, и тогда IPv6 устройства идёт мимо туннеля, а российский сайт увидит настоящий домашний адрес напрямую, без всяких скриптов. Проверка с устройства: curl -6 ifconfig.co - вернулся домашний адрес, значит IPv6 идёт мимо. Профили старых версий и подробности - в ADVANCED.md.
• Деление по адресу назначения видно снаружи: сайт может сравнить адрес соединения с тем, что сообщит скрипт на его странице. Это свойство любой схемы с делением - см. Диагностику.
• Российские сайты увидят адрес Cloudflare, а не российский адрес. Для сервисов, которые требуют именно российский IP, этого может не хватить - там нужен каскад с сервером в России, см. CASCADE.md.
• Адреса WARP общие. Часть российских сервисов относится к ним настороженно, и на отдельных сайтах вы можете увидеть капчу.
• Двойная инкапсуляция добавляет к российскому трафику несколько миллисекунд и немного нагружает процессор. На зарубежном трафике не сказывается вовсе - он идёт прежним путём.
• Список сетей ведёт сторонний сервис. Он может ошибаться в обе стороны: не знать какую-то российскую сеть или, наоборот, отдать лишнюю.

Как убрать

systemctl disable --now bird
systemctl disable --now awg-quick@warp
apt purge -y bird2                      # только если BIRD не нужен под другие задачи
rm -f /etc/amnezia/amneziawg/warp.conf
rm -rf /root/warp

Остановка awg-quick@warp сама снимет правило ip rule и правила iptables - они прописаны в PostDown. Проверить, что ничего не осталось:

ip rule show | grep 200        # пусто
ip route show table 200        # пусто

Установку amneziawg-installer это не затрагивает: клиенты продолжают работать, весь трафик снова идёт прямым выходом.

Если удаляете и сам установщик (--uninstall), сначала выполните шаги выше: установщик останавливает только awg0, а warp.conf лежит в /etc/amnezia, который он удаляет целиком, поэтому awg-quick@warp останется включённым без конфига, а модуль не выгрузится, пока поднят warp.

---

Схему предложил @alexfiu4-cyber в #103. Вопросы и улучшения - туда же или в Issues.