VPN-klientens IP i Kubernetes: bevara det eller SNAT:a det?

Någonstans mellan tunneln och backend överlever en klientadress eller blir utbytt, och båda utfallen är försvarbara. Valet tillhör den som äger den mottagande tjänsten, inte den som installerade CNI:n. När auktorisering per klient, kvoter eller revisionsspår spelar roll måste adressen överleva varje hopp. När delad tillskrivning är acceptabel tar käll-NAT bort ett routingproblem som du annars skulle underhålla för alltid.

Var klientadressen faktiskt försvinner

En fjärrclients paket anländer till VPN-poden med en inre källa inom tunnelintervallet, säg 10.90.0.42. När poden vidarebefordrar paketet mot en ClusterIP eller en pod-IP kan tre olika mekanismer skriva om källan. Nodens CNI-masquerade-regel täcker trafik som poden skickar utanför klustrets CIDR. kube-proxys conntrack-post på destinationsnoden täcker själva Service-hoppet. En proxy som avslutar anslutningen vidarebefordrar inte paketet alls, så den källa du till slut ser tillhör proxyn.

Var och en lever i ett annat lager, och därför reparerar ett enda Service-fält nästan aldrig hela vägen.

externalTrafficPolicy på VPN:ens publika Service avgör bara vad som händer med den yttre anslutningen: Local behåller fjärradressen på noden som tog emot den, medan Cluster låter kube-proxy lämna paketet till en annan nod och masquerade det där. Den inställningen styr den lyssnare dina klienter ringer. Den säger ingenting om det dekrypterade paket som din VPN-process sedan routar in i klustret.

Tre villkor som avgör diskussionen

Jag ställer samma tre frågor i samma ordning varje gång detta dyker upp, eftersom den första oftast avslutar diskussionen. Besvara dem för den specifika arbetsbelastningen och inte för klustret som helhet. Två kluster inom ett företag kan landa i olika svar och båda ha rätt.

Om backend svarar ja på den första frågan och nej på den andra har du nätarbete att göra i stället för ett manifest att redigera. Om den tredje raden säger proxy skulle adressen aldrig ha överlevt, och att låtsas annat kostar en vecka av paketinsamling.

Vad preserveläget kräver av nätverket

Att bevara källan innebär att destinationsnoden måste skicka tillbaka trafik till 10.90.0.42 genom en aktiv VPN-gateway. VPN-poolen är inte ett kluster-CIDR, så ingen CNI routar den åt dig som standard. Du lägger till rutten själv och ser sedan till att gateway-endpointen den pekar på överlever en omplanering.

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

Nästa hopp är en pod-adress, och pod-adresser flyttar sig. Rikta rutten mot en Service-VIP eller en nodadress som står kvar, eller acceptera att du jagar gatewayen efter varje eviction. Omvänd vägfiltrering är den andra fällan: strikt läge släpper paket vars returväg inte matchar gränssnittet de anlände på, vilket är exakt formen av ett bevarat VPN-flöde.

Lös validering är ofta skillnaden mellan en fungerande returväg och svar som försvinner efter att ha lämnat backend. Masquerade-regler på VPN-noden måste också undanta tunnelintervallet, annars lämnar det vidarebefordrade paketet med podens adress, oavsett vilken rutt du byggt. Uttryck hellre det undantaget i CNI:ns egen konfiguration i stället för att redigera iptables för hand, eftersom agenten skriver om sina kedjor vid omstart och din handskrivna regel överlever exakt till nästa uppgradering.

NetworkPolicy är åtkomstkontroll, inte routing. Att skärpa en policy kommer aldrig att återställa en adress som masquerade redan har ersatt.

Vad SNAT kostar, och hur du skriver ner det

Käll-NAT mot klustret är den billigare designen, och det är inte ett misstag. Backend ser VPN-podens eller nodens adress, loggarna stämmer överens och ingen returrutt behöver finnas. Det du förlorar är förmågan att skilja två klienter åt på nätverkslagret, så kvoter, bannlysningar och revisionsspår måste komma någon annanstans ifrån.

Oftast är det någon annanstans applikationen: en sessionstoken, en signerad header eller en PROXY-protokollrad skriven av en proxy du kontrollerar. Dessa ger mottagaren en identitet som den bara kan lita på när proxyn sitter i vägen och headern inte kan sättas från klientsidan. Var tydlig i runbooken om vilken som gäller, för nästa ingenjör kommer att anta att adressen i loggen är klienten. Det är den inte, och en incident räcker för att göra det antagandet dyrt.

Byter handlar förblir ärlig så länge den är nedskriven.

Kontroller som skiljer en fungerande väg från en turlig

Testa med en färsk anslutning i stället för en cachad, och testa i båda riktningarna. Flera fel verkar bara intermittenta eftersom nya flöden tar den omskrivna vägen.

Fånga tupeln på tre punkter under en auktoriserad begäran: direkt efter dekapsulering, på VPN-podens egressgränssnitt och på backend. Om källan ändras mellan den andra och tredje fångsten ligger orsaken nedströms poden. Om den ändras före den andra översätter poden själv.

Ta sedan bort VPN-poden och upprepa testet medan den omplaneras. En bevarad väg som bryts vid eviction är ofullständig, och detsamma gäller en NAT-regel knuten till en adress som inte längre finns. Skicka till sist en begäran från en källa som du förväntar dig ska nekas och bekräfta att avslaget kommer från policy och inte från en saknad rutt.