VPN-Client-IP a Kubernetes: behalen oder SNAT?

Iergendwou tëscht dem Tunnel an dem Backend iwwerlieft eng Client-Adress oder gëtt ersat, an déi zwou Resultater sinn defendéierbar. D'Wiel gehéiert dem Besëtzer vum empfangende Service, net deem, deen d'CNI installéiert huet. Wann d'Autorisatioun pro Client, Quoten oder Auditopzeechnungen zielen, muss d'Adress all Hop iwwerstoen. Wann déi gedeelt Zouschreiwung akzeptabel ass, entfernt Source-NAT e Routingproblem, deen s du soss fir ëmmer ënnerhalen géifs.

Wou d'Client-Adress wierklech verschwënnt

De Pak vun engem wäitem Client erreecht de VPN-Pod mat enger interner Quell bannent dem Tunnelberäich, souzesoen 10.90.0.42. Wann de Pod dëse Pak Richtung ClusterIP oder Pod-IP weiderleedt, kënnen dräi verschidde Mechanismen d'Quell ëmsschreiwen. D'Masquerade-Regel vun der CNI um Node deckt Traffic of, deen de Pod baussent dem Cluster-CIDR schéckt. Den conntrack-Andrag vu kube-proxy um Zilnode deckt de Service-Hop selwer of. E Proxy, dee Verbindung ophält, leet de Pak guer net weider, also gehéiert d'Quell, déi s du schlussendlech gesäis, zum Proxy.

Jiddereen lieft an enger anerer Schicht, dofir reparéiert een eenzegt Service-Feld bal ni de ganze Wee.

externalTrafficPolicy um ëffentleche Service vum VPN entscheet just, wat mat der baussenzeger Verbindung geschitt: Local hält d'wäit Adress um Node, deen se kritt huet, während Cluster kube-proxy erlaabt, de Pak un en aneren Node ze ginn an en do ze masqueraden. Dës Astellung regéiert de Listener, mat deem deng Cliente sech verbannen. Si seet näischt iwwer de entschlësselte Pak, deen däi VPN-Prozess duerno an de Cluster leet.

Dräi Konditiounen, déi d'Debatt entscheeden

Ech stelle fiwwer déi selwecht dräi Froen an der selwechter Reiefolleg, well déi éischt d'Diskussioun meeschtens ophält. Äntwert se fir déi konkreet Aarbechtslaascht an net fir de ganze Cluster. Zwee Cluster an enger Firma kënnen op verschidden Äntwerten kommen an déi zwou kënnen richteg sinn.

Wann de Backend jo op déi éischt Fro an nee op déi zweet äntwert, hues du Network-Aarbecht ze maachen, net e Manifest z'änneren. Wann déi drëtt Zeil Proxy seet, hätt d'Adress ni iwwerlieft, a behaapte sech anescht kascht eng Woch Pakkfang.

Wat de Preserve-Modus vum Netzwierk verlaangt

D'Quell behalen heescht, datt den Zilnode den Traffic iwwer eng aktiv VPN-Gateway op 10.90.0.42 zréckschécke muss. De VPN-Pool ass keen Cluster-CIDR, dofir routt keen CNI en fir dech standardméisseg. Du setz d'Route selwer derbäi an suergs duerno, datt de Gateway-Endpunkt, op deen se weist, eng Ëmplanung iwwerlieft.

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

Den nächsten Hop ass eng Pod-Adress, an d'Pod-Adresse beweege sech. Richt d'Route op eng Service-VIP oder eng Node-Adress, déi stoe bleift, oder akzeptéier, datt s du no all Verdreiwen der Gateway nogees. Reverse-Path-Filterung ass déi aner Fal: de stramme Modus verwëft Paken, déi en Retourwee hunn, deen net mat der Interface iwwerenee kënnt, op där se ukomm sinn, an dat ass genee d'Form vun engem behaltene VPN-Flow.

Lues Validatioun ass dacks den Ënnerscheed tëscht engem fonctionéierende Retourwee an Äntwerten, déi verschwanne nodeem se de Backend verlooss hunn. D'Masquerade-Regele um VPN-Node mussen och den Tunnelberäich ausgrenzen, soss geet de weidergeleet Pak mat der Adress vum Pod eraus, egal wat fir eng Route s du gebaut hues. Dréck déi Ausgränzung léiwer an der Konfiguratioun vun der CNI selwer aus wéi iptables vun Hand ze änneren, well den Agent seng Ketten beim Neistart ëmmschreift an deng handgeschriwwen Regel genee bis zum nächsten Upgrade lieft.

NetworkPolicy ass Access-Control, net Routing. Eng Politik ze verschäerfen hielt ni eng Adress zréck, déi de Masquerade schonn ersat huet.

Wat SNAT kascht, a wéi een et opschreift

Source-NAT a Richtung Cluster ass de bëllegen Design, an et ass kee Feeler. De Backend gesäit d'Adress vum VPN-Pod oder Node, d'Logs stëmmen iwwerenee, an et muss keng Retourroute ginn. Wat s du verléiers, ass d'Fäegkeet, zwee Clienten op der Netzwierkschicht z'ënnerscheeden, dofir mussen Quoten, Spären an Auditspueren vun aneschtwou kommen.

Meeschtens ass dat aneschtwou d'Applikatioun: e Sessiounstoken, en ënnerschriwwene Header oder eng PROXY-Protokollzeil, déi e Proxy schreift, deen s du kontrolléiers. Dës ginn dem Empfänger eng Identitéit, déi en nëmme ka vertrauen, wann de Proxy um Wee ass an den Header net vun der Clientsäit ka gesat ginn. Sidd am Runbook explizit, wéi eng gëllt, well den nächsten Ingenieur unhëlt, datt d'Adress am Log de Client ass. Et ass se net, an een Tëschefall duer, fir déi Unhuelung deier ze maachen.

Den Tausch bleift éierlech, soulaang en opgeschriwwen ass.

Kontrollen, déi ee fonctionéierende Wee vun engem glécklechen ënnerscheeden

Test mat enger fräscher Verbindung amplaz enger gecachter, a test a béid Richtungen. Verschidde Feeler schéngen nëmme periodesch, well nei Flëss de ëmmschriwwene Wee huele.

Fänk den Tuple op dräi Punkten während enger autoriséierter Ufro: direkt no der Decapsulation, op der Egress-Interface vum VPN-Pod an um Backend. Wann d'Quell tëscht der zweeter an drëtter Fang änert, läit d'Ursaach ënnerhalb vum Pod. Wann se sech virun der zweeter änert, iwwersetzt de Pod selwer.

Läsch duerno de VPN-Pod a widderhuel den Test, während en nei geplangt gëtt. En behaltene Wee, deen beim Verdreiwen brécht, ass onfäerdeg, an esou ass et och eng NAT-Regel, déi un eng Adress gebonnen ass, déi et net méi ginn. Schéck schlussendlech eng Ufro vun enger Quell, déi s du erwaarts, datt se refuséiert gëtt, a bestäteg, datt de Refus vun der Politik kënnt an net vun enger feelender Route.