Çox NIC-li GCP VM: cavablar niyə yanlış interfeysdən çıxır

Compute Engine VM-ə ikinci interfeys qoşmaq ona daha bir şəbəkə bağlantısı verir, simmetrik qayıdış yolu yox. Qonaq hələ də interfeysi və mənbə ünvanını öz marşrut və qaydalarından seçir. Sonra Google Cloud paketin hansı interfeysdən çıxdığından asılı olmayaraq VPC marşrutlaşdırmasını və firewall siyasətini tətbiq edir. Bu iki qərar uyğun gəlmədikdə sorğular bir NIC-ə gəlir, cavablar isə digərindən çıxır və filial yarım-açıq söhbət görür.

Yolu beş addımda izləyin və uyğunsuzluq siyasət qaydası yazmazdan əvvəl görünəcək.

Addım 1: bulud NIC-lərini qonaq cihazlarına uyğunlaşdırın

Bulud interfeysləri nic0, nic1 və başqaları adlandırır, qonaq isə uyğun gəlməsi məcburi olmayan cihaz adları görür. Xəritələməni hər şeydən əvvəl instansiya metadatasından və ya interfeysin öz ünvanından həll edin. DHCP-nin verdiyi adi defolt marşrut nic0 ilə əlaqələndirilir, buna görə də internetə baxan yol tez-tez təsadüfən qalib gəlir. Təxmin edilən cihaz adına görə siyasət yazmaq düzgün qaydanın yanlış interfeysə düşməsinin yoludur.

Ünvanları, cihaz adlarını və hər birinin aid olduğu VPC-ni qeyd edin. Bu üç sütunlu xəritə hər sonrakı addımın girişidir.

Addım 2: iki marşrut qərarını adlandırın

Birinci qərar qonağa aiddir: bu paket üçün hansı interfeys və hansı mənbə ünvanı. İkincisi buluda aiddir: VPC-nin marşrutları və firewall siyasəti həmin interfeys ətrafında nəyə icazə verir.

VPN-ə baxan VPC-də görünən marşrut həmin NIC-i seçən qonaq marşrutuna çevrilmir. Bulud marşrutu şəbəkənin nə çatdıra biləcəyini təsvir edir, qonaq marşrutu isə paketin nə edəcəyini müəyyənləşdirir.

Addım 3: qayıdış yolu siyasəti seçin

Kiçik və sabit filial prefiksləri dəsti üçün qonaqda açıq təyinat marşrutları ən sadə ifadədir: həmin prefikslərə cavablar VPN-ə baxan interfeysdən çıxır. Bir neçə xidmət qəsdən fərqli yerli mənbə ünvanları istifadə etdikdə, hər interfeys üçün cədvəl seçən mənbə əsaslı qaydalar hər cavabı düzgün kontekstdə saxlayır. Çoxinterfeysli sənədləşmə bu dizaynların dayandığı NIC adlandırmasını və defolt marşrut davranışını təsvir edir.

Hər cədvələ etibarlı bağlı marşrutlar və növbəti hoplar, üstəlik ondan tələb olunacaq təyinatlar lazımdır. Natamam cədvələ yönələn qayda qayıdış yolu dizaynı deyil. Həmin NIC üçün sənədləşdirilmiş şlüzü istifadə edin, alt şəbəkənin görünüşündən Ethernet şlüzü uydurmayın.

Addım 4: qonağın öz filtrlərini yoxlayın

Serverin harada dinlədiyini və cavabın hansı yerli mənbəni daşıdığını yoxlayın. Bütün ünvanları dinləyən server marşrutlaşdırma siyasətini ləğv etmir, ona görə hər ünvana bağlanmaq cavabın çıxdığı interfeysi dəyişmir.

Linux-da tərs yol yoxlamasını nəzərdə tutulan dizaynla müqayisə edin. Onu ilk addım kimi qlobal söndürmək marşrutlaşdırma xətasını saxtalaşdırma riski ilə dəyişir və tapmağa çalışdığınız asimmetriyanı gizlədir.

Addım 5: hər yol üçün bir axın sınaqdan keçirin

İcazə verilmiş filial sorğusunu və əlaqəsiz internet sorğusunu ayrı-ayrılıqda, hər birini öz real mənbəyi və təyinatı ilə yoxlayın. Mümkün olduqda hər iki interfeysdə paket tutun, çünki faydalı sübut cavabı hansı interfeysin daşıdığıdır. Sonra bulud tərəfindəki siyasətin dizayn etdiyiniz yola riayət etdiyini təsdiqləyin. Bir uğurlu sorğu bir axını sübut edir, simmetrik dizaynı yox.

İki testi qeydlərinizdə ayrı saxlayın, çünki onlar fərqli marşrutları və fərqli firewall qaydalarını yoxlayır.

İkinci NIC sizə nə vermir

İkinci interfeys şəbəkə bağlantısı və daha bir ünvan əlavə edir. Avtomatik simmetrik marşrutlaşdırma əlavə etmir və firewall siyasətini yan keçmir. Ona marşrutlaşdırma düzəlişi kimi baxmaq çox NIC-li dizaynların sonradan heç kimin izah edə bilmədiyi qaydalar yığmasının səbəbidir.

VM başqa maşınların trafikini yönləndirməlidirsə, bu marşrutlaşdırıcı rolunu açıq şəkildə planlaşdırın, yönləndirməyə icazə verən bulud parametri və ona uyğun qonaq filtrləri də daxil olmaqla.