BGP на Keenetic: как поднять динамическую маршрутизацию через Entware и FRR

Магистральный протокол динамической маршрутизации BGP (Border Gateway Protocol) традиционно ассоциируется с enterprise-оборудованием или полноценными Linux-серверами. Однако в современных реалиях задача построения отказоустойчивых VPN-сетей (Mesh, Site-to-Site) или автоматического распределения трафика часто заставляет инженеров искать способы запуска BGP на клиентских SOHO-роутерах.

Мало кто знает, но начиная с версий KeeneticOS 3.x в прошивке присутствует официальный встроенный компонент BGP (под капотом работает легковесный демон BIRD, интегрированный с подсистемой NDM). У него полностью отсутствует веб-интерфейс, а вся конфигурация осуществляется исключительно через CLI Keenetic (router bgp ...). При этом возможности кастомизации фильтров, route-maps и community в штатном решении сильно ограничены.

Для сетевых инженеров, которым требуется полный контроль над протоколом, привычный Cisco-like синтаксис (vtysh) и максимальная гибкость фильтрации, существует альтернативный «хардкорный» путь — использование OPKG/Entware для запуска полноценного современного стека FRRouting (FRR).

Сам по себе протокол BGP работает поверх TCP/179. Перед началом интеграции важно помнить: открытие этого порта во внешний мир без строгой фильтрации делает роутер уязвимым для атак на control-plane. Официальная поддержка Keenetic допускает установку сторонних пакетов Entware, но не консультирует по их настройке, поэтому вся конфигурация FRR выполняется пользователем самостоятельно.

2. Подробное решение

Архитектура схемы

Практическая схема взаимодействия выглядит следующим образом:

             ┌──────────────────────┐
             │  Upstream / VPS / DC │
             │  AS 65001            │
             │  10.255.0.1          │
             └──────────┬───────────┘
                        │
                  WireGuard / GRE / IPIP / Ethernet
                        │
             ┌──────────▼───────────┐
             │      Keenetic         │
             │  KeeneticOS + Entware │
             │  FRR bgpd (vtysh)     │
             │  AS 65010             │
             │  10.255.0.2           │
             └──────────┬───────────┘
                        │
                 LAN / VLAN / VPN clients

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

• Прием маршрута по умолчанию (default route) или ограниченного набора префиксов от VPS / центрального узла.
• Анонсирование локальных подсетей.
• Динамическое переключение маршрутов между резервными VPN-туннелями.

Для получения Full-View (полной таблицы интернет-маршрутов, составляющей более 1 млн префиксов) Keenetic категорически не подходит. Это embedded-устройство с ограниченными ресурсами CPU и RAM.

Когда BGP на Keenetic имеет смысл

Оправданные сценарии:

1. Site-to-site VPN с динамикой: Несколько офисов или домашних локаций соединены через WireGuard/GRE. BGP автоматически сообщает соседям о появлении или изменении внутренних подсетей.
2. Failover между туннелями: Наличие основного и резервного провайдеров/VPN-каналов. Протокол реагирует на падение линка быстрее и чище, чем кастомные скрипты переключения статики.
3. Лабораторные стенды: Изучение принципов работы BGP в связке с VyOS, Cisco или другими вендорами на недорогом «железе».
4. Анонс частных префиксов: Передача маршрутов вида 10.10.10.0/24 или 192.168.30.0/24 в сторону центрального ядра сети.

Плохие сценарии:

• Попытка принять Full-View от ISP.
• Построение ядра сети крупного провайдера (Production ISP Edge).
• Публикация BGP наружу без ACL.
• Использование в качестве Route Reflector для большого числа клиентов.

Варианты реализации

Вариант A. Вынос BGP на соседний Linux-узел (Рекомендуемый для Production)

Самый стабильный и безопасный вариант, не нагружающий роутер:

Keenetic ── LAN ── Linux/VyOS/FRR (в LXC/ВМ/Mini-PC) ── VPN/BGP ── Upstream

Роутер занимается только коммутацией и NAT, а вся логика BGP инкапсулирована на сервере. На Keenetic прописывается лишь статическая трасса до локального Linux-маршрутизатора.

Вариант B. Запуск BGP прямо на Keenetic через Entware

Основной вариант данной статьи. Требует наличия модели роутера с USB-портом (файловая система накопителя должна быть EXT4) либо современной модели с поддержкой установки Entware напрямую во внутреннюю NAND-память (доступно начиная с KeeneticOS 3.7.x). В качестве демона используется современный стек FRR.

Вариант C. Использование устаревшего стека Quagga

Quagga — исторический предшественник FRR. Этот вариант стоит рассматривать исключительно как fallback-сценарий, если для архитектуры процессора вашего роутера в репозитории Entware отсутствует пакет FRR. Стоит учитывать, что проект Quagga официально признан устаревшим (активная разработка прекращена в 2018 году), поэтому все новые инсталляции следует разворачивать на FRR.

Подготовка Keenetic к установке FRR

Шаг 1. Включение поддержки OPKG

В веб-интерфейсе Keenetic перейдите в Управление → Общие настройки → Изменить набор компонентов и активируйте пункт «Поддержка открытых пакетов (OPKG)».

Если используется USB-накопитель, отформатируйте его в EXT4, подключите к устройству и выберите в качестве хранилища для OPKG. Для установки во внутреннюю память (на поддерживаемых моделях) используется CLI-команда:

(config)> opkg disk storage:

После успешной установки окружения Entware автоматически создается скрипт инициализации /opt/etc/init.d/rc.unslung, через который будут запускаться наши службы.

Шаг 2. Вход в окружение Entware и обновление

Подключитесь к Keenetic по SSH и перейдите в shell Entware:

(config)> exec sh

Обновите дерево пакетов и задайте пароль для суперпользователя:

opkg update
opkg upgrade
passwd root

Шаг 3. Установка пакетов маршрутизации

Выполните поиск доступных пакетов:

opkg list | grep -E '^(frr|quagga)'

При наличии стабильной сборки FRR, установите основной демон, надстройку для BGP, интерфейс взаимодействия ядра и утилиту управления:

opkg install frr frr-bgpd frr-zebra frr-vtysh

Если FRR недоступен для вашей архитектуры, установите legacy-пакеты Quagga:

opkg install quagga quagga-bgpd quagga-zebra

Примечание: Имена пакетов в различных репозиториях (MIPS/ARM/AArch64) могут незначительно отличаться.

Настройка BGP через FRRouting (FRR)

Рассмотрим минимальную рабочую конфигурацию для следующих вводных данных:

• Автономная система Keenetic: 65010
• Автономная система VPS: 65001
• IP-адрес туннеля Keenetic: 10.255.0.2
• IP-адрес туннеля VPS: 10.255.0.1
• Локальная сеть за Keenetic: 192.168.10.0/24

Шаг 1. Создание структуры директорий

mkdir -p /opt/etc/frr
mkdir -p /opt/var/log/frr
mkdir -p /opt/var/run/frr

Шаг 2. Создание файла конфигурации frr.conf

Откройте редактор: vi /opt/etc/frr/frr.conf и внесите следующие настройки:

frr version 8
frr defaults traditional
hostname keenetic-bgp
log file /opt/var/log/frr/frr.log informational
service integrated-vtysh-config
!
! Фильтр для исходящих анонсов (разрешаем только локальную LAN)
ip prefix-list PL-LAN seq 10 permit 192.168.10.0/24
ip prefix-list PL-LAN seq 999 deny 0.0.0.0/0 le 32
!
! Фильтр для входящих анонсов (блокируем full-view, разрешаем дефолт и серые сети)
ip prefix-list PL-IN seq 10 permit 0.0.0.0/0
ip prefix-list PL-IN seq 20 permit 10.0.0.0/8 le 24
ip prefix-list PL-IN seq 30 permit 172.16.0.0/12 le 24
ip prefix-list PL-IN seq 40 permit 192.168.0.0/16 le 24
ip prefix-list PL-IN seq 999 deny 0.0.0.0/0 le 32
!
router bgp 65010
 bgp router-id 10.255.0.2
 no bgp ebgp-requires-policy
 neighbor 10.255.0.1 remote-as 65001
 neighbor 10.255.0.1 description upstream-vps
 neighbor 10.255.0.1 timers 10 30
 !
 address-family ipv4 unicast
  network 192.168.10.0/24
  neighbor 10.255.0.1 activate
  neighbor 10.255.0.1 prefix-list PL-IN in
  neighbor 10.255.0.1 prefix-list PL-LAN out
 exit-address-family
!
line vty

Важно: Явное указание bgp router-id необходимо, так как в изолированном окружении Entware демон zebra не всегда может корректно считать адреса физических интерфейсов роутера.

Шаг 3. Проверка локальной таблицы маршрутизации

BGP-демон анонсирует сеть, указанную в директиве network, только если этот префикс физически присутствует в таблице маршрутизации ядра. Убедитесь в этом командой:

ip route show 192.168.10.0/24

Шаг 4. Запуск служб

Если пакет FRR из репозитория автоматически создал скрипты автоматизации, выполните:

/opt/etc/init.d/S*frr start

В противном случае демоны запускаются вручную в фоновом режиме:

zebra -d -f /opt/etc/frr/frr.conf -z /opt/var/run/frr/zserv.api -i /opt/var/run/frr/zebra.pid
bgpd -d -f /opt/etc/frr/frr.conf -z /opt/var/run/frr/zserv.api -i /opt/var/run/frr/bgpd.pid

Настройка противоположной стороны (Linux / VPS)

Пример ответной конфигурации frr.conf на стороне вашего облачного сервера:

frr version 8
frr defaults traditional
hostname upstream-vps
log syslog informational
service integrated-vtysh-config
!
ip prefix-list FROM-KEENETIC seq 10 permit 192.168.10.0/24
ip prefix-list FROM-KEENETIC seq 999 deny 0.0.0.0/0 le 32
!
ip prefix-list TO-KEENETIC seq 10 permit 0.0.0.0/0
ip prefix-list TO-KEENETIC seq 999 deny 0.0.0.0/0 le 32
!
router bgp 65001
 bgp router-id 10.255.0.1
 neighbor 10.255.0.2 remote-as 65010
 neighbor 10.255.0.2 description keenetic-router
 !
 address-family ipv4 unicast
  neighbor 10.255.0.2 activate
  neighbor 10.255.0.2 prefix-list FROM-KEENETIC in
  neighbor 10.255.0.2 prefix-list TO-KEENETIC out
  network 0.0.0.0/0
 exit-address-family

Не забудьте включить маршрутизацию пакетов на Linux-сервере:

sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.d/99-forwarding.conf

Настройка автозапуска на Keenetic

Для обеспечения отказоустойчивости после перезагрузки создайте init-скрипт /opt/etc/init.d/S80frr:

#!/opt/bin/sh

PATH=/opt/sbin:/opt/bin:/sbin:/bin:/usr/sbin:/usr/bin
CONF="/opt/etc/frr/frr.conf"
RUN_DIR="/opt/var/run/frr"
LOG_DIR="/opt/var/log/frr"
ZEBRA_PID="${RUN_DIR}/zebra.pid"
BGPD_PID="${RUN_DIR}/bgpd.pid"
ZSOCK="${RUN_DIR}/zserv.api"

start() {
  mkdir -p "$RUN_DIR" "$LOG_DIR"
  if [ -f "$ZEBRA_PID" ] && kill -0 "$(cat "$ZEBRA_PID")" 2>/dev/null; then
    echo "Zebra is already running."
  else
    zebra -d -f "$CONF" -z "$ZSOCK" -i "$ZEBRA_PID"
  fi

  if [ -f "$BGPD_PID" ] && kill -0 "$(cat "$BGPD_PID")" 2>/dev/null; then
    echo "Bgpd is already running."
  else
    bgpd -d -f "$CONF" -z "$ZSOCK" -i "$BGPD_PID"
  fi
}

stop() {
  [ -f "$BGPD_PID" ] && kill "$(cat "$BGPD_PID")" 2>/dev/null && rm -f "$BGPD_PID"
  [ -f "$ZEBRA_PID" ] && kill "$(cat "$ZEBRA_PID")" 2>/dev/null && rm -f "$ZEBRA_PID"
}

case "$1" in
  start) start ;;
  stop) stop ;;
  restart) stop; sleep 2; start ;;
  *) echo "Usage: $0 {start|stop|restart}"; exit 1 ;;
esac

Сделайте скрипт исполняемым: chmod +x /opt/etc/init.d/S80frr.

3. Диагностика и отладка

Для входа в интерактивную консоль маршрутизатора введите:

vtysh

Основные команды мониторинга сессии:

• show bgp summary — проверка состояния соседства. Искомый статус: Established.
• show ip bgp — просмотр таблицы префиксов BGP.
• show ip bgp neighbors 10.255.0.1 received-routes — полученные от соседа маршруты (требуется включенное свойство soft-reconfiguration).
• show ip route bgp — маршруты, успешно переданные из BGP в подсистему Zebra.

Выход из консоли осуществляется командой exit. Чтобы убедиться, что маршруты успешно попали непосредственно в ядро Linux самого Keenetic, выполните команду из основного шелла роутера:

ip route show proto bgp

Типовые неисправности

1. Сессия висит в состоянии Active/Connect: Проверьте доступность порта TCP/179 с помощью nc -vz 10.255.0.1 179. Проверьте правила встроенного межсетевого экрана KeeneticOS — они могут блокировать входящий трафик на туннельном интерфейсе.
2. Сессия активна (Established), но префиксов нет: Ошибка в prefix-list. Проверьте, не блокируют ли фильтры анонсы с обеих сторон.
3. После перезагрузки роутера конфигурация пропадает: Особенность Entware. Сервисы инициализируются только после полного монтирования диска с файловой системой EXT4. Убедитесь, что отработал родительский скрипт rc.unslung.

4. Потенциальные недостатки решения

При всей привлекательности схемы, запуск FRR на Keenetic несет в себе архитектурные риски:

• Конфликт логики маршрутизации KeeneticOS (NDM): Собственное ядро операционной системы Keenetic жестко контролирует свои таблицы маршрутизации, логику Multi-WAN (политики маршрутизации), привязки интерфейсов и аппаратный оффлоад (PPE/WhNat). Маршруты, инжектируемые сторонним демоном zebra напрямую в ядро Linux, не видны в веб-интерфейсе Keenetic. Это может приводить к труднодиагностируемым конфликтам (например, трафик уходит не в тот WAN-интерфейс из-за приоритетов таблиц).
• Хрупкость подсистемы хранения: Если USB-флешка выйдет из строя или размонтируется при сбое питания — вся сеть упадет, так как Entware-демоны станут недоступны.
• Потребление ресурсов: Даже небольшая нестабильность линка на стороне соседа (route flapping) вызовет постоянный перерасчет трасс, что способно загрузить слабый процессор SOHO-роутера на 100%, парализовав работу остальных его функций.

Заключение

Использование BGP на Keenetic через Entware и FRR — рабочий, гибкий, но узкоспециализированный инструмент. Он идеально подходит для гиковских инсталляций, домашних лабораторий и связывания удаленных точек в условиях, когда развертывание полноценного выделенного сервера нецелесообразно.

Для стабильного коммерческого использования (Production Enterprise) приоритетным выбором остается вынос BGP на выделенные виртуальные машины или применение специализированных устройств (VyOS, MikroTik, Juniper), изначально спроектированных под задачи динамической маршрутизации.