Azure NVA yoxlaması: cavab niyə başqa firewall-dan keçir

Filialdan Azure-a axın hər iki istiqamətdə düzgün marşrutlaşdırıla bilər və yenə də uğursuz ola bilər, çünki iki istiqamət fərqli cihazlardan keçir. Sorğu filialdan VPN ilə çıxır, NVA A-ya düşür və iş yükünə çatır. Cavab iş yükündən çıxır, NVA B-yə işarə edən marşruta uyğun gəlir və orada ölür. O şəkildəki hər marşrut etibarlıdır, amma TCP sessiyası yenə də qırıqdır.

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

Bu boşluq burada bütün mövzudur: marşrutlaşdırma konvergensiyası və sessiya vəziyyətinin sahibliyi diaqramda eyni görünən fərqli problemlərdir.

Route Server əslində nə proqramlaşdırır

Azure Route Server dəstəklənən BGP danışanları ilə peer bağlayır, onların marşrutlarını öyrənir və virtual şəbəkənin effektiv marşrutlarına proqramlaşdırır. Bu, idarəetmə müstəvisi işidir. O, vendor firewall-unun sessiya cədvəlini oxumur və verilmiş bağlantını hansı cihazın buraxdığını bilmir. İki bərabər xərcli növbəti hop, fabric üçün sadəcə eyni prefiksə çatmağın iki yoludur və o, hər ikisini istifadə edəcək.

Deməli, marşrut öyrənmək çatıla bilənliyi sübut edir. Qarşı tərəfdəki cihazın bu axını əvvəl görüb-görmədiyi barədə heç nə sübut etmir.

Dizayn etməzdən əvvəl hər iki istiqaməti oxu

Hər istiqamətdə həqiqətən malik olduğunuz yönləndirməni yazmağa başlayın, nəzərdə tutduğunuzu deyil. Daha spesifik BGP marşrutları, istifadəçi təyin etdiyi marşrutlar və şlüz davranışı hamısı rəqabət edir və qalib sessiya üzrə deyil, təyinat üzrə müəyyən edilir. NVA-da default marşrut hər xüsusi prefiksin ondan keçdiyi anlamına gəlmir.

Faydalı yoxlama konkret bir iş yükü IP-si üçün hər istiqamətin hansı növbəti hopa çevrildiyini soruşmaqdır. Cavab iki fərqli cihazdırsa, üzə çıxıb-çıxmadığından asılı olmayaraq asimmetriya probleminiz var.

Vəziyyət harada yaşayır

Vəziyyətli firewall bağlantını qəbul edir və beşli tuple üzərində açarlanmış cədvəl qeydi saxlayır. Cavab həmin qeydi saxlayan cihaza çatmalıdır, ya da o cihaz vəziyyəti başqa yolla almalıdır. Azure data müstəvisində heç nə qeydi cihazlar arasında ötürmür. Ya trafik sahibinə geri yönləndirilir, ya cihazlar vendor mexanizmi ilə vəziyyəti paylaşır, ya da dizayn işləmir.

Buna görə iki sağlam NVA yoxlama üçün sağlamlıq yoxlaması deyil. Sağlamlıq çatıla bilənliklə bağlıdır; yoxlama sessiyanı hansı instansın saxladığı ilə bağlıdır.

Dəstəklənən HA modelləri və hər birinin nə vəd etdiyi

Microsoft's guidance on Virtual WAN marşrutlaşdırma niyyəti barədə təlimatı ikili rollu bağlantı və firewall NVA-ları üçün əhatəli davranışı təsvir edir; burada birbaşa marşrutlaşdırma hub-un normal simmetrik tətbiqini yan keçə bilər. O qeydləri seçdiyiniz topologiyaya məhdudiyyətlər kimi oxuyun, aktiv-aktiv dizaynlara qadağa kimi deyil. Vəziyyəti sinxronlaşdıran və ya axın üzrə yönləndirən vendor cütlüyü dəstəklənə bilər. Buna heç birini etməyən bərabər xərcli cütlük dəstəklənmir.

Sonra node uğursuz olanda mövcud sessiyalara nə olacağını müəyyənləşdirin. Marşrut konvergensiyası yeni axınlar üçün çatıla bilənliyi saniyələr içində bərpa edir, köhnə firewall vəziyyəti isə sadəcə yox olur. Müştərinin yenidən qoşulması sənədləşdirilmiş nəticə ola bilər və bu, insident zamanı deyil, ondan əvvəl veriləcək qərardır.

Etibar etməzdən əvvəl nəyi sınaqdan keçirməli

Test with inspection enabled and iş yükünün giriş siyasəti yerində olmaqla sınaqdan keçirin, çünki ikisindən biri asimmetriyanı gizlədə bilər. Hər iki istiqamətdə yeni icazəli axın göndərin və eyni cihazın hər iki yarısını gördüyünü təsdiqləyin. Sonra davamlı trafik işlədin və təsdiqlənmiş failover-i tetikləyin, qurulmuş sessiyaların sağ qalıb-qalmadığını və ya yenidən qoşulduğunu izləyin.

Hər axını onu emal edən cihazla əlaqələndirin. Bir NVA-da paket tutumu, cavab heç vaxt ora qayıtmayıbsa, demək olar ki, heç nə demir.

Nəhayət, planı üç ayrı sətir kimi yazın: marşrut sahibliyi, trafik yönləndirməsi və sessiya vəziyyətinin sahibliyi. İlk ikisi həll olunub üçüncüsü fərz edildikdə dizaynlar pozulur.