# Получение BGP маршрутов через туннель в обход провайдера

# Настройка BGP (Antifilter) через Wireguard на Mikrotik (RouterOS 7)

Данное руководство описывает типовые проблемы и чек-лист настройки при маршрутизации заблокированного трафика через списки BGP (Antifilter) с использованием туннеля Wireguard.

*Примечание: Инструкция подразумевает, что удаленный VPS-сервер (Wireguard, NAT) настроен корректно, работает штатно и готов к приему трафика.*

---

## ОСНОВНЫЕ ПРОБЛЕМЫ И ИХ РЕШЕНИЕ (RouterOS 7)

### 1. Защита от петли маршрутизации (Routing Loop)

**Симптом:** При включении BGP туннель Wireguard моментально падает, связь с роутером может обрываться. Маршруты то появляются, то пропадают.

**Причина:** По BGP прилетает маршрут до публичного IP вашего же VPS. Микротик пытается отправить служебный зашифрованный трафик Wireguard внутрь самого туннеля Wireguard (так как туда теперь направлен маршрут), из-за чего туннель схлопывается.

**Что делать:** Жестко привязать публичный IP VPS-сервера к физическому интерфейсу провайдера (WAN). Это исключит его попадание в туннель.

```
/ip route add dst-address=[ПУБЛИЧНЫЙ_IP_VPS]/32 gateway=ether1-WAN comment="Anti-Loop for WG"
```

*(Замените `ether1-WAN` на имя вашего интерфейса с интернетом, например `pppoe-out1`).*

### 2. Правильные фильтры BGP (Избавляемся от динамических ID)

**Симптом:** Трафик не идет в туннель вообще, либо уходит в интернет напрямую. В настройках фильтров стоит шлюз вида `*0xa`.

**Причина:** В RouterOS 7 фильтры часто создаются через консоль или Winbox с указанием внутреннего шестнадцатеричного ID интерфейса (например, `*0xa`). При минорном обновлении прошивки, добавлении интерфейсов или перезагрузке этот внутренний ID меняется, и правило начинает указывать "в никуда".

**Что делать:** В фильтрах (Routing -> Filters) **всегда** прописывать текстовое имя интерфейса.

- ❌ Неправильно: `set gw *0xa; accept;`
- ✅ Правильно: `set gw WG0; accept;`

```
/routing/filter/rule/set [find chain=BGP_IN] rule="set gw WG0; accept;"
```

### 3. Обход блокировки BGP-сессии провайдером (BGP over VPN)

**Симптом:** BGP-сессия не поднимается (висит в статусе Connect/Active), маршруты не прилетают. Пинг до серверов Antifilter не проходит.

**Причина:** Провайдер (или ТСПУ) блокирует BGP-трафик (порт TCP 179) к известным серверам Antifilter.

**Что делать:** Спрятать саму BGP-сессию внутрь зашифрованного Wireguard-туннеля.

1. Направляем трафик до BGP-пира внутрь туннеля WG (чтобы запросы шли через VPN): ```
    /ip route add dst-address=[IP_СЕРВЕРА_BGP]/32 gateway=WG0 comment="BGP over WG"
    ```
2. В настройках BGP Connection (Routing -> BGP) меняем `local.address` с внешнего IP роутера на **внутренний IP Микротика в сети Wireguard** (например, 10.199.126.5). Иначе Mikrotik будет стучаться внешним адресом изнутри VPN: ```
    /routing/bgp/connection/set [find name="antifilter"] local.address=10.199.126.5
    ```

### 4. Проверка NAT (Маскарадинг) на Mikrotik

**Симптом:** BGP поднят, маршруты в таблице есть. Трассировка показывает, что пакеты уходят в туннель, но сайты не открываются (ответы не возвращаются).

**Причина:** Пакеты из домашней локальной сети уходят на VPS с серыми IP-адресами (например, 192.168.88.x). Удаленный сервер не может их замаскировать, так как его NAT обычно настроен только на подсеть самого Wireguard (10.x.x.x).

**Что делать:** Убедиться, что на Микротике есть правило NAT, маскирующее локальный трафик при выходе в интерфейс Wireguard.

```
/ip firewall nat add chain=srcnat action=masquerade out-interface=WG0 comment="NAT for WG"
```

---

## ✅ ЧЕК-ЛИСТ ДЛЯ ДИАГНОСТИКИ

- \[ \] **Связь с VPS:** Wireguard-туннель поднят? Пингуется ли внутренний IP VPS (например, 10.199.126.1) с Микротика?
- \[ \] **Защита от петель (Routing Loop):** Прописан ли статический маршрут `/32` до публичного IP VPS-сервера через физический интерфейс провайдера (WAN)?
- \[ \] **Имена интерфейсов в фильтрах:** В меню `Routing -> Filters` указано явное имя `WG0` вместо системных ID (`*0x...`)?
- \[ \] **Защита BGP от блокировки:** Маршрутизируется ли IP-адрес BGP-сервера (например, 165.22.x.x) через интерфейс `WG0`?
- \[ \] **Локальный IP для BGP:** В настройках сессии `Routing -> BGP` в поле `local.address` указан внутренний IP-адрес интерфейса `WG0` (а не внешний IP провайдера)?
- \[ \] **Локальный NAT:** Включен ли `masquerade` (srcnat) для трафика, покидающего интерфейс `WG0`?

---

## 🛠 КОМАНДЫ ДЛЯ ДИАГНОСТИКИ (ПРОВЕРКА НА MIKROTIK)

Чтобы убедиться, что все настроено правильно, выполните следующие проверки через терминал (New Terminal) в Winbox.

### 1. Проверка работы самого туннеля Wireguard

Для начала нужно убедиться, что туннель поднят и данные бегают. Пингуем внутренний IP-адрес вашего VPS-сервера (в примере — `10.199.126.1`):

```
/ping 10.199.126.1 count=4
```

**Ожидаемый результат:** Пинги возвращаются (packet-loss=0%). Если таймаут — проблема в ключах, портах или Endpoint-адресе WG.

### 2. Проверка связи с BGP-сервером через туннель

Пингуем IP-адрес BGP-сервера Antifilter (в примере — резервный сервер `165.22.127.207`). Этот запрос должен идти строго внутри Wireguard.

```
/ping 165.22.127.207 count=4
```

**Ожидаемый результат:** Пинги идут. Если 100% потерь — вы забыли прописать статический маршрут до BGP-сервера через `WG0`, и трафик блокируется провайдером.

### 3. Проверка статуса BGP-сессии и маршрутов

Проверяем, поднялась ли сессия и сколько маршрутов прилетело:

```
/routing/bgp/connection/print
/ip/route/print count-only where bgp
```

**Ожидаемый результат:** Сессия должна быть в статусе `established` (буква E), а вторая команда должна вывести количество полученных маршрутов (обычно около 30 000 — 45 000).

### 4. Трассировка маршрута (Traceroute) до заблокированного сайта

Проверяем, каким путем роутер отправляет трафик к заблокированным ресурсам (для примера берем IP-адрес Cloudflare, за которым скрывается Rutracker — `104.21.32.39`):

```
/tool traceroute 104.21.32.39
```

**Ожидаемый результат:**   
1-й хоп (прыжок) должен быть внутренним IP-адресом вашего VPS в сети Wireguard (например, `10.199.126.1`).   
2-й хоп должен быть шлюзом провайдера вашего VPS-сервера.   
Если первым хопом выступает IP-адрес вашего домашнего провайдера — маршруты BGP не применились.

### 5. Симуляция запроса из локальной сети (Проверка NAT)

Если с самого Микротика пинг до заблокированного ресурса идет, а с телефонов/ноутбуков — нет, скорее всего, проблема в NAT. Имитируем запрос от имени домашнего устройства (замените `192.168.88.1` на IP-адрес вашего роутера в локальной сети):

```
/ping 104.21.32.39 src-address=192.168.88.1 count=4
```

**Ожидаемый результат:** Пинг должен пройти успешно. Если таймаут — на Микротике отсутствует или не работает правило `src-nat (masquerade)` для интерфейса `WG0`.