Глобальна система маршрутизації в Інтернеті функціонує завдяки протоколу граничного шлюзу BGP (Border Gateway Protocol). Щомиті понад сто тисяч Автономних Систем (AS) обмінюються маршрутними оголошеннями, визначаючи шлях передавання IP-пакетів крізь проміжні транзитні канали до кінцевих вузлів. Протягом кількох десятиліть ця децентралізована мережа спиралася на мовчазну довіру: оператори могли анонсувати префікси IP чи транзитні маршрути без математичних доказів відповідних повноважень.

Впровадження інфраструктури відкритих ключів ресурсів (RPKI) та механізму валідації походження маршрутів (Route Origin Validation — ROV, закріпленого в RFC 6811) стало визначним етапом у зміцненні безпеки міжавтономного обміну даними. ROV дозволяє маршрутизаторам перевіряти, чи має певна Автономна Система право генерувати оголошення для вказаного префікса відповідно до цифрового об'єкта ROA (Route Origin Authorization).

Проте архітектура ROV має відчутну сліпу зону: вона аналізує виключно систему-джерело (крайню праву AS в атрибуті AS_PATH). ROV неспроможна перевірити, чи є послідовність проміжних систем, які транспортують пакети, правомірною та дозволеною. Помилки адміністраторів або зловмисники можуть штучно додавати вузли до маршруту чи спричиняти руйнівні витоки маршрутів BGP (route leaks), спрямовуючи транскордонний трафік через неочікувані канали зв'язку.

Щоб подолати цю системну проблему, Інженерна рада Інтернету (IETF) розробила стандарт ASPA (Авторизація постачальників автономних систем) у межах RFC 9319 та супутніх специфікацій SIDROPS. ASPA забезпечує криптографічну перевірку проміжних транзитних зв'язків у BGP, усуваючи витоки маршрутів і маніпуляції з послідовностями AS у світових мережах.

+-------------------------------------------------------------------------+
|                 РОЗРИВ ЦІЛІСНОСТІ МАРШРУТУ BGP: ROV ТА ASPA             |
+-------------------------------------------------------------------------+
|                                                                         |
|  Префікс: 198.51.100.0/24   Вихідна AS: AS65001                         |
|                                                                         |
|  Анонс BGP AS_PATH у мережі:                                            |
|  [Tier-1 Провайдер AS100] -> [Мережа витоку AS200] -> [Клієнт AS65001]  |
|                                                                         |
|  1. Валідація походження RPKI ROV:                                      |
|     - Перевіряє ЛИШЕ кінцеву AS65001 праворуч.                          |
|     - Збіг префікса з об'єктом ROA є -> Статус: ЧИННИЙ (VALID)!         |
|     - Підсумок: ROV не бачить, чи має мережа AS200 дозвіл на транзит!   |
|                                                                         |
|  2. Авторизація постачальника RPKI ASPA:                                |
|     - Покроково перевіряє стосунки «клієнт-постачальник».               |
|     - Перевіряє: чи уповноважила AS65001 систему AS200 на транзит?      |
|     - Виявляє несанкціонований транзит і порушення правила valley-free! |
|     - Статус: INVALID -> Помилковий маршрут відкидається перед таблицею!|
+-------------------------------------------------------------------------+

Межі можливостей механізму перевірки походження (ROV)

Щоб оцінити важливість ASPA, необхідно проаналізувати межі захисту, які забезпечує ROV. Коли організація реєструє запис ROA у сховищі RPKI, цей криптографічний об'єкт прив'язує блок адрес (наприклад, 203.0.113.0/24) та граничну довжину маски до авторизованого номера вихідної системи (AS64496).

Отримавши оголошення BGP, граничний маршрутизатор перевіряє дві умови:

  1. Чи входить оголошений префікс у межі, визначені підписаним сертифікатом ROA?
  2. Чи збігається крайній правий номер AS в атрибуті AS_PATH із номером у записі ROA?

Якщо параметри збігаються, маршрут отримує позначку Valid. Якщо ж префікс оголошує стороння система, маршрут кваліфікується як Invalid і блокується.

Втім, ROV не здійснює жодної перевірки систем, які передують системі-джерелу. Мережа з кількома аплінками (multihomed), де сталася помилка фільтрації, або атакуючий можуть сформувати анонс, де джерело вказане цілком вірно, але проміжний ланцюг спотворено. Проміжна мережа може самовільно вклинитися в маршрут або передати трафік між непов'язаними пірами, порушуючи комерційні правила обміну без жодного попередження з боку ROV.

Природа витоку маршрутів BGP (RFC 7908)

Стандарт RFC 7908 визначає витік маршруту BGP як несанкціоноване поширення маршрутних анонсів за межі узгодженої зони взаємодії. У міжавтономній маршрутизації комерційні відносини спираються на класичну модель Гао-Рексфорд (Gao-Rexford model):

  • Клієнт — Постачальник (Customer-to-Provider): Клієнт оплачує постачальнику послуги глобального транзиту.
  • Постачальник — Клієнт (Provider-to-Customer): Постачальник передає дані до своїх платних клієнтів і від них.
  • Піринг (Peer-to-Peer): Дві мережі безкоштовно обмінюються трафіком своїх прямих користувачів на паритетних умовах.

За законами економіки маршрутизація повинна залишатися вільною від долин (valley-free). Мережа в жодному разі не повинна забезпечувати безкоштовний транзит між двома своїми провайдерами або двома безкоштовними пірами. Коли маршрут спустився вниз по ієрархії (від провайдера до клієнта чи між пірами), він не має права знову підійматися вгору до іншого постачальника або піра.

+-----------------------------------------------------------------------+
|                    ПОРУШЕННЯ ПРАВИЛА VALLEY-FREE                      |
+-----------------------------------------------------------------------+
|        [Магістральний провайдер A]         [Магістральний провайдер B]|
|                 │                                   ▲                 |
|                 │ (Від постачальника до клієнта)    │ (ВИТІК ШЛЯХУ!)  |
|                 ▼                                   │                 |
|      +---------------------------------------------------------+      |
|      |             Мультихомінг-підприємство AS300             |      |
|      |    Випадково реанонсує маршрути від провайдера A        |      |
|      |    безпосередньо на зовнішні канали провайдера B!       |      |
|      +---------------------------------------------------------+      |
+-----------------------------------------------------------------------+

Витоки маршрутів найчастіше виникають через людські помилки: мережевий інженер помилково налаштовує правила експорту (route-map) на межі мережі, або стається збій сценарію автоматизації під час профілактики. Коли мережа AS300 спрямовує маршрути постачальника A до постачальника B, сусідні автономні системи починають сприймати цей маршрут як привабливий і прямий.

Світовий інтернет-трафік, розрахований на потужні трансокеанські магістралі, несподівано спрямовується у вузькі канали підприємства AS300. Наслідком стає параліч каналу, зростання затримок до кількох секунд і масштабна втрата пакетів.

Резонансні інциденти минулих років — наприклад, переспрямування європейського мобільного трафіку через мережу металургійного заводу у 2019 році або збої хмарних сервісів — зачепили мільярди зашифрованих пакетів, не порушивши жодного правила класичного ROA.

Принцип дії ASPA: криптографічне підтвердження провайдерів

ASPA усуває цю вразливість через створення перевіреного ланцюга цифрових дозволів між автономними системами. Згідно з RFC 9319, власник Автономної Системи підписує та публікує запис ASPA у репозиторії RPKI.

Запис ASPA містить однозначну заяву, захищену електронним підписом:

  • Клієнтська AS (Customer AS — CAS): Система, яка надає авторизацію.
  • Список дозволених провайдерів (Provider AS Set — PAS): Повний перелік вищих автономних систем, яким клієнтська AS офіційно делегує право транспортувати її трафік і транслювати її анонси.

Запис ASPA підтримує протоколи IPv4 та IPv6. Оскільки об'єкти ASPA інтегровані в наявну структуру сертифікатів X.509 RPKI, вони успадковують аналогічні засоби перевірки цілісності, що й сертифікати ROA. Валідатори (Routinator, StayRtr, rpki-client) завантажують і перевіряють списки ASPA поруч з інформацією про префікси.

Алгоритм верифікації ASPA: дотримання принципу Valley-Free

Граничний маршрутизатор із підтримкою ASPA після отримання анонсу BGP звіряє ланцюг номерів AS в атрибуті AS_PATH із локальною базою даних ASPA.

Алгоритм почергово аналізує кожну пару сусідніх систем (AS(i), AS(i+1)) уздовж усього маршруту:

  1. Висхідна ланка (від клієнта до постачальника): Під час підйому від джерела до магістральних мереж кожен перехід AS(i) -> AS(i+1) має бути підтвердженим: AS(i+1) обов'язково повинна міститися в записі ASPA для AS(i).
  2. Вершина маршруту (Apex): Трафік досягає найвищого рівня ієрархії (оператора Tier-1 або прямого пірингового з'єднання).
  3. Низхідна ланка (від постачальника до клієнта): Під час спуску до адресата кожен перехід AS(i) -> AS(i+1) має підтверджувати, що AS(i) зареєстрована як легітимний провайдер у записі ASPA для AS(i+1).

Якщо алгоритм виявляє перехід від низхідного руху знову до висхідного (порушення принципу valley-free через витік між пірами або транзитерами) або стикається з неавторизованим посередником, маршрут позначається як Invalid.

Маршрутизатори з активною політикою ASPA блокують анонси з поміткою Invalid, захищаючи таблиці маршрутизації від некоректних даних.

Валідація на висхідних та низхідних з'єднаннях

Тип каналу, через який приходить анонс BGP, визначає напрямок і специфіку алгоритму перевірки:

Тип вхідного порту Очікувана структура AS_PATH Напрямок аналізу ASPA Головне захисне завдання
Від клієнта Виключно висхідний ланцюг (Клієнт -> Постачальник...) Перевірка знизу вгору (Customer-to-Provider) Захист від витоку маршрутів інших провайдерів клієнта
Від піра (Peer) Висхідна частина, піринговий стик, низхідна частина Двостороння перевірка правила valley-free Захист від бічних витоків і маніпуляцій з препендами
Від постачальника Підйом до вершини, після чого спуск до джерела Перевірка зверху вниз у бік початкової AS Блокування поширення транзитом чужих витоків

Здійснюючи математичні розрахунки на зовнішніх портах, оператори уникають потреби укладати громіздкі двосторонні угоди з віддаленими мережами. Некоректні маршрути відкидаються безпосередньо на апаратному рівні.

Вплив витоків маршрутизації на стабільність тунелів VPN

Віртуальні приватні мережі будують зашифровані канали поверх загальнодоступної інфраструктури. Хоча протоколи WireGuard та IPsec надійно захищають зміст пакетів, у фізичному середовищі вони залишаються звичайними IP-пакетами, що підпорядковуються маршрутизації BGP.

У разі витоку маршруту або підміни послідовності AS між користувачем і сервером VPN виникають три прямі загрози:

  1. Відмова в обслуговуванні через перевантаження вузлів: Витоки спрямовують трафік у слабкі регіональні канали. Накопичення черг у буферах (bufferbloat) і системні втрати пакетів руйнують контрольні пакети UDP keepalive, знижують пропускну здатність TCP і призводять до регулярних обривів зв'язку.
  2. Аналіз таймінгів і метаданих трафіку: Навіть без розшифрування інформації сторона, яка примусово спрямувала трафік VPN через свій вузол, може зіставляти часові інтервали, обсяги даних і метадані потоку, пов'язуючи дії клієнта з певними серверами.
  3. Зникнення пакетів у «чорних дірах»: Мережі, які спричинили витік, часто анонсують напрямки, не маючи фізичного зв'язку з кінцевою точкою, через що пакети VPN втрачаються до відновлення глобальної таблиці BGP.

Захист від маршрутних збоїв у комплексі RiceGuard та Anycast

Мережева структура VPNRice побудована з розрахунком на активну нейтралізацію деградації зовнішніх каналів. Поєднання швидкісного протоколу RiceGuard та архітектури BGP Anycast відокремлює призначений для користувача трафік від хаосу публічних ліній.

+-----------------------------------------------------------------------+
|                    АКТИВНИЙ ЕКРАН МАРШРУТИЗАЦІЇ RICEGUARD             |
+-----------------------------------------------------------------------+
|  [ Трафік застосунків користувача ]                                   |
|         │                                                             |
|         ▼                                                             |
|  [ Граничні адреси Anycast ]   -> Розміщені на магістралях Tier-1     |
|         │                                                             |
|         ▼                                                             |
|  [ Фільтрація RPKI ROV + ASPA] -> Перевірка AS_PATH на вході          |
|         │                                                             |
|         ▼                                                             |
|  [ Тунельний рушій RiceGuard ] -> Швидкісне шифрування ChaCha20       |
|         │                                                             |
|         ▼                                                             |
|  [ Чистий магістральний трафік]-> Без зайвих затримок і втрат         |
+-----------------------------------------------------------------------+

RiceGuard забезпечує надійність завдяки низці рішень:

  • Суворий контроль на стиках Tier-1: Вузли VPNRice підключаються лише до операторів першого рівня, які обов'язково застосовують валідацію RPKI ROV та правила ASPA на всіх інтерфейсах.
  • Географічний розподіл Anycast: Оголошення спільних префіксів із багатьох дата-центрів гарантує, що за локального витоку маршруту Anycast плавно спрямує потоки до сусіднього стабільного вузла.
  • Миттєве відновлення зв'язку: Завдяки оптимізованій передачі через UDP, після нормалізації маршрутів BGP протокол RiceGuard відновлює сесію за кілька мілісекунд без повторних тривалих погоджень.

Користувачі можуть завантажити надійні клієнтські програми для ПК та мобільних пристроїв на сторінці завантаження VPN.

Практичне впровадження: створення та публікація записів ASPA

Для активації механізму захисту ASPA адміністраторам автономних систем потрібно внести дані про авторизовані зв'язки через регіональні інтернет-реєстратори (RIR), зокрема RIPE NCC, ARIN чи APNIC.

Оформлення об'єктів ASPA здійснюється через вебінтерфейс порталу RPKI або локальні системи керування сертифікатами відповідно до стандарту RFC 8181.

Формат структури запису ASPA

Типове подання об'єкта ASPA у форматі JSON для корпоративної автономної системи (AS65100), яка зазначає своїх офіційних постачальників транзиту:

{
  "customer_asid": 65100,
  "providers": [
    {
      "provider_asid": 174,
      "afi": "both"
    },
    {
      "provider_asid": 2914,
      "afi": "both"
    },
    {
      "provider_asid": 3356,
      "afi": "both"
    }
  ]
}

У цій конфігурації:

  • customer_asid вказує номер системи-власника префіксів.
  • providers фіксує перелік схвалених операторів (Cogent AS174, NTT AS2914 та Lumen AS3356).
  • afi підтверджує чинність правила одночасно для протоколів IPv4 та IPv6.

Будь-який маршрутний анонс, де AS65100 буде оголошено через неузгоджену проміжну мережу, отримає статус Invalid і буде заблокований.

Налаштування маршрутизатора: увімкнення ASPA у BIRD та FRR

Популярні маршрутизатори з відкритим кодом, зокрема BIRD (починаючи з гілки 2.15) та FRRouting (FRR), мають вбудовану підтримку обробки записів ASPA.

Приклад конфігурації для BIRD 2

У файлі конфігурації BIRD модуль RPKI встановлює з'єднання з локальним демоном перевірки через протокол RTR (порт 8282):

# Підключення до локального валідатора RPKI RTR
protocol rpki rpki_validator {
    rtr 127.0.0.1 port 8282;
    retry 300;
    refresh 600;
    aspa 4; # Увімкнути ASPA для IPv4
    aspa 6; # Увімкнути ASPA для IPv6
}

# Визначення вхідного фільтра BGP із перевіркою ASPA
filter ebgp_in_filter {
    # Початкова перевірка джерела за ROV
    if roa_check(rpki_validator, net, bgp_path.last) = ROA_INVALID then {
        reject "Drop: ROV origin invalid";
    }

    # Перевірка правильності послідовності за ASPA
    if aspa_check(rpki_validator, bgp_path, 0) = ASPA_INVALID then {
        reject "Drop: ASPA verification failed (Route Leak detected)";
    }

    accept;
}

Розміщення інструкції aspa_check у вхідному фільтрі блокує спотворені анонси ще до їх потрапляння до системної бази маршрутів (RIB).

Порівняння ASPA та BGPSec: практична доцільність

Тривалий час еталоном безпеки вважався стандарт BGPSec (RFC 8205), який передбачає підписання кожного переходу між маршрутизаторами електронним підписом.

Проте повномасштабне впровадження BGPSec зупинилося через нездоланні практичні труднощі:

  • Колосальне апаратне навантаження: Постійне створення та перевірка підписів на портах у сотні гігабітів перевищує можливості співпроцесорів сучасних маршрутизаторів.
  • Зростання розміру пакетів: Додавання підписів викликає фрагментацію пакетів TCP і переповнення черг буферів.
  • Потреба в тотальному переході: Якщо хоча б один транзитний оператор на шляху не підтримує BGPSec, ланцюг довіри розривається.

На відміну від нього, ASPA пропонує прагматичний шлях:

  1. Збереження структури BGP: Формат пакетів BGP UPDATE у фізичній лінії не змінюється.
  2. Мінімальний вплив на CPU: Перевірка здійснюється через швидкий пошук у локальній таблиці пам'яті.
  3. Миттєва автономна користь: Якщо ваш прямий постачальник активував ASPA, захист починає діяти без очікування оновлення всього світового Інтернету.

Чекліст із безпеки маршрутизації для мережевих інженерів

Фахівцям із підтримки телекомунікаційної інфраструктури рекомендовано виконати такі кроки:

  1. Реєстрація об'єктів ROA: Створіть офіційні авторизації джерел для всіх належних вам діапазонів IPv4 та IPv6.
  2. Оформлення записів ASPA: Зафіксуйте в базі RPKI список офіційних постачальників транзиту, не забуваючи про резервні лінії.
  3. Налаштування суворого фільтра ROV: Сконфігуруйте обладнання на безумовне відкидання анонсів зі статусом ROA_INVALID.
  4. Оновлення демонів перевірки: Перейдіть на свіжі релізи валідаторів (Routinator 0.13+, StayRtr або rpki-client) із підтримкою таблиць ASPA.
  5. Моніторинг витоків: Використовуйте глобальні аналітичні платформи BGP для своєчасного виявлення аномальних маршрутів до ваших ресурсів.

Безпека маршрутизації глобального Інтернету потребує контролю не лише за адресою відправника, а й за всією траєкторією руху пакетів. Криптографічна перевірка шляхів за допомогою ASPA системно нейтралізує загрози витоків BGP, створюючи надійну платформу для стабільної роботи зашифрованих каналів зв'язку по всьому світу.