Kubernetes daxilində VPN müştəri IP-si: saxlamalı, yoxsa SNAT etməli?
Kubernetes daxilində real VPN müştəri ünvanını saxlamaqla mənbə NAT-ı arasında üç şərtlə seçim edin, sonra qayıdış yolunu və pod dəyişməsini yoxlayın.
Tunel ilə backend arasında hansısa yerdə müştəri ünvanı ya yaşayır, ya da dəyişdirilir və hər iki nəticə müdafiə oluna bilər. Seçim CNI-ni quraşdıran şəxsə deyil, qəbul edən xidmətin sahibinə aiddir. Hər müştəri üzrə avtorizasiya, kvotalar və ya audit qeydləri vacib olduqda, ünvan hər hopdan keçməlidir. Ortaq aidiyyət məqbul olduqda, mənbə NAT-ı əbədi saxlamaq məcburiyyətində qalacağınız bir marşrutlaşdırma problemini aradan qaldırır.
Müştəri ünvanı əslində harada yox olur
Uzaq müştərinin paketi VPN poduna tunel aralığı daxilində daxili mənbə ilə, deyək ki 10.90.0.42, gəlir. Pod həmin paketi ClusterIP və ya pod IP-sinə yönəltdikdə, mənbəyi üç fərqli mexanizm yenidən yaza bilər. Düyünün CNI masquerade qaydası podun klaster CIDR-indən kənara göndərdiyi trafiki əhatə edir. Təyinat düyünündəki kube-proxy conntrack girişi Service hopunu özü əhatə edir. Bağlantını sonlandıran proxy paketi ümumiyyətlə yönəltmir, buna görə sonda gördüyünüz mənbə proxy-yə aiddir.
Hər biri fərqli qatda yaşayır, buna görə bir Service sahəsi demək olar ki, heç vaxt bütün yolu bərpa etmir.
VPN-in publik Service-indəki externalTrafficPolicy yalnız xarici bağlantıya nə olacağını müəyyən edir: Local uzaq ünvanı onu qəbul edən düyündə saxlayır, Cluster isə kube-proxy-yə paketi başqa düyünə ötürməyə və orada masquerade etməyə imkan verir. Bu parametr müştərilərinizin yaxınlaşdığı dinləyicini idarə edir. Sonradan VPN prosesinizin klasterə yönəltdiyi deşifrə edilmiş paket barədə heç nə demir.
Mübahisəni həll edən üç şərt
Bu mövzu hər qalxdıqda eyni üç sualı eyni ardıcıllıqla verirəm, çünki birincisi adətən müzakirəni bitirir. Onlara bütün klaster üçün deyil, konkret iş yükü üçün cavab verin. Bir şirkət daxilində iki klaster fərqli cavablara gələ bilər və hər ikisi doğru ola bilər.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
Backend birinci suala bəli, ikinciyə xeyr cavabı verirsə, redaktə ediləcək manifest deyil, görüləcək şəbəkə işiniz var. Üçüncü sətir proxy deyirsə, ünvan heç vaxt yaşamayacaqdı və əksini iddia etmək bir həftə paket tutmağa başa gəlir.
Saxlama rejiminin şəbəkədən tələb etdikləri
Mənbəyi saxlamaq o deməkdir ki, təyinat düyünü trafiki aktiv VPN şlüzü vasitəsilə 10.90.0.42-yə qaytarmalıdır. VPN hovuzu klaster CIDR-i deyil, buna görə heç bir CNI onu sizin üçün defolt olaraq marşrutlaşdırmır. Marşrutu özünüz əlavə edir, sonra onun göstərdiyi şlüz son nöqtəsinin yenidən planlaşdırmaya dözdüyünə əmin olursunuz.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2Həmin növbəti hop pod ünvanıdır və pod ünvanları yerini dəyişir. Marşrutu yerində qalan Service VIP-inə və ya düyün ünvanına yönəldin, ya da hər çıxarışdan sonra şlüzü təqib edəcəyinizi qəbul edin. Əks yol filtrləmə digər tələdir: sərt rejim qayıdış yolu gəldiyi interfeysə uyğun gəlməyən paketləri atır, bu da saxlanmış VPN axınının dəqiq formasıdır.
Sərbəst validasiya çox vaxt işləyən qayıdış yolu ilə backend-dən çıxdıqdan sonra yoxa çıxan cavablar arasındakı fərqdir. VPN düyünündəki masquerade qaydaları da tunel aralığını istisna etməlidir, əks halda yönləndirilmiş paket hansı marşrutu qurduğunuzdan asılı olmayaraq podun ünvanı ilə çıxır. Bu istisnanı iptables-ı əl ilə redaktə etmək əvəzinə CNI-nin öz konfiqurasiyasında ifadə etməyi üstün tutun, çünki agent yenidən başladıqda zəncirlərini yenidən yazır və əl ilə yazdığınız qayda məhz növbəti yenilənməyə qədər yaşayır.
NetworkPolicy giriş nəzarətidir, marşrutlaşdırma deyil. Siyasəti sərtləşdirmək masquerade-in artıq əvəz etdiyi ünvanı heç vaxt bərpa etməyəcək.
SNAT nəyə başa gəlir və onu necə yazmaq lazımdır
Klasterə doğru mənbə NAT-ı daha ucuz dizayndır və bu səhv deyil. Backend VPN podunun və ya düyünün ünvanını görür, qeydlər bir-biri ilə uyğunlaşır və heç bir qayıdış marşrutunun olması tələb olunmur. İtirdiyiniz şey iki müştərini şəbəkə qatında ayırd etmək qabiliyyətidir, buna görə kvotalar, qadağalar və audit izləri başqa yerdən gəlməlidir.
Adətən o başqa yer tətbiqdir: sessiya tokeni, imzalanmış başlıq və ya nəzarət etdiyiniz proxy tərəfindən yazılan PROXY protokol sətri. Bunlar qəbul edənə yalnız proxy yolda olduqda və başlıq müştəri tərəfindən təyin edilə bilmədikdə etibarlı hesab edə biləcəyi kimlik verir. Runbook-da hansının tətbiq olunduğunu açıq yazın, çünki növbəti mühəndis qeyddəki ünvanı müştəri hesab edəcək. Belə deyil və bir hadisə bu fərziyyəni bahalı etməyə kifayət edir.
Mübadilə yazıldığı müddətcə dürüst qalır.
İşləyən yolu şanslı yoldan ayıran yoxlamalar
Keşlənmiş əlaqə ilə deyil, təzə əlaqə ilə sınaqdan keçirin və hər iki istiqamətdə yoxlayın. Bir neçə nasazlıq yalnız yeni axınlar yenidən yazılmış yolu tutduğu üçün fasiləli görünür.
Bir icazəli sorğu zamanı tuple-ı üç nöqtədə tutun: dekapsulyasiyadan dərhal sonra, VPN podunun çıxış interfeysində və backend-də. Mənbə ikinci və üçüncü tutma arasında dəyişirsə, səbəb podun aşağı axınındadır. İkincidən əvvəl dəyişirsə, pod özü tərcümə edir.
Sonra VPN podunu silin və yenidən planlaşdırılarkən testi təkrarlayın. Çıxarışda pozulan saxlanmış yol yarımçıqdır, artıq mövcud olmayan ünvana bağlanmış NAT qaydası da. Nəhayət, rədd edilməsini gözlədiyiniz mənbədən bir sorğu göndərin və imtinanın çatışmayan marşrutdan deyil, siyasətdən gəldiyini təsdiqləyin.