VGW BGP elanları VPC marşrut cədvəlinə qarşı: nə nəyi dəyişir

VPC subnet marşrut cədvəlində çatışmayan prefiks ilə müştəri marşrutlaşdırıcısında çatışmayan prefiks iki fərqli nasazlıqdır və onlardan yalnız biri AWS marşrut cədvəlləri daxilində bərpa olunur. Virtual özəl şlüz öz VPC-si ilə əlaqəli CIDR bloklarını elan edir; subnet marşrut cədvəli isə iş yükünün cavabı hara göndərəcəyini müəyyən edir. İkincisini birincini dəyişməyin yolu kimi görmək bu diaqnozda ən çox rast gəlinən səhv dönüşdür. Aşağıdakı yoxlamaları ardıcıllıqla aparın və iki istiqaməti ayrı saxlayın.

Hər hansı cədvəli oxumazdan əvvəl birləşmənin adını müəyyənləşdirin

Saytdan-sayta VPN ya virtual özəl şlüzdə, ya da tranzit şlüzdə bitir və resurs ID-ləri hansı marşrutlaşdırma modelinin tətbiq olunduğunu müəyyən edir. Əvvəlcə onları oxuyun: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Cavab növbəti baxılacaq cədvəlin VPC marşrut cədvəli, yoxsa tranzit şlüz marşrut cədvəli olduğunu bildirir.

VPN tranzit şlüzə qoşulubsa, VPC marşrut cədvəlini idarəetmə müstəvisi kimi qəbul etməyi dayandırın. Orada VPC cədvəli şlüz birləşməsinə işarə edir, assosiasiya və yayılma isə tranzit şlüz marşrut cədvəlində baş verir. İki baxışı qarışdırmaq yanlış obyekt barədə inamlı nəticələr doğurur.

AWS-dən ofisə istiqamət elandır

VGW birləşməsi üçün şlüz öz VPC-si ilə əlaqəli CIDR bloklarını BGP vasitəsilə müştəri şlüzünə elan edir. Fərdi subnet marşrutu əlavə etmək və ya marşrutu peer VPC-yə və ya cihaza yönəltmək başqa əlaqəli CIDR əlavə etmir və həmin elanda görünmür. Ofisdə prefiks çatışmırsa, hər hansı marşrut cədvəlini redaktə etməzdən əvvəl alınan marşrutlar siyahısını VPC assosiasiyaları ilə müqayisə edin.

Sadə qaydanın istisnaları var, ona görə onu əhatə dairəsində saxlayın. VPN CloudHub quruluşu sayt prefikslərini müştəri şlüzləri arasında yenidən elan edə bilər, tranzit şlüz isə öz yayılma qaydalarına tabedir. VGW-nin yalnız öz VPC-sini elan etdiyi ifadəsi faydalı standartdır, rastlaşacağınız hər topologiyanı əhatə edən qanun deyil.

Ofisdən AWS-yə istiqamət yayılma və seçimdir

Əks istiqamətdə VGW ofis prefiksini öyrənir, lakin bu təkbaşına iş yükünü yerindən tərpətmir. Subnet marşrut cədvəlində ya birləşmə üçün yayılma aktiv olmalıdır, ya da eyni təyinat üçün statik marşrut olmalıdır. Bir prefiks üçün hər ikisi varsa, statik marşrut qalib gəlir və ən uzun prefiks uyğunluğu onlardan əvvəl işləyir.

Mənşəyi ehtimal etmək əvəzinə oxuyun: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Mənşəyi EnableVgwRoutePropagation olan qeyd BGP-dən gəlib; mənşəyi CreateRoute olan qeydi insan yazıb və kimsə onu silənə qədər qalib gəlməyə davam edəcək.

İki istiqaməti ayrı saxlayan runbook

Heç nəyi dəyişməzdən əvvəl AWS tərəfində dörd faktı qeyd edin: birləşmə növü, əlaqəli VPC CIDR-ləri, sözügedən prefiks üçün subnet marşrutunun mənşəyi və tunel ilə BGP vəziyyəti. Həmin describe çağırışı hər tunel üzrə qəbul edilmiş marşrut sayı ilə VgwTelemetry qaytarır və bu, AWS-in ümumiyyətlə hər hansı marşrut qəbul edib-etmədiyini bildirir. Sonra bunu müştəri cihazının həqiqətən quraşdırdığı ilə müqayisə edin. BGP-də olub yönləndirmə cədvəlində olmayan prefiks yerli idxal və ya ən yaxşı yol probleminə aiddir, AWS marşrut cədvəli probleminə yox.

Subnet cədvəlində prefiks tamamilə yoxdursa, yayılmanı aktivləşdirin və ya statik marşrut əlavə edin, sonra dəyişikliyin dərhal olduğunu güman etmək əvəzinə yayılma intervalından sonra eyni sorğunu yenidən oxuyun. Prefiks varsa və trafik yenə uğursuz olursa, idarəetmə müstəvisini tək qoyun və məlumat yoluna keçin.

Orada olarkən nələri dəyişmək lazım deyil

Bir çatışmayan prefiksi düzəltmək üçün əlaqəsiz marşrut cədvəllərində yayılmanı açıb-qaçmayın və tək bir olmayan CIDR-ı ört-basdır etmək üçün standart marşrut əlavə etməyin. Hər iki dəyişiklik təsir sahəsini genişləndirir və növbəti diaqnozu çətinləşdirir. Düzəlişi yalnız sözügedən iş yükü subnetinə xidmət edən cədvəllə məhdudlaşdırın.

Məlumat yolu bütün bunlardan ayrıdır. Təhlükəsizlik qrupları vəziyyət daşıyır, şəbəkə ACL-ləri isə yox, və host firewall-u ya asimmetrik dönüş yolu marşrutlaşdırmanın düzgün çatdırdığı trafiki ata bilər. Elan edilən aqreqat həm də içindəki hər xidmətə icazə vermir, ona görə girişi siyasət sərhədində məhdudlaşdırın, ünvanın təsadüfən BGP elanında görünüb-görünməsindən asılı olmayın.

Hər marşrut cədvəli sorğusunun əvvəlini və sonrasını dəyişiklik qeydində saxlayın. Dəyişiklik vəziyyəti pisləşdirsə, əvvəlki marşrutları bərpa edin və eyni sorğu ilə təsdiqləyin, çünki yoxlaya bilmədiyiniz geri qaytarma yalnız təxmindir.