VPN-klientens IP i Kubernetes: bevar den eller SNAT den?

Et sted mellem tunnelen og backenden overlever en klientadresse eller bliver erstattet, og begge udfald er forsvarlige. Valget tilhører den, der ejer den modtagende tjeneste, ikke den, der installerede CNI'et. Når autorisation pr. klient, kvoter eller revisionsspor betyder noget, skal adressen overleve hvert hop. Når fælles tilskrivning er acceptabel, fjerner kilde-NAT et routingproblem, som du ellers ville vedligeholde for evigt.

Hvor klientadressen egentlig forsvinder

En fjernklients pakke ankommer til VPN-poden med en indre kilde inden for tunnelområdet, f.eks. 10.90.0.42. Når poden videresender pakken mod en ClusterIP eller en pod-IP, kan tre forskellige mekanismer omskrive kilden. Nodens CNI-masquerade-regel dækker trafik, som poden sender uden for klyngens CIDR. kube-proxy's conntrack-post på destinationsnoden dækker selve Service-hoppet. En proxy, der afslutter forbindelsen, videresender slet ikke pakken, så den kilde, du til sidst ser, tilhører proxyen.

Hver af dem lever i et forskelligt lag, og derfor reparerer ét Service-felt næsten aldrig hele vejen.

externalTrafficPolicy på VPN'ens offentlige Service bestemmer kun, hvad der sker med den ydre forbindelse: Local beholder fjernadressen på den node, der modtog den, mens Cluster lader kube-proxy give pakken videre til en anden node og masquerade den der. Den indstilling styrer den listener, dine klienter kontakter. Den siger intet om den dekrypterede pakke, som din VPN-proces bagefter ruter ind i klyngen.

Tre betingelser, der afgør diskussionen

Jeg stiller de samme tre spørgsmål i samme rækkefølge, hver gang dette dukker op, fordi det første normalt afslutter diskussionen. Besvar dem for den konkrete arbejdsbyrde og ikke for klyngen som helhed. To klynger i samme virksomhed kan ende med forskellige svar og begge have ret.

Hvis backenden svarer ja til det første spørgsmål og nej til det andet, har du netværksarbejde at gøre i stedet for et manifest at redigere. Hvis den tredje række siger proxy, var adressen aldrig kommet til at overleve, og at foregive andet koster en uge med pakkefangst.

Hvad preserve-tilstand kræver af netværket

At bevare kilden betyder, at destinationsnoden skal sende trafik tilbage til 10.90.0.42 gennem en aktiv VPN-gateway. VPN-puljen er ikke et klynge-CIDR, så ingen CNI ruter den for dig som standard. Du tilføjer selv ruten og sikrer derefter, at det gateway-endepunkt, den peger på, overlever en omplanlægning.

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

Det næste hop er en pod-adresse, og pod-adresser flytter sig. Ret ruten mod en Service-VIP eller en node-adresse, der bliver på plads, eller accepter, at du jagter gatewayen efter hver udsmidning. Omvendt vejfiltrering er den anden fælde: streng tilstand dropper pakker, hvis returvej ikke matcher det interface, de ankom på, og det er præcis formen af et bevaret VPN-flow.

Løs validering er ofte forskellen mellem en fungerende returvej og svar, der forsvinder efter at have forladt backenden. Masquerade-regler på VPN-noden skal også udelukke tunnelområdet, ellers forlader den videresendte pakke med podens adresse, uanset hvilken rute du har bygget. Foretræk at udtrykke den udelukkelse i CNI'ets egen konfiguration i stedet for at redigere iptables manuelt, fordi agenten omskriver sine kæder ved genstart, og din håndskrevne regel overlever præcis indtil næste opgradering.

NetworkPolicy er adgangskontrol, ikke routing. At stramme en politik vil aldrig gendanne en adresse, som masquerade allerede har erstattet.

Hvad SNAT koster, og hvordan du skriver det ned

Kilde-NAT mod klyngen er det billigere design, og det er ikke en fejl. Backenden ser VPN-podens eller nodens adresse, logfiler stemmer overens, og der behøver ikke at findes nogen returrute. Det, du mister, er evnen til at skelne to klienter på netværkslaget, så kvoter, bandlysninger og revisionsspor må komme et andet sted fra.

Som regel er det andet sted applikationen: et sessionstoken, en signeret header eller en PROXY-protokol-linje skrevet af en proxy, du kontrollerer. De giver modtageren en identitet, som den kun kan stole på, når proxyen sidder i vejen, og headeren ikke kan sættes fra klientsiden. Vær eksplicit i runbooken om, hvilken der gælder, fordi den næste ingeniør vil antage, at adressen i loggen er klienten. Det er den ikke, og én hændelse er nok til at gøre den antagelse dyr.

Byttehandlen forbliver ærlig, så længe den er skrevet ned.

Kontroller, der skiller en fungerende vej fra en heldig

Test med en frisk forbindelse i stedet for en cachet, og test i begge retninger. Flere fejl ser kun periodiske ud, fordi nye flows tager den omskrevne vej.

Fang tuple'en tre steder under én godkendt anmodning: lige efter dekapsulering, på VPN-podens udgangsinterface og på backenden. Hvis kilden ændrer sig mellem den anden og tredje fangst, ligger årsagen nedstrøms for poden. Hvis den ændrer sig før den anden, oversætter poden selv.

Slet derefter VPN-poden, og gentag testen, mens den omplanlægges. En bevaret vej, der brækker ved udsmidning, er uafsluttet, og det samme er en NAT-regel fastgjort til en adresse, der ikke findes længere. Send til sidst én anmodning fra en kilde, som du forventer bliver afvist, og bekræft, at afvisningen kommer fra politik og ikke fra en manglende rute.