VPN-client-IP in Kubernetes: bewaren of SNAT'en?

Ergens tussen de tunnel en de backend overleeft een clientadres of wordt het vervangen, en beide uitkomsten zijn verdedigbaar. De keuze is aan de eigenaar van de ontvangende dienst, niet aan degene die de CNI heeft geïnstalleerd. Wanneer autorisatie per client, quota of auditregistraties ertoe doen, moet het adres elke hop overleven. Wanneer gedeelde toerekening acceptabel is, verwijdert source-NAT een routeringsprobleem dat je anders voor altijd zou onderhouden.

Waar het clientadres echt verdwijnt

Het pakket van een externe client komt aan bij de VPN-pod met een interne bron binnen het tunnelbereik, zeg 10.90.0.42. Wanneer de pod dat pakket doorstuurt naar een ClusterIP of een pod-IP, kunnen drie verschillende mechanismen de bron herschrijven. De masquerade-regel van de CNI op de node dekt verkeer dat de pod buiten de cluster-CIDR verstuurt. De conntrack-regel van kube-proxy op de doelnode dekt de Service-hop zelf. Een proxy die de verbinding beëindigt, stuurt het pakket helemaal niet door, dus de bron die je uiteindelijk ziet, is van de proxy.

Elk leeft in een andere laag, en daarom herstelt één Service-veld bijna nooit het hele pad.

externalTrafficPolicy op de publieke Service van de VPN bepaalt alleen wat er met de buitenste verbinding gebeurt: Local houdt het externe adres op de node die het heeft ontvangen, terwijl Cluster kube-proxy toestaat het pakket aan een andere node te geven en het daar te masqueraden. Die instelling beheert de listener waarop je clients inbellen. Ze zegt niets over het ontsleutelde pakket dat je VPN-proces daarna de cluster in routeert.

Drie voorwaarden die de discussie beslechten

Ik stel dezelfde drie vragen in dezelfde volgorde telkens als dit opkomt, omdat de eerste de discussie meestal beëindigt. Beantwoord ze voor de specifieke workload en niet voor de cluster als geheel. Twee clusters binnen één bedrijf kunnen op verschillende antwoorden uitkomen en beide gelijk hebben.

Als de backend ja antwoordt op de eerste vraag en nee op de tweede, heb je netwerkwerk te doen in plaats van een manifest te bewerken. Als de derde rij proxy zegt, zou het adres nooit hebben overleefd, en doen alsof dat niet zo is kost een week packet captures.

Wat preserve-modus van het netwerk vraagt

De bron bewaren betekent dat de doelnode verkeer naar 10.90.0.42 moet terugsturen via een actieve VPN-gateway. De VPN-pool is geen cluster-CIDR, dus geen enkele CNI routeert die standaard voor je. Je voegt de route zelf toe en zorgt er dan voor dat het gateway-endpoint waar die naartoe wijst een herplanning overleeft.

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

Die volgende hop is een pod-adres, en pod-adressen verplaatsen zich. Richt de route op een Service-VIP of een node-adres dat blijft staan, of accepteer dat je na elke evictie de gateway achterna zit. Reverse path filtering is de andere valkuil: strikte modus laat pakketten vallen waarvan het retourpad niet overeenkomt met de interface waarop ze aankwamen, en dat is precies de vorm van een bewaard VPN-flow.

Losse validatie is vaak het verschil tussen een werkend retourpad en antwoorden die verdwijnen nadat ze de backend hebben verlaten. Masquerade-regels op de VPN-node moeten ook het tunnelbereik uitsluiten, anders verlaat het doorgestuurde pakket met het adres van de pod, ongeacht welke route je hebt gebouwd. Druk die uitsluiting liever uit in de configuratie van de CNI zelf in plaats van iptables met de hand te bewerken, want de agent herschrijft zijn chains bij een herstart en je handgeschreven regel overleeft precies tot de volgende upgrade.

NetworkPolicy is toegangscontrole, geen routering. Een beleid aanscherpen zal nooit een adres herstellen dat masquerade al heeft vervangen.

Wat SNAT kost, en hoe je het opschrijft

Source-NAT naar de cluster is het goedkopere ontwerp, en het is geen fout. De backend ziet het adres van de VPN-pod of node, logs komen met elkaar overeen, en er hoeft geen retourroute te bestaan. Wat je verliest is het vermogen om twee clients op netwerkniveau te onderscheiden, dus quota, bans en audittrails moeten ergens anders vandaan komen.

Meestal is dat ergens anders de applicatie: een sessietoken, een ondertekende header of een PROXY-protocolregel die door een proxy wordt geschreven die je beheert. Die geven de ontvanger een identiteit die hij alleen kan vertrouwen als de proxy in het pad zit en de header niet vanaf de clientzijde kan worden gezet. Wees expliciet in de runbook welke geldt, want de volgende engineer gaat ervan uit dat het adres in de log de client is. Dat is het niet, en één incident is genoeg om die aanname duur te maken.

De ruil blijft eerlijk zolang hij opgeschreven staat.

Controles die een werkend pad van een gelukkig pad scheiden

Test met een verse verbinding in plaats van een gecachte, en test in beide richtingen. Verschillende fouten lijken alleen intermittent omdat nieuwe flows het herschreven pad nemen.

Leg de tuple op drie punten vast tijdens één geautoriseerd verzoek: direct na decapsulatie, op de egress-interface van de VPN-pod en op de backend. Als de bron verandert tussen de tweede en derde capture, zit de oorzaak stroomafwaarts van de pod. Als ze verandert vóór de tweede, vertaalt de pod zelf.

Verwijder dan de VPN-pod en herhaal de test terwijl die opnieuw wordt gepland. Een bewaard pad dat breekt bij een evictie is onvoltooid, en dat geldt ook voor een NAT-regel die vastzit aan een adres dat niet meer bestaat. Stuur ten slotte één verzoek vanaf een bron waarvan je verwacht dat die wordt geweigerd, en bevestig dat de weigering uit beleid komt en niet uit een ontbrekende route.