Bulud VPN üçün BGP lazımdır: digər marşrutlaşdırma protokolları niyə uğursuz olur
Tunel işləyir, prefiks isə heç vaxt görünmür. İdarə olunan bulud VPN-ləri marşrutlaşdırma müqaviləsi kimi BGP-dən istifadə edir, ona görə əvvəlcə xidmət tələbini yoxlayın.
IPsec təhlükəsizlik assosiasiyası qalxıb, tunel sayğacları hərəkət edir, bulud prefiksinə trafik isə yox olur. Sonra operator müştəri marşrutlaşdırıcısında OSPF-i aktivləşdirməyə çalışır, qonşunun qurulacağını gözləyir və heç nə baş vermir. Tunel heç vaxt çatışmayan hissə deyildi: idarə olunan bulud VPN-i müəyyən edilmiş marşrutlaşdırma müqaviləsi təqdim edir və böyük platformalarda bu müqavilə BGP-dir. Sessiya yaranana və prefiks qəbul edilənə qədər tunel arxasında heç bir təyinat olmayan şifrələnmiş yoldur.
Tunel qalxıb, marşrut isə yoxdur
Faza 1 və faza 2-nin tamamlanması tərəflərin müdafiə barədə razılaşdığını sübut edir, tərəflərdən birinin trafiki hara göndərəcəyini bildiyini deyil. Bunlar ayrı nasazlıq rejimləri olan ayrı vəziyyət maşınlarıdır.
Sıra ilə üç sual verin: prefiks elan olundumu, qarşı tərəf onu qəbul etdimi və yönləndirmə üçün quraşdırıldımı? Elan olunub filtrlənən prefiks siyasət problemidir. Heç vaxt elan olunmayan prefiks sessiya və ya konfiqurasiya problemidir. Qəbul olunub quraşdırılmayan prefiks isə marşrut seçimi problemidir və hər cavab konfiqurasiyanın fərqli hissəsinə işarə edir.
Provayder sizə əslində nə verir
İdarə olunan VPN şlüzü məhdudiyyətsiz marşrutlaşdırıcı deyil. Provayder sizə dəstəklənən qonşu ünvanları, avtonom sistem parametri, prefiks limitləri və müəyyən edilmiş nasazlıq davranışı olan şlüz verir. Bu səth məhsulun özüdür.
Google Cloud HA VPN üçün dinamik BGP marşrutlaşdırmasını sənədləşdirir; Cloud Router qonşu marşrutlarını öyrənir və VPC-yə uyğun fərdi dinamik marşrutlar verir. AWS Site-to-Site VPN statik və dinamik marşrutlaşdırma arasında seçimi sənədləşdirir və BGP canlılıq yoxlamalarını tunel ehtiyat keçidi üçün faydalı kimi təsvir edir, eyni zamanda BGP olmayan cihazlar üçün sağlamlıq yoxlamalarını da dəstəkləyir. Heç bir platformanın davranışı digərinin məhsul adından çıxarılmamalıdır.
Praktiki nəticə budur ki, əvvəlcə idarə olunan rejimi seçirsiniz, sonra dəstəklənən düymələri oxuyursunuz. Xidmətin təklif etmədiyi qonşuluq tipini fərz edən dizayn müştəri marşrutlaşdırıcısında həll olunacaq konfiqurasiya problemi deyil.
Tunel müdafiəsi və əlçatanlıq ayrı işlərdir
IPsec tunel üçün seçilmiş trafiki qoruyur. BGP isə prefiksi uyğun edən əlçatanlıq məlumatını verir. İşləyən tunel gözlənilən prefiksin elan olunduğunu, qəbul edildiyini və ya quraşdırıldığını sübut etmir.
Təsəvvür edin, bir filial 10.42.0.0/16-nı iki uyğun tunel yolu ilə elan edir. Bir işlək yolu çıxarın və heç kim hər iş yükünün marşrutunu redaktə etmədən marşrut seçimi dəyişə bilər. Aşkarlama, marşrut seçimi və tətbiqin bərpası ani deyil və yerləşdirmələr arasında eyni deyil, ona görə ehtiyat keçid testi keçən ilk paketi deyil, bütün ardıcıllığı müşahidə etməlidir.
Bulud prefiksi əlçatmaz olduqda, kriptoya toxunmadan əvvəl sessiya vəziyyətini və öyrənilmiş marşrutları yoxlayın. Arxasında marşrut olmayan qalxmış SA bu simptomun ən çox yayılmış variantıdır.
OSPF fərziyyələri harada pozulur
IPsec tunelinin içində OSPF, IS-IS və ya başqa protokol tamamilə mümkündür — hər iki ucu və yönləndirmə dizaynını özünüz idarə etdiyiniz özünüidarə edilən cihazda. Bu fakt dinamik marşrutlaşdırma rejimi kimi yalnız BGP təklif edən idarə olunan xidmət barədə heç nə demir.
Təklif olunan dizayn xidmətin dəstəkləmədiyi qonşuluq tələb edirsə, arxitekturanı qəsdən dəyişin. Seçimlərə VPC-də özünüidarə edilən cihaz, xidmətin dəstəklədiyi yerdə statik marşrutlaşdırma və ya fərqli bağlantı məhsulu daxildir. Protokolu yalnız müştəri marşrutlaşdırıcısında konfiqurasiya etmək bulud tərəfində mövcud olmayan qonşu əlavə edə bilməz və prefiksi görünən etməyəcək.
Bir satıcının cavabını digər satıcının şlüzünə daşımayın. Dinamik marşrutlaşdırma və ya tunel ehtiyat keçidi kimi eyni sözlər fərqli mexanizmləri və fərqli limitləri təsvir edə bilər.
Əvvəlcə xidmət tələbini oxuyun, sonra dizayn edin
İlk konfiqurasiya sətrindən əvvəl qonşu ünvanlarını, avtonom sistem nömrələrini, elan edib qəbul edəcəyiniz prefiksləri, marşrut limitlərini və tunel sıradan çıxdıqda gözlənilən davranışı yazın. Bu beş bənd dizayn etdiyiniz müqavilədir.
Sonra eyni sıra ilə yoxlayın: sessiya qurulub, prefiks alınıb, marşrut VPC marşrut cədvəlindədir və xidmət ünvanına real axın var. Məcburi ehtiyat keçiddən sonra təkrarlayın, çünki yenidən qurulan sessiya fərqli marşrut dəsti ilə qayıda bilər. Dizayn saniyəaltı yaxınlaşmadan asılıdırsa, onu fərz etmək əvəzinə ölçün.
Xidmət müqaviləsini dəyişiklik qeydi ilə birlikdə saxlayın. Sonra kimsə tunelin niyə OSPF işlədə bilmədiyini soruşanda cavab protokol məhdudiyyəti deyil, məhsul sərhədidir və qeyd bunu deməlidir.