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

[English version](WARP-RU.en.md) · [Документация](README.md) · [Сайт проекта](https://bivlked.github.io/amneziawg-installer/ru/)

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

> Схему предложил [@alexfiu4-cyber](https://github.com/alexfiu4-cyber) в [issue #103](https://github.com/bivlked/amneziawg-installer/issues/103). Я её проверил на стенде, поправил пару мест и оформил в инструкцию. Спасибо за разбор.

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

<a id="toc"></a>
## Содержание

- [Что это даёт и когда нужно](#what)
- [Как это работает](#how)
- [Что понадобится](#prereq)
- [Шаг 1. Профиль WARP через wgcf](#step1)
- [Шаг 2. Интерфейс warp и правило маршрутизации](#step2)
- [Шаг 3. Подписка на BGP-фид](#step3)
- [Шаг 4. Установка и настройка BIRD](#step4)
- [Проверка](#verify)
- [Что происходит при сбоях](#failopen)
- [Диагностика](#trouble)
- [Безопасность](#security)
- [Ограничения и нюансы](#limits)
- [Как убрать](#uninstall)

<a id="what"></a>
## Что это даёт и когда нужно

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

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

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

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

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

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

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

<a id="how"></a>
## Как это работает

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

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 не содержит маршрута по умолчанию. Поэтому всё, что в ней не нашлось, автоматически уходит прежним путём. Разбор этого поведения - в разделе [Что происходит при сбоях](#failopen).

<a id="prereq"></a>
## Что понадобится

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

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

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

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

Если на сервере уже работает BIRD под другую задачу, **не заменяйте его конфиг целиком** - в шаге 4 добавьте нужные блоки к существующему и сделайте резервную копию. Раздел [Как убрать](#uninstall) в этом случае тоже не подходит: он удаляет 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 с утилитами третьей линии рецепт пока не перепроверялся.

<a id="step1"></a>
## Шаг 1. Профиль WARP через wgcf

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

```bash
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`), она уже стоит в шаблоне ниже.

<a id="step2"></a>
## Шаг 2. Интерфейс warp и правило маршрутизации

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

```ini
[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`.

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

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

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

```bash
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`, и правило поймает не тот трафик.

<a id="step3"></a>
## Шаг 3. Подписка на BGP-фид

Список российских сетей отдаёт сервис [antifilter.network](https://antifilter.network/bgp). Чтобы он начал анонсировать маршруты вашему серверу, его нужно зарегистрировать на странице `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`, второго достаточно, чтобы отобрать нужные маршруты.

<a id="step4"></a>
## Шаг 4. Установка и настройка BIRD

```bash
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;
}
```

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

```bash
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`.

<a id="verify"></a>
## Проверка

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

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

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

```bash
ip route get 5.255.255.242 from 10.9.9.2 iif awg0
```

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

```bash
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`, то есть срабатывает только на транзитном трафике, пришедшем от клиентов. Запросы, которые сервер делает от себя, под него не подпадают никогда и уходят прямым путём. Единственная честная проверка - с клиента за туннелем.

<a id="failopen"></a>
## Что происходит при сбоях

Здесь важно не обольщаться словом «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` с проверкой, что ответ вообще пришёл.

<a id="trouble"></a>
## Диагностика

- **`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](ADVANCED.md#split-detect-adv); мерилось там против снимка сетей, которым пользуется каскад, а у фида список свой.
- **Работает, а после перезагрузки нет.** Проверьте автозапуск всех трёх юнитов: `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.

<a id="security"></a>
## Безопасность

- Правила `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` и два отбрасывающих правила в фильтре стоят как раз на этот случай.

<a id="limits"></a>
## Ограничения и нюансы

- Схема не входит в установщик и им не управляется. Обновление скриптов её не тронет, но и не восстановит, если вы её сломаете.
- Работает по 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](ADVANCED.md#split-detect-adv).
- Деление по адресу назначения видно снаружи: сайт может сравнить адрес соединения с тем, что сообщит скрипт на его странице. Это свойство любой схемы с делением - см. [Диагностику](#trouble).
- Российские сайты увидят адрес Cloudflare, а не российский адрес. Для сервисов, которые требуют именно российский IP, этого может не хватить - там нужен каскад с сервером в России, см. [CASCADE.md](CASCADE.md).
- Адреса WARP общие. Часть российских сервисов относится к ним настороженно, и на отдельных сайтах вы можете увидеть капчу.
- Двойная инкапсуляция добавляет к российскому трафику несколько миллисекунд и немного нагружает процессор. На зарубежном трафике не сказывается вовсе - он идёт прежним путём.
- Список сетей ведёт сторонний сервис. Он может ошибаться в обе стороны: не знать какую-то российскую сеть или, наоборот, отдать лишнюю.

<a id="uninstall"></a>
## Как убрать

```bash
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`. Проверить, что ничего не осталось:

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

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

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

---

Схему предложил [@alexfiu4-cyber](https://github.com/alexfiu4-cyber) в [#103](https://github.com/bivlked/amneziawg-installer/issues/103). Вопросы и улучшения - туда же или в [Issues](https://github.com/bivlked/amneziawg-installer/issues).