IP-ja e klientit VPN brenda Kubernetes: ta ruajmë apo ta SNAT-ojmë?

Diku mes tunelit dhe backend-it, adresa e klientit ose mbijeton ose zëvendësohet, dhe të dyja rezultatet janë të mbrojtshme. Zgjedhja i takon atij që zotëron shërbimin pritës, jo atij që instaloi CNI-në. Kur autorizimi për klient, kuotat ose regjistrat e auditimit kanë rëndësi, adresa duhet të mbijetojë çdo hop. Kur atribuimi i përbashkët është i pranueshëm, NAT-i i burimit heq një problem rrugëtimi që përndryshe do të mirëmbahej përgjithmonë.

Ku zhduket në të vërtetë adresa e klientit

Paketa e një klienti në distancë mbërrin në pod-in VPN me një burim të brendshëm brenda intervalit të tunelit, le të themi 10.90.0.42. Kur pod-i e përcjell atë paketë drejt një ClusterIP ose një IP pod-i, tre mekanizma të ndryshëm mund të rishkruajnë burimin. Rregulli i masquerade i CNI-së së nyjes mbulon trafikun që pod-i dërgon jashtë CIDR-it të klusterit. Hyrja conntrack e kube-proxy në nyjen e destinacionit mbulon vetë hopin e Service. Një proxy që përfundon lidhjen nuk e përcjell fare paketën, kështu që burimi që shihni në fund i përket proxy-t.

Secili jeton në një shtresë të ndryshme, prandaj një fushë e vetme e Service pothuajse kurrë nuk e rregullon të gjithë rrugën.

externalTrafficPolicy në Service-in publik të VPN-së vendos vetëm çfarë ndodh me lidhjen e jashtme: Local e mban adresën e largët në nyjen që e mori, ndërsa Cluster lejon kube-proxy ta kalojë paketën në një nyje tjetër dhe ta masquerade atje. Ai cilësim qeveris dëgjuesin që klientët tuaj thërrasin. Nuk thotë asgjë për paketën e dekriptuar që procesi juaj VPN e drejton në kluster më pas.

Tre kushte që e zgjidhin mosmarrëveshjen

I bëj të njëjtat tre pyetje në të njëjtën rend sa herë që kjo del, sepse e para zakonisht e mbyll diskutimin. Përgjigjuni për ngarkesën specifike të punës dhe jo për klusterin në tërësi. Dy klustera brenda një kompanie mund të arrijnë në përgjigje të ndryshme dhe të dyja të jenë të sakta.

Nëse backend-i përgjigjet po pyetjes së parë dhe jo të dytës, ju keni punë rrjeti për të bërë, jo një manifest për të redaktuar. Nëse rreshti i tretë thotë proxy, adresa nuk do të kishte mbijetuar kurrë, dhe të pretendohesh ndryshe kushton një javë kapjesh paketash.

Çfarë kërkon mënyra preserve nga rrjeta

Ruajtja e burimit do të thotë që nyja e destinacionit duhet t’i kthejë trafikun 10.90.0.42 përmes një gateway VPN aktiv. Pishina VPN nuk është CIDR klusteri, kështu që asnjë CNI nuk e rrugëton për ju si parazgjedhje. Ju e shtoni rrugën vetë, pastaj sigurohuni që pika fundore e gateway-t ku tregon ajo i mbijeton një riskedulimi.

ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2

Ai hop tjetër është një adresë pod-i, dhe adresat e pod-eve lëvizin. Drejtojeni rrugën në një VIP Service ose në një adresë nyje që qëndron në vend, ose pranoni që do të ndiqni gateway-t pas çdo dëbimi. Filtrimi i rrugës së kthimit është kurthi tjetër: modaliteti i rreptë i hedh poshtë paketat, rruga e kthimit të të cilave nuk përputhet me ndërfaqen ku mbërritën, që është pikërisht forma e një fluksi VPN të ruajtur.

Validimi i lirshëm është shpesh dallimi midis një rruge kthimi që funksionon dhe përgjigjeve që zhduken pasi largohen nga backend-i. Rregullat e masquerade në nyjen VPN gjithashtu duhet të përjashtojnë intervalin e tunelit, përndryshe paketa e përcjellë largohet me adresën e pod-it, pavarësisht se çfarë rruge keni ndërtuar. Preferoni ta shprehni atë përjashtim në konfigurimin e vetë CNI-së në vend që të redaktoni iptables me dorë, sepse agjenti i rishkruan zinxhirët e tij në rinisje dhe rregulli juaj i shkruar me dorë mbijeton saktësisht deri në përditësimin tjetër.

NetworkPolicy është kontroll aksesi, jo rrugëtim. Shtrëngimi i një politikë nuk do të rikthejë kurrë një adresë që masquerade e ka zëvendësuar tashmë.

Sa kushton SNAT, dhe si ta shkruajmë atë

NAT-i i burimit drejt klusterit është dizajni më i lirë, dhe nuk është gabim. Backend-i sheh adresën e pod-it ose të nyjes VPN, regjistrat pajtohen me njëri-tjetrin, dhe nuk duhet të ekzistojë asnjë rrugë kthimi. Ajo që humbisni është aftësia për të dalluar dy klientë në nivelin e rrjetit, kështu që kuotat, ndalimet dhe gjurmët e auditimit duhet të vijnë nga diku tjetër.

Zakonisht ai diku tjetër është aplikacioni: një shenjë sesioni, një header i nënshkruar, ose një rresht protokolli PROXY i shkruar nga një proxy që ju kontrolloni. Këto i japin marrësit një identitet që mund ta besojë vetëm kur proxy-t ndodhet në rrugë dhe header-i nuk mund të vendoset nga ana e klientit. Jini të qartë në runbook se cili prej tyre zbatohet, sepse inxhinieri i radhës do të supozojë se adresa në regjistër është klienti. Nuk është, dhe një incident mjafton për ta bërë atë supozim të kushtueshëm.

Shkëmbimi mbetet i ndershëm për sa kohë shkruhet.

Kontrolle që ndajnë një rrugë që funksionon nga një e fatit

Testoni me një lidhje të re dhe jo me një të ruajtur në cache, dhe testoni në të dy drejtimet. Disa dështime duken të ndërprera vetëm sepse flukset e reja marrin rrugën e rishkruar.

Kapni tuple-in në tre pika gjatë një kërkese të autorizuar: menjëherë pas dekapsulimit, në ndërfaqen e daljes së pod-it VPN, dhe në backend. Nëse burimi ndryshon midis kapjes së dytë dhe të tretë, shkaku ndodhet në rrjedhën e poshtme të pod-it. Nëse ndryshon përpara të dytës, vetë pod-i po përkthehet.

Pastaj fshini pod-in VPN dhe përsëritni testin ndërsa ai riskedulohet. Një rrugë e ruajtur që prishet në dëbim është e papërfunduar, dhe po ashtu edhe një rregull NAT i fiksuar në një adresë që nuk ekziston më. Më në fund, dërgoni një kërkesë nga një burim që prisni të refuzohet dhe konfirmoni se refuzimi vjen nga politika dhe jo nga një rrugë që mungon.