GKE podları VPN üzərindən niyə yerli serverlərə çatmır

Ping node-dan işləyir və pod-dan uğursuz olur, yerli şəbəkəyə isə heç nə çatmır. Tunel və marşrut qaydasındadır; kabldakı mənbə ünvanı deyil. Bu iki hal arasındakı fərq paketin klasterdən çıxarkən özünü nə kimi təqdim etməsidir və GKE-in bu barədə öz fikri var. Mexanizm masquerade istisna siyahısıdır və onu oxumaq bir əmr çəkir.

Bir şeyi dəyişməzdən əvvəl qüvvədə olan siyahını oxuyun

GKE hər təyinat aralığı üzrə pod trafikinin çıxışda node ünvanına yenidən yazılıb-yazılmayacağına qərar verən agent ilə gəlir. Onun standart konfiqurasiyası üç RFC1918 blokunu, 10.0.0.0/8, 172.16.0.0/12 və 192.168.0.0/16, istisna edilmiş təyinatlar kimi göstərir. Buna görə pod-dan yerli 10.x hostuna göndərdiyiniz hər şey node-dan podun öz ünvanı hələ də üzərində olmaqla çıxır. Node-un öz trafiki yenidən yazılmır və onun pinginin işləməsinin səbəbi məhz budur.

Nəzərdə tutulan konfiqurasiyanı və quraşdırılmış qaydaları oxuyun, çünki onlar ziddiyyət təşkil edə bilər. kubectl -n kube-system get configmap ip-masq-agent -o yaml agentə nə deyildiyini, kubectl -n kube-system get pods -l k8s-app=ip-masq-agent isə bunu tətbiq etmək üçün nəyinsə işləyib-işləmədiyini göstərir. Node-da iptables-save | grep -i masq nüvədə həqiqətən mövcud olan qaydaları göstərir. ConfigMap bir şey deyir, qaydalar başqa şey deyirsə, şübhəli şəxs şəbəkə deyil, agentdir.

Mənbə ünvanını tutma ilə təsdiqləyin

Siyahını dəyişməzdən əvvəl tutma aparın. Tək təyinat üzrə filtr çıxışı oxunaqlı saxlayır: tcpdump -ni any host 10.20.30.40.

Bunu qarşı tərəfin bildirdikləri ilə müqayisə edin. Yerli şəbəkədə pod ünvanını göstərən və cavab olmayan tutma dövrəni bağlayır: istisna siyahısı asimmetriyanı heç bir tunel nasazlığı olmadan izah edir. Bir mənbə ünvanının iki müşahidəsi CNI barədə təxmin etməyi dayandırmaq üçün kifayətdir.

İstisnanı pod CIDR-i ilə məhdudlaşdırın

Dəstəklənən düzəliş istisnanı silmək əvəzinə daraldır: pod CIDR-ini istisna saxlayın və 10.x fəzasının qalanını çıxarın. Bu siyahı agentin ConfigMap-ində nonMasqueradeCIDRs altında yerləşir və onu dəyişmək redaktə, ardınca yayım deməkdir. Geniş qeydi klasterin faktiki pod aralığı ilə əvəz edin, digər özəl blokları klasterdaxili trafik hələ də onlara ehtiyac duyursa saxlayın və səbəbiniz yoxdursa resyncInterval-ə toxunmayın. Tətbiq edin, agent podlarının yenidən başladığını və nüvə qaydalarının dəyişdiyini təsdiqləyin.

Bu, real təsir radiusu olan klaster miqyaslı dəyişiklikdir. O qüvvəyə mindikdən sonra əvvəl pod mənbəyini saxlayan trafik indi node-a yenidən yazılmış şəkildə gəlir, buna görə həmin pod ünvanlarına bağlanan hər şey fərqli göndərən görür. İtkilər pod ünvanlarını adlandıran loglar, icazə siyahıları və yerli firewall qaydalarıdır və onlar səssizcə sıradan çıxır. Dəyişikliyi düzəliş kimi deyil, davranış dəyişikliyi kimi elan edin.

Bir neçə node hovuzu olan klasterdə agentin təsirlənmiş podların həqiqətən işlədiyi node-larda planlaşdırıldığını yoxlayın. DaemonSet olmayan hovuz köhnə qaydalarını saxlayır və ConfigMap-də bunu göstərən heç nə olmayacaq.

Alternativ və onun qiyməti

Digər variant pod ünvanlarını toxunulmaz saxlayır və yola onları öyrədir. Pod CIDR-i Cloud VPN trafik seçicilərinə daxil olur və yerli tərəfə cavabların hara gedəcəyini bilməsi üçün onun üçün geri marşrut lazımdır. Bu, bəzi təhlükəsizlik modellərinin istədiyi pod kimliyini qoruyur və qarşı tərəfin qəbul etməli olduğu həm marşrutlaşdırma, həm də firewall əhatəsini genişləndirir.

Güzəşt oxunaqlığın əhatə ilə müqabilində olmasıdır. Çevirmə yerli tərəfin hər node üçün bir ünvan görməsinə səbəb olur, bu da icazə siyahısına salmağı asanlaşdırır və hansı podun nə göndərdiyini gizlədir. Çevirməmə pod ünvanını başdan-başa saxlayır, bu atribusiya üçün yaxşı, yeni aralığı öyrənməli olan yoldakı hər cihaz üçün pisdir. Heç bir variant Docker və ya CNI qüsuru deyil; hər ikisi əməliyyat hesabı olan marşrutlaşdırma qərarıdır. Komandanızın hesabını ödəyə biləcəyi variantı seçin və səbəbini yazın.

Doğrulayın və geri qaytarın

Eyni tutmanı yenidən aparın. Düzəlişinizdən sonra hələ də pod ünvanını çap edən node səviyyəli tutma qaydaların heç vaxt dəyişmədiyini göstərir, ConfigMap nə deyirsə də. Fakt kabldır; qalan hər şey çıxarışdır.

Sonra əks istiqaməti yoxlayın, çünki bu dəyişikliklərin yarısı yalnız çıxış üzrə doğrulanır. Cavabın sorğunu göndərən node-a və ya pod-a çatdığını və tətbiqin sadəcə SYN almadığını, tamamlandığını təsdiqləyin. Sorğunu cavabsız göstərən tutma bu tərəfdə masquerade problemi deyil, qarşı tərəfdə marşrutlaşdırma problemidir.

Geri qaytarma əvvəlki ConfigMap-dir, eyni şəkildə tətbiq olunur, agentin yenidən başladığı və qaydaların dəyişdiyi eyni təsdiqlə. Dəyişiklik qeydində bir məlum sorğu üçün əvvəlki və sonrakı mənbə ünvanını saxlayın, çünki dəyişikliyin dediyinizi etdiyini sübut edən məhz o tək sətirdir. GKE IP masquerade agent təlimatı standartları və ConfigMap sahələrini sənədləşdirir. Yayımdan sonra mənbə ünvanı dəyişməyibsə, agent o node-da işləmir və heç bir YAML redaktəsi bunu düzəltməyəcək.