Облачният 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, отговорът е граница на продукта, а не ограничение на протокола, и записът трябва да го казва.