Bring Your Own IP на VPS через BGP: полное руководство

Эта страница — центральный узел полного пути BYOIP. Она связывает каждый шаг от получения ASN до мониторинга BGP-анонсов в продакшене. Каждый раздел ссылается на отдельную статью с конфигурациями, командами и шагами проверки.

Если ты уже знаешь, что такое BGP и BYOIP, переходи сразу к Что нужно перед первой BGP-сессией?.

Что значит принести свой IP на VPS?

Bring Your Own IP (BYOIP) — это анонс IP-адресного пространства, которым ты владеешь или арендуешь у регионального интернет-регистратора (RIR), через сеть хостинг-провайдера с помощью BGP. Вместо IP-адресов провайдера твой VPS оригинирует маршруты для твоих собственных префиксов. Трафик, предназначенный этим IP, достигает сервера через аплинки и точки обмена трафиком провайдера.

Ты сохраняешь контроль над адресами. При смене провайдера IP переезжают с тобой. Никаких изменений DNS, никакого сброса репутации, никакого даунтайма для клиентов за пределами окна конвергенции.

Зачем приносить свои IP?

Непрерывность IP-репутации. Доставляемость почты, DNS-репутация и белые списки файрволов привязаны к адресу, а не к серверу. Смена провайдера с провайдерскими IP означает восстановление репутации с нуля.

Портативность между провайдерами. Твои префиксы не привязаны ни к одному хосту. Можно переключиться на другого провайдера или работать в multi-homing через двух, не меняя адреса, к которым подключаются клиенты.

Multi-homing и резервирование. Анонсируй один и тот же префикс с нескольких площадок. BGP автоматически обеспечивает переключение при сбое. Сервис остаётся доступным, даже если одна площадка падает.

Соответствие требованиям и аудит. Некоторые регулируемые среды требуют документального подтверждения владения IP-адресами. Собственное выделение через RIR обеспечивает этот бумажный след.

Anycast. Анонсируй один и тот же префикс с географически распределённых узлов. Пользователи маршрутизируются к ближайшему. Именно так работают корневые DNS-серверы и CDN-узлы.

Как BGP вписывается в BYOIP?

BGP (Border Gateway Protocol) — протокол, который маршрутизаторы используют для обмена информацией о достижимости между автономными системами в интернете. Когда ты приносишь свой IP на VPS, ты запускаешь BGP-демон на сервере. Этот демон устанавливает сессию с маршрутизатором провайдера и анонсирует твои префиксы. Провайдер распространяет эти анонсы своим аплинкам и пирам. За несколько минут маршрутизаторы по всему интернету узнают, что твоё IP-пространство доступно через сеть провайдера.

Это тот же протокол, который использует каждый ISP, облачный провайдер и контентная сеть. Разница в масштабе: ты анонсируешь один-два префикса вместо тысяч.

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

Что нужно перед первой BGP-сессией?

Шесть базовых блоков в порядке зависимости:

Номер автономной системы (ASN). Твоя идентичность в BGP-интернете. Получаешь от RIR (RIPE NCC в Европе, ARIN в Северной Америке, APNIC в Азиатско-Тихоокеанском регионе) через спонсирующего LIR. Обработка занимает 2-5 рабочих дней в RIPE NCC.
Выделение IP. Минимум /24 для IPv4 или /48 для IPv6. Более мелкие префиксы фильтруются большинством сетей и не будут распространяться. IPv4-пространство можно получить от RIR (всё более дефицитно и дорого) или арендовать у брокера. Выделения IPv6 легко доступны у всех RIR.
IRR route-объекты. Записи в Internet Routing Registry, документирующие, какой ASN авторизован оригинировать твой префикс. Многие транзитные провайдеры строят BGP-фильтры по данным IRR. Без соответствующего route-объекта анонс может быть молча отброшен. Создай их в базе RIPE (или эквиваленте твоего RIR) до первой сессии.
RPKI ROA (Route Origin Authorizations). Криптографические объекты, связывающие префикс с ASN. Более 51% IPv4-маршрутов и 57% IPv6-маршрутов сейчас имеют валидные ROA. Сети, выполняющие Route Origin Validation (ROV), будут отклонять анонсы, не прошедшие RPKI-проверку. Создай ROA в портале своего RIR.
Демон маршрутизации. Софт на VPS, который говорит по BGP. Три основных варианта — BIRD2, FRRouting (FRR) и VyOS. Смотри сравнение ниже.
Провайдер с поддержкой BGP-сессий. Не каждый VPS-провайдер это предлагает. Нужен провайдер, который настроит BGP-сессию между своим маршрутизатором и твоим VPS, примет анонсы префиксов и распространит их в аплинк.

Чеклист перед стартом

Перед запросом BGP-сессии у провайдера убедись, что есть:

Пункт	Где получить	Ориентировочное время
ASN	RIR через спонсирующего LIR	2-5 рабочих дней
IPv4 /24 или больше	Выделение RIR или аренда	От дней до недель
IPv6 /48 или больше	Выделение RIR	1-2 рабочих дня
IRR route/route6-объекты	База данных RIPE или эквивалент	Минуты (после получения ASN)
RPKI ROA для каждого префикса	Членский портал RIR	Минуты
LOA (Letter of Authorization)	Подписываешь ты, провайдер может запросить	Минуты
Провайдер с поддержкой BGP	или аналог	Различается

Провайдеру обычно нужны твой ASN, префиксы, которые планируешь анонсировать, и, возможно, LOA, подтверждающее твою авторизацию на анонс.

Как связаны ASN, выделение IP и RPKI?

Эти три элемента образуют цепочку доверия, позволяющую интернету проверить легитимность твоих анонсов.

Твой ASN идентифицирует сеть. Каждый BGP-анонс несёт оригинирующий ASN в своём AS-path. Вышестоящие сети используют это для построения политики маршрутизации.

Твоё выделение IP — адресное пространство, которое ты авторизован использовать. База данных RIR регистрирует тебя (или спонсирующего LIR) как держателя.

IRR-объекты — это уровень политики маршрутизации. Объект route в базе RIPE говорит: «AS64500 авторизован оригинировать 192.0.2.0/24». Транзитные провайдеры запрашивают данные IRR для построения префиксных фильтров. Если route-объект отсутствует или некорректен, автоматические фильтры транзитного провайдера могут отклонить анонс.

RPKI ROA — криптографический уровень. ROA — подписанный объект в RPKI-репозитории RIR. Он говорит то же, что и IRR route-объект, но криптографически верифицируем. Сети, запускающие ROV-валидаторы (Routinator, rpki-client, Fort, RIPE NCC RPKI Validator), получают ROA и передают результаты валидации маршрутизаторам. Анонс без валидного ROA всё чаще отбрасывается.

Цепочка зависимостей выглядит так:

ASN (from RIR)
  └── IP allocation (from RIR)
        ├── IRR route objects (RIPE Database)
        ├── RPKI ROAs (RIR portal)
        └── BGP session (provider router <-> your daemon)
              └── Prefix announcement (your daemon originates routes)

Приведи в порядок верхние уровни, прежде чем трогать конфигурацию BGP. Анонс без соответствующих IRR и RPKI-записей будет либо отфильтрован, либо помечен как потенциальный хайджек.

Какой демон маршрутизации выбрать: BIRD2, FRR или VyOS?

Три варианта доминируют в BGP на Linux VPS. Все три поддерживают dual-stack (IPv4 + IPv6), RPKI-валидацию и необходимые для BYOIP функции. Выбор сводится к предпочтениям в стиле конфигурации и операционным требованиям.

Характеристика	BIRD2	FRRouting (FRR)	VyOS
Стиль конфигурации	Собственный декларативный язык	CLI в стиле Cisco IOS (vtysh)	CLI в стиле JunOS (set/commit)
Язык фильтрации	Мощные Тьюринг-полные фильтры	Route-maps + prefix-lists	Route-maps (FRR под капотом)
Dual-stack	Единый конфигурационный файл, мультитаблица	Отдельные блоки address-family	Отдельные блоки address-family
Поддержка RPKI	Встроенный протокол `rpki`	Встроенный модуль rpki	Через интеграцию FRR
Потребление памяти	Ниже (в 2 раза эффективнее FRR в бенчмарках)	Выше, особенно с полными таблицами	Выше (оверхед полной ОС)
Кривая обучения	Круче, если переходишь с Cisco	Низкая для пользователей Cisco/IOS	Низкая для пользователей JunOS
Лучше всего для	IXP route-серверы, сетапы с большим количеством политик	Привычный Cisco-воркфлоу	Полноценный роутер-ОС

BIRD2 обладает наиболее выразительным языком фильтрации. Можно писать сложные политики импорта/экспорта в одном конфигурационном файле. Он обрабатывает IPv4 и IPv6 в одном экземпляре демона. Потребление памяти примерно вдвое меньше, чем у FRR при аналогичной нагрузке. Компромисс: его синтаксис конфигурации не имеет аналогов в вендорском мире. Ты учишь язык BIRD или не используешь BIRD.

FRRouting (FRR) использует CLI в стиле Cisco IOS через vtysh. Если ты работал с Cisco, Arista или старым Quagga, FRR покажется знакомым сразу. Route-maps и prefix-lists работают, как ожидаешь. Это наиболее распространённая open-source routing suite.

VyOS — полноценная сетевая операционная система, использующая FRR в качестве движка маршрутизации. Всё настраивается через workflow set / commit в стиле JunOS. Предоставляет полноценный роутерный опыт: файрвол, NAT, VPN, DHCP и маршрутизация в одном пакете. На Virtua Cloud можно развернуть VyOS в один клик. Компромисс: это полноценная ОС, а не просто демон. Ты теряешь гибкость обычного Linux-сервера.

Что выбрать? Максимальный контроль и эффективность — BIRD2. Привычный Cisco-стиль на Linux — FRR. Выделенный роутер-апплайенс — VyOS.

Как защитить BGP-деплоймент?

Безопасность в BGP не опциональна. Неправильно настроенная BGP-сессия может утечь маршруты, принять угнанные префиксы или открыть сеть для инъекции трафика. Каждый BGP-деплоймент должен включать эти уровни защиты с первого дня.

RPKI и Route Origin Validation

Настрой демон на валидацию полученных маршрутов по RPKI-данным. Запусти локальный RPKI-кеш (Routinator или rpki-client) или подключись к хостинговому валидатору. Отклоняй маршруты со статусом RPKI «invalid». Это не даёт маршрутизатору принимать угнанные префиксы.

На 2025 год более 51% IPv4-маршрутов и 57% IPv6-маршрутов имеют валидные ROA. Все крупные транзитные провайдеры выполняют ROV. Если у твоих префиксов нет ROA, некоторые сети отбросят анонсы.

Фильтрация маршрутов

Никогда не используй export all или import all в продакшене. Это BGP-эквивалент chmod 777.

На стороне экспорта анонсируй только те префиксы, которые ты авторизован оригинировать. Используй prefix-list, явно соответствующий твоим выделениям. На стороне импорта, если ты single-homed (один аплинк), обычно принимаешь только дефолтный маршрут. При multi-homing фильтруй импорт по prefix-list и AS-path для предотвращения утечки маршрутов.

Отклоняй bogon-префиксы (пространство RFC 1918, документационные диапазоны, нераспределённые блоки) на импорте. Отклоняй префиксы длиннее /24 для IPv4 или /48 для IPv6. Установи max-prefix лимиты для защиты от пира, случайно сбросившего полную таблицу маршрутизации в сессию.

GTSM (Generalized TTL Security Mechanism)

GTSM (RFC 5082) гарантирует, что BGP-пакеты приходят с TTL 255, то есть они отправлены напрямую подключённым соседом. Это блокирует удалённых атакующих от инъекции BGP-пакетов. Большинство провайдеров поддерживают эту функцию. Включи на своей стороне, когда провайдер подтвердит поддержку.

Правила файрвола

Разреши TCP-порт 179 только с IP BGP-маршрутизатора провайдера. Отбрасывай всё остальное, направленное на порт 179. Это одно правило nftables или iptables, но оно предотвращает несанкционированные попытки BGP-подключения.

Типичные ошибки

rp_filter ломает трафик. Linux reverse path filtering (rp_filter=1, дефолт на многих дистрибутивах) отбрасывает пакеты, приходящие на интерфейс, если таблица маршрутизации ядра считает, что IP источника должен приходить на другой интерфейс. С BGP-анонсированными префиксами на dummy-интерфейсах это ломает легитимный трафик. Установи rp_filter=0 или rp_filter=2 (loose mode) на затронутых интерфейсах. Проверяй после каждого обновления ядра.

Путаница между конфигурацией BIRD 1.x и BIRD 2.x. BIRD 2 использует совершенно другой синтаксис конфигурации по сравнению с BIRD 1.x. Многие онлайн-туториалы (включая топовые результаты поиска у Vultr и других) до сих пор показывают синтаксис BIRD 1.x. Если скопировать конфигурацию из старого туториала в BIRD 2, демон откажется запускаться. Всегда проверяй версию через birdc show status.

Пропущенные IRR-объекты. Ты создал RPKI ROA, но забыл IRR route-объект. Автоматический построитель фильтров аплинка запрашивает IRR, не находит соответствующего объекта и молча отбрасывает анонс. Префикс RPKI-valid, но по-прежнему недоступен. Всегда создавай оба.

Что можно делать с BGP помимо базовых анонсов?

После того как префикс анонсирован и доступен, BGP открывает несколько продвинутых сценариев.

Anycast

Анонсируй один и тот же префикс с нескольких географических точек. Каждая площадка запускает идентичный сервис (DNS-резолвер, CDN-edge, API-эндпоинт). Пользователи маршрутизируются к ближайшей площадке по BGP path selection. Если площадка падает, её BGP-сессия обрывается, префикс отзывается с этой локации, и трафик автоматически переключается на оставшиеся площадки.

Anycast — принцип работы системы корневых DNS-серверов. Можно реализовать тот же паттерн с двумя-тремя VPS-нодами в разных дата-центрах.

Failover и multi-homing

Анонсируй префикс от двух провайдеров или с двух площадок одного провайдера. Используй LOCAL_PREF и MED для настройки приоритета primary/backup. При падении primary трафик переключается на backup в пределах окна конвергенции BGP (обычно 30-90 секунд с включённым BFD).

Для планового обслуживания используй community graceful shutdown (RFC 8326). Демон сигнализирует пирам деприоритизировать префикс перед тем, как ты остановишь сессию. Трафик перетекает на резервную площадку без потери пакетов.

BGP communities для traffic engineering

Communities — теги, привязанные к BGP-анонсам, влияющие на то, как вышестоящие сети обрабатывают твои маршруты. Типичные применения:

Blackhole community: сигнализируй аплинку отбрасывать весь трафик к определённому префиксу во время DDoS-атаки.
Управление prepending: попроси аплинк prepend'ить твой AS, чтобы сделать путь менее предпочтительным, перенаправляя трафик на другой аплинк.
Селективный анонс: анонсируй пирам, но не транзиту, или наоборот, контролируя, куда распространяется префикс.
Географическое ограничение: ограничь анонс определёнными регионами или IXP.

Каждый провайдер определяет свои значения communities. Проверь документацию BGP communities своего провайдера перед использованием.

Как мониторить BGP-анонсы?

Нужно знать, когда что-то меняется с твоими префиксами. Хайджеки маршрутов, случайные отзывы, изменения RPKI-статуса и падения видимости требуют немедленного внимания. Не думай, что анонсы стабильны, потому что вчера они работали.

BGPalerter — self-hosted инструмент мониторинга, наблюдающий за твоими префиксами и ASN. Подключается к публичным источникам BGP-данных (RIPE RIS, RouteViews) и алертит о:

Хайджеках префиксов (другой ASN оригинирует твой префикс)
Хайджеках подпрефиксов (кто-то анонсирует more specific твоего префикса)
Утечках маршрутов
Изменениях RPKI-статуса на invalid
Падениях видимости (префикс исчезает со значительного числа точек наблюдения)

Запускай его как systemd-сервис на отдельном VPS от того, который делает BGP. Если BGP-нода падает, ты всё ещё хочешь получать алерты. Настрой нотификации в Slack, email или свой мониторинг-стек.

Внешние инструменты валидации

Используй их для проверки, что анонсы выглядят корректно снаружи:

bgp.tools — вид в реальном времени на префикс, AS-path, RPKI-статус и IRR-консистентность
RIPE Stat — looking glass от RIR с историей маршрутизации и RPKI-валидацией
Hurricane Electric BGP Toolkit (bgp.he.net) — информация об AS, отчёты по префиксам, статус IRR и RPKI
Looking glass серверы — большинство транзитных провайдеров и IXP предоставляют looking glass для проверки, как твой префикс выглядит с их стороны

Проверяй эти инструменты после первого анонса и периодически потом. Анонс, который выглядит корректно с точки зрения твоего демона, может быть отфильтрован или угнан дальше по цепочке.

Полный путь: от нуля до мониторинга BGP

Полный маршрут со ссылками на статью для каждого шага:

Получить ASN от RIR через спонсирующего LIR.
Получить IP-пространство. Минимум /24 IPv4, /48 IPv6. От RIR или брокера.
Создать IRR route-объекты в базе RIPE для каждого префикса.
Создать RPKI ROA в портале RIR для каждого префикса.
Выбрать демон маршрутизации: BIRD2 , FRR или VyOS .
Настроить BGP на VPS. Поднять сессию, анонсировать префиксы, применить фильтры.
Защитить деплоймент. RPKI-валидация, фильтрация маршрутов, GTSM, правила файрвола.
Проверить снаружи. bgp.tools, RIPE Stat и looking glass провайдера.
Настроить мониторинг. Развернуть BGPalerter для отслеживания хайджеков и проблем видимости.
Освоить продвинутые сценарии. Communities , anycast , failover .

Нужен свой ASN или хватит приватного?

Если ты анонсируешь префиксы только одному аплинку и никогда не планируешь multi-homing или пиринг на IXP, приватный ASN (64512-65534 для 16-бит, 4200000000-4294967294 для 32-бит) может подойти. Провайдер убирает его из AS-path перед пропагацией маршрутов в аплинк.

Получи собственный публичный ASN, если верно хотя бы одно:

Планируешь подключение к нескольким аплинкам (multi-homing)
Хочешь пиринг на internet exchange
Хочешь, чтобы ASN был виден в traceroute и BGP looking glass
Хочешь использовать BGP communities, ссылающиеся на твой ASN
Управляешь сервисом, где сетевая идентичность важна (CDN, DNS, почтовая инфраструктура)

Разница в стоимости минимальна. Публичный ASN через RIPE NCC стоит сбор спонсирующего LIR (обычно несколько сотен евро в год). Для большинства сценариев публичный ASN — правильный выбор.