Сучасні телекомунікаційні мережі та хмарні центри обробки даних передають трафік сотень незалежних організацій через спільну фізичну інфраструктуру. У традиційній IP-маршрутизації кожен маршрутизатор підтримує одну загальну таблицю. Якщо два незалежних підприємства підключаються до одного пристрою та використовують однакові діапазони приватних підмереж стандарту RFC 1918, виникають конфлікти маршрутизації, що спричиняють втрату пакетів і витік конфіденційної інформації.

Для розв'язання цієї проблеми група IETF стандартизувала віртуальні приватні мережі BGP/MPLS IP у специфікації RFC 4364 (початково RFC 2547). Ця архітектура, відома в галузі зв'язку як BGP L3VPN, ізолює маршрутні домени користувачів на 3-му рівні за допомогою віртуальних екземплярів маршрутизації VRF (Virtual Routing and Forwarding), розширення MP-BGP (RFC 4760) та дворівневого конвеєра комутації міток MPLS.

Проблема багатокористувацької маршрутизації в корпоративних мережах

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

Базовий підхід полягає у фізичному розділенні каналів або побудові окремих шифрованих тунелів між кожною парою філій. Проте підключення сотень віддалених майданчиків створює квадратичне ускладнення $O(N^2)$, породжуючи серйозні експлуатаційні бар'єри:

  1. Магістральні вузли ядра вимушені зберігати мільйони маршрутів клієнтів, що вичерпує апаратну пам'ять TCAM.
  2. Простір адрес зазнає накладання, коли різні компанії застосовують поширені підмережі 10.0.0.0/8 або 192.168.1.0/24.
  3. Трудомісткість конфігурації стрімко зростає з появою кожного нового офісу.

Специфікація RFC 4364 усуває ці структурні обмеження. Завдяки зосередженню логіки обробки VPN суто на граничних маршрутизаторах оператора (Provider Edge, PE) і збереженню ядра (Provider, P) виключно для швидкої комутації міток, BGP L3VPN гарантує зв'язок між філіями з математично доведеною надійністю ізоляції.

+-----------------------------------------------------------------------------+
|                     СЕТЕВА ТОПОЛОГІЯ BGP L3VPN (RFC 4364)                   |
+-----------------------------------------------------------------------------+
[ CE-A1 ] ---> [ PE 1 ] ======================== [ PE 2 ] ---> [ CE-A2 ] (Клієнт A)
                  ||        (Ядро P: комутація міток)       ||
[ CE-B1 ] ---> [ PE 1 ] ======================== [ PE 2 ] ---> [ CE-B2 ] (Клієнт B)

Virtual Routing and Forwarding (VRF): сегментація таблиць та пам'яті

Фундаментом розмежування клієнтів на мережевому рівні є технологія Virtual Routing and Forwarding (VRF). Замість монолітної таблиці маршрутизатор PE розбиває площини керування та передавання даних на кілька автономних віртуальних маршрутизаторів.

Кожен екземпляр VRF володіє незалежною базою даних маршрутизації (RIB) і таблицею пересилання (FIB). Фізичні інтерфейси або логічні підінтерфейси з тегами VLAN стандарту IEEE 802.1Q прив'язуються безпосередньо до призначеного VRF.

Ізоляція площини керування та бази даних пересилання FIB

Коли маршрутизатор клієнта (Customer Edge, CE) анонсує діапазони адрес вузлу PE 1 через BGP, OSPF або статичні маршрути:

  • Оновлення заносяться виключно до таблиці RIB відповідного VRF.
  • Протоколи, що працюють усередині одного VRF, не мають доступу до інших контурів на тому самому шасі.
  • Перевірка пакетів, отриманих через клієнтський інтерфейс, здійснюється тільки за таблицею FIB закріпленого VRF.

Завдяки суворо ізольованому перегляду бази пересилання пакет Клієнта A не може бути скерований до Клієнта B, навіть якщо IP-адреса призначення цілком збігається з адресою мережі Клієнта B.

Опрацювання приватних адресних просторів за стандартом RFC 1918

Завдяки розділенню станів маршрутизації на рівні ядра системи різні підприємства можуть безперешкодно послуговуватися однаковими підмережами IPv4.

Наприклад, Клієнт A та Клієнт B можуть одночасно спрямовувати трафік у мережу 10.50.0.0/24. На пристрої PE:

  • Трафік Клієнта A перевіряє таблицю FIB екземпляра VRF-Alpha і прямує до CE-A2.
  • Трафік Клієнта B перевіряє таблицю FIB екземпляра VRF-Beta і прямує до CE-B2.

Проте щойно маршрути залишають PE та надходять до опорної мережі провайдера через протокол MP-BGP, класична маршрутизація IPv4 не здатна розрізнити однакові префікси. RFC 4364 розв'язує цю неоднозначність додаванням спеціальних розпізнавачів маршрутів.

Route Distinguishers (RD): забезпечення глобальної унікальності префіксів

Route Distinguisher (RD) — це числове поле завдовжки 8 байтів (64 біти), що призначається для кожного VRF. Під час перенесення маршруту IPv4 з клієнтського VRF до протоколу MP-BGP граничний маршрутизатор приєднує 8-байтовий префікс RD перед 4-байтовою адресою IPv4.

Утворена 12-байтова (96-бітна) конструкція має назву префікса VPN-IPv4 (AFI=1, SAFI=128):

+-----------------------------------------------------------------------------+
|                СТРУКТУРА АДРЕСИ ПРЕФІКСА VPN-IPV4 ЗА RFC 4364               |
+-----------------------------------------------------------------------------+
|     Route Distinguisher (64 біти)   |           Префікс IPv4 (32 біти)      |
+-------------------------------------+---------------------------------------+

Стандарт RFC 4364 визначає три типових формати поля RD:

  • Тип 0: Номер автономної системи (ASN) на 2 байти та 4-байтове числове значення (наприклад, 65001:100).
  • Тип 1: IP-адреса на 4 байти та 2-байтове числове значення (наприклад, 198.51.100.1:100).
  • Тип 2: Номер ASN на 4 байти та 2-байтове числове значення (наприклад, 4200000001:100).

Додавши 65001:100 до префікса Клієнта A та 65001:200 до префікса Клієнта B, мережі набувають вигляду 65001:100:10.50.0.0/24 та 65001:200:10.50.0.0/24. У протоколі MP-BGP вони інтерпретуються як абсолютно незалежні адреси й можуть співіснувати в одній таблиці без накладання.

Route Targets (RT): розширені спільноти BGP та політики розподілу

Поширеною помилкою є припущення, що Route Distinguisher вказує, до якого саме VRF має потрапити маршрут. Насправді RD не містить жодних правил маршрутної політики та призначений виключно для надання адресі унікальності.

Справжній розподіл та фільтрація маршрутів між різними VRF контролюються параметрами Route Target (RT), які функціонують у вигляді розширених спільнот BGP (BGP Extended Communities, RFC 4360).

[ VRF Alpha PE 1 ] ---> Експорт RT 65001:101 ---> [ Опорне ядро MP-BGP ]
                                                           |
[ VRF Alpha PE 2 ] <--- Імпорт RT 65001:101 <-------------+

Кожен VRF керує двома самостійними списками спільнот:

  • Export Route Targets: Додаються до клієнтських маршрутів під час передавання в MP-BGP.
  • Import Route Targets: Застосовуються для звірки під час надходження оголошень VPN-IPv4. Якщо маршрут містить RT зі списку імпорту, префікс звільняється від RD і додається до локальної таблиці RIB цього VRF.

Керування топологіями взаємодії: Hub-and-Spoke та Full-Mesh

Розмежування імпорту та експорту дає змогу конструювати різноманітні схеми обміну даними без зміни фізичних ліній зв'язку:

  • Повнозв'язна топологія (Full-Mesh): Усі підрозділи експортують та імпортують однаковий RT (export 65001:100, import 65001:100), що відкриває прямий обмін між філіями.
  • Зіркоподібна топологія (Hub-and-Spoke): Віддалені точки (Spoke) експортують RT-Spoke та імпортують RT-Hub. Центральний вузол (Hub) експортує RT-Hub та імпортує RT-Spoke. Пряма взаємодія між Spoke унеможливлюється, а весь потік обов'язково фільтрується через центральний міжмережевий екран.
  • Спільні сервіси (Extranet): Корпоративний VRF імпортує додатковий RT із сегмента загальних сервісів (DNS, каталоги облікових записів), що надає доступ до інфраструктури без розкриття основних клієнтських мереж.

Дворівневий стек міток: механізм пересилання пакетів MPLS та VPN

Після поширення маршрутів у площині керування фізичне передавання пакетів через ядро мережі здійснюється за допомогою дворівневого стека міток MPLS.

Коли вхідний маршрутизатор PE інкапсулює клієнтський трафік, він послідовно накладає дві незалежні 32-бітні мітки MPLS (RFC 3031):

+-----------------------------------------------------------------------------+
|                    ДВОРІВНЕВИЙ СТЕК МІТОК ПЕРЕСИЛАННЯ MPLS                  |
+-----------------------------------------------------------------------------+
| Кадр рівня 2 | Зовнішня мітка транспорту | Внутрішня мітка VPN | Дані IP    |
+-----------------------------------------------------------------------------+
  1. Внутрішня мітка (мітка VPN / сервісу): Призначається вихідним маршрутизатором (Egress PE) через MP-BGP. Вона вказує вихідному вузлу цільовий VRF або інтерфейс призначення після зняття інкапсуляції.
  2. Зовнішня мітка (транспортна мітка / IGP): Розподіляється протоколами LDP, RSVP-TE або Segment Routing. Вона спрямовує пакет транзитними вузлами P до адреси Loopback вихідного маршрутизатора.

Зовнішні транспортні мітки та масштабованість ядра мережі P

Така схема комутації забезпечує високу масштабованість магістралі:

  • Проміжні маршрутизатори P зчитують і комутують виключно зовнішню мітку.
  • Пристрої ядра не аналізують внутрішні IP-адреси клієнтів і мітки VPN.
  • Мережеве ядро звільнене від необхідності зберігати мільйони приватних маршрутів і працює лише з адресами граничних вузлів.

На передостанньому вузлі перед Egress PE спрацьовує процедура Penultimate Hop Popping (PHP), що знімає зовнішню мітку. Вихідний маршрутизатор отримує пакет лише з внутрішньою міткою, миттєво знаходить цільовий інтерфейс і передає чистий IP-пакет клієнту.

Безпека площини даних і ризики витоків VRF у хмарних підключеннях

Попри надійність механізмів BGP L3VPN, експлуатаційні помилки можуть призвести до порушення ізоляції:

  1. Помилкове схрещування Route Target: Описка в налаштуваннях імпорту (наприклад, додавання 65001:200 до контуру VRF-Alpha) відкриває маршрути між різними клієнтами, спричиняючи несанкціонований обмін даними.
  2. Атаки відмови в обслуговуванні через надлишок анонсів: Несправне або скомпрометоване обладнання клієнта може скинути тисячі фіктивних маршрутів, заповнивши пам'ять плат пристрою PE.
  3. Витоки маршрутизації в гібридних хмарах: Під час з'єднання локальних центрів із магістралями AWS Direct Connect або Azure ExpressRoute некоректні фільтри можуть спричинити поширення маршрутів за замовчуванням за межі периметра.

Інженери можуть перевіряти статус публічних виходів за допомогою сервісу перевірки власної IP-адреси.

Захист та зміцнення протоколу MP-BGP на граничних маршрутизаторах

Надійна експлуатація L3VPN передбачає обов'язкове застосування суворих правил фільтрації на маршрутизаторах PE.

У сучасних операційних системах (зокрема FRRouting, Cisco IOS-XR та Junos) налаштовуються ліміти префіксів та адресні фільтри. Нижче наведено зразок конфігурації FRRouting для створення VRF і розповсюдження маршрутів:

# Створення VRF та закріплення фізичного порту
ip link add dev vrf-tenant-a type vrf table 1001
ip link set dev eth2 master vrf-tenant-a
ip link set dev vrf-tenant-a up

# Налаштування процесу маршрутизації FRR
router bgp 65001
 address-family ipv4 vpn
  neighbor 198.51.100.2 activate
 exit-address-family
 !
 router bgp 65001 vrf vrf-tenant-a
  rd 65001:100
  address-family ipv4 unicast
   route-target export 65001:100
   route-target import 65001:100
   maximum-prefix 5000 80 warning-only
  exit-address-family

Основні вимоги безпеки охоплюють:

  • Обмеження кількості префіксів: Використання директиви maximum-prefix для клієнтських сесій BGP з метою автоматичного розриву з'єднання в разі перевищення ліміту.
  • Фільтрація за шляхами AS-path: Застосування списків доступу AS-path для відсікання приватних або підроблених номерів автономних систем.
  • Аутентифікація сесій TCP: Захист з'єднань MP-BGP між маршрутизаторами PE за допомогою механізму TCP-AO (RFC 5925) або підписів MD5 (RFC 2385) для запобігання підробці таблиць.

Реалізація криптографічної ізоляції клієнтів в архітектурі RiceGuard

Інфраструктура VPNRice використовує запатентований рушій RiceGuard на всіх граничних серверах мережі. Замість передавання незахищених міток MPLS через загальнодоступні канали, RiceGuard поєднує логічну ізоляцію RFC 4364 із наскрізним криптографічним захистом.

[ Пристрій клієнта ] ---> [ Граничний шлюз доступу RiceGuard ]
                                        |
     +----------------------------------+----------------------------------+
     | Логічний поділ VRF та інтелектуальна маршрутизація потоків          |
     | Криптографічне внутрішнє маркування (сегментація симетричних ключів)|
     +----------------------------------+----------------------------------+
                                        |
                    [ Захищена глобальна магістраль Anycast ]
                                        |
                                        v
                    [ Вихідний шлюз: передавання без витоків ]
  1. Криптографічна ізоляція VRF: RiceGuard прив'язує тунелі користувачів до виділених апаратних контекстів безпеки, гарантуючи ізоляцію даних окремими тимчасовими ключами.
  2. Обробка на повній швидкості ліній: Класифікація пакетів та перевірка правил виконуються в безблокувальних конвеєрах ядра, зберігаючи високу швидкість обробки на багатоядерних процесорах.
  3. Захист від перехоплення в транзиті: На відміну від стандартного транспорту MPLS, де пакети передаються відкрито між вузлами P, RiceGuard захищає міжрегіональний трафік всередині тунелів WireGuard, унеможливлюючи перехоплення на оптичних магістралях.

Для стабільного та захищеного підключення комп'ютерів і мобільних пристроїв встановіть офіційний застосунок.

Завантажити VPNRice.

Інженерам магістральних мереж пропонуємо ознайомитися з аналізом технології BGP EVPN All-Active Multi-Homing та дослідити роботу субсекундного моніторингу BFD. Крім того, рекомендуємо вивчити матеріал щодо ковзних вікон захисту від повторів IPsec RFC 4303.

Контрольний список впровадження надійних мереж BGP L3VPN

Розгортання відмовостійкої інфраструктури BGP L3VPN вимагає ретельної перевірки таких параметрів:

  • Уніфікація назв RD та RT: Запровадьте чіткий регламент іменування (наприклад, ASN:TenantID для RD та ASN:ServiceProfile для RT) для уникнення накладок.
  • Контроль кількості маршрутів CE: Застосовуйте суворі ліміти maximum-prefix на кожному клієнтському стику для захисту пам'яті маршрутизаторів PE.
  • Тестування зв'язності LSP в ядрі: Переконайтеся, що протоколи IGP та LDP/SR підтримують безперервні шляхи комутації міток між усіма адресами Loopback вузлів PE.
  • Контроль підключень Extranet: Під час спільного використання ресурсів між кількома VRF налаштовуйте чіткі правила імпорту Route Target, виключаючи потрапляння маршрутів за замовчуванням.
  • Шифрування транзитних ділянок: У разі передавання через публічні канали або хмари упаковуйте трафік MPLS у тунелі IPsec або WireGuard для збереження конфіденційності.
  • Моніторинг стабільності площини керування: Відстежуйте динаміку оновлень VPN-IPv4 у системі Prometheus для швидкого усунення зациклень маршрутів або нестабільних сесій.