Хмарному VPN потрібен BGP: чому інші протоколи маршрутизації не працюють

Асоціація безпеки IPsec встановлена, лічильники тунелю зростають, а трафік до хмарного префікса зникає. Тоді оператор намагається ввімкнути OSPF на клієнтському маршрутизаторі, очікує формування сусідства, і нічого не відбувається. Тунель ніколи не був відсутньою частиною: керований хмарний VPN надає визначений контракт маршрутизації, і на великих платформах цей контракт — BGP. Доки не існує сесії та не прийнято префікс, тунель — лише зашифрований шлях без пунктів призначення за ним.

Тунель піднято, а маршруту немає

Завершення фази 1 і фази 2 доводить, що сторони згодні щодо захисту, а не те, що якась сторона знає, куди надсилати трафік. Це окремі машини станів з окремими режимами відмови.

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

Що постачальник насправді дає

Керований шлюз VPN — не безмежний маршрутизатор. Постачальник дає шлюз із підтримуваними адресами сусідів, налаштуванням автономної системи, обмеженнями префіксів і визначеною поведінкою під час відмови. Ця поверхня і є продуктом.

Google Cloud описує динамічну маршрутизацію BGP для HA VPN, де Cloud Router вивчає маршрути сусідів і передає придатні користувацькі динамічні маршрути до VPC. AWS Site-to-Site VPN описує вибір між статичною та динамічною маршрутизацією і називає перевірки живучості BGP корисними для перемикання тунелю, водночас підтримуючи перевірки стану для пристроїв без BGP. Поведінку однієї платформи не можна виводити з назви продукту іншої.

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

Захист тунелю й доступність — різні завдання

IPsec захищає трафік, вибраний для тунелю. BGP постачає інформацію про доступність, яка робить префікс придатним. Робочий тунель не доводить, що очікуваний префікс було анонсовано, прийнято або встановлено.

Уявіть філію, яка анонсує 10.42.0.0/16 через два придатні шляхи тунелю. Приберіть один робочий шлях, і вибір маршруту може змінитися без того, щоб хтось редагував маршрут кожного робочого навантаження. Виявлення, вибір маршруту й відновлення застосунку не є миттєвими і не є однаковими в різних розгортаннях, тому тест перемикання має спостерігати всю послідовність, а не перший пакет, що пройшов.

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

Де руйнуються припущення про OSPF

OSPF, IS-IS або інший протокол усередині тунелю IPsec цілком можливий на самостійно керованому пристрої, де вам належать обидва кінці та схема пересилання. Цей факт нічого не говорить про керований сервіс, який пропонує лише BGP як режим динамічної маршрутизації.

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

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

Прочитайте вимогу сервісу, потім проєктуйте

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

Потім перевіряйте в тому самому порядку: сесію встановлено, префікс отримано, маршрут присутній у таблиці маршрутів VPC і є реальний потік до адреси сервісу. Повторіть після примусового перемикання, бо сесія, яка перевстановлюється, може повернутися з іншим набором маршрутів. Якщо проєкт залежить від збіжності менше секунди, виміряйте її, а не припускайте.

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