IP-en til VPN-klienten i Kubernetes: bevare han eller SNAT?

Ein stad mellom tunnelen og backend overlever ei klientadresse eller blir erstatta, og begge utfalla er forsvarlege. Valet høyrer til den som eig den mottakande tenesta, ikkje den som installerte CNI-et. Når autorisasjon per klient, kvotar eller revisjonsspor betyr noko, må adressa overleve kvar hopp. Når delt tilskriving er akseptabel, fjernar kjelde-NAT eit ruteproblem du elles ville vedlikehalde for alltid.

Kvar klientadressa faktisk forsvinn

Pakken til ein ekstern klient kjem til VPN-poden med ei indre kjelde innanfor tunnelområdet, sei 10.90.0.42. Når poden sender pakken vidare mot ein ClusterIP eller ein pod-IP, kan tre ulike mekanismar skrive om kjelda. CNI-masquerade-regelen på noden dekkjer trafikk poden sender utanfor CIDR-en til klynga. conntrack-oppføringa til kube-proxy på destinasjonsnoden dekkjer sjølve Service-hoppet. Ein proxy som avsluttar sambandet, sender ikkje pakken vidare i det heile, så kjelda du til slutt ser, høyrer til proxyen.

Kvar av dei lever i eit anna lag, og difor reparerer eitt Service-felt nesten aldri heile vegen.

externalTrafficPolicy på den offentlege Service-en til VPN-en avgjer berre kva som skjer med den ytre sambandet: Local held fjernadressa på noden som tok imot ho, medan Cluster lèt kube-proxy gje pakken vidare til ein annan node og masquerade han der. Den innstillinga styrer listeneren klientane dine kontaktar. Ho seier ingenting om den dekrypterte pakken som VPN-prosessen din deretter rutar inn i klynga.

Tre vilkår som avgjer diskusjonen

Eg stiller dei same tre spørsmåla i same rekkjefølgje kvar gong dette dukkar opp, fordi det første vanlegvis avsluttar diskusjonen. Svar på dei for den konkrete arbeidsbelastninga og ikkje for klynga som heilskap. To klynger i same selskap kan enda med ulike svar og begge ha rett.

Viss backend svarar ja på det første spørsmålet og nei på det andre, har du nettverksarbeid å gjere i staden for eit manifest å redigere. Viss den tredje rada seier proxy, ville adressa aldri ha overlevd, og å late som noko anna kostar ei veke med pakkefangst.

Kva preserve-modus krev av nettverket

Å bevare kjelda betyr at destinasjonsnoden må sende trafikk tilbake til 10.90.0.42 gjennom ein aktiv VPN-gateway. VPN-poolen er ikkje ein klynge-CIDR, så ingen CNI rutar han for deg som standard. Du legg til ruta sjølv og sikrar deretter at gateway-endepunktet ho peikar på overlever ei omplanlegging.

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 neste hoppet er ei pod-adresse, og pod-adresser flyttar seg. Rett ruta mot ein Service-VIP eller ei nodeadresse som blir ståande, eller godta at du jagar gatewayen etter kvar utkasting. Omvendt vegfiltrering er den andre fella: streng modus slepp pakkar kva returveg ikkje samsvarar med grensesnittet dei kom inn på, og det er nøyaktig forma på ein bevart VPN-flyt.

Laus validering er ofte skilnaden mellom ein fungerande returveg og svar som forsvinn etter å ha forlate backend. Masquerade-reglar på VPN-noden må også utelukke tunnelområdet, elles forlèt den videresende pakken med adressa til poden, uansett kva rute du har bygd. Føretrekk å uttrykke den utelukkinga i konfigurasjonen til CNI-et sjølv i staden for å redigere iptables for hand, fordi agenten skriv om kjedene sine ved omstart, og den handskrivne regelen din overlever nøyaktig til neste oppgradering.

NetworkPolicy er tilgangskontroll, ikkje ruting. Å stramme inn ein policy vil aldri gjenopprette ei adresse som masquerade allereie har erstatta.

Kva SNAT kostar, og korleis du skriv det ned

Kjelde-NAT mot klynga er det billegare designet, og det er ikkje ein feil. Backend ser adressa til VPN-poden eller noden, loggane stemmer overeins, og ingen returrute treng å finnast. Det du mistar, er evna til å skilje to klientar på nettverkslaget, så kvotar, bans og revisjonsspor må kome frå ein annan stad.

Vanlegvis er den andre staden applikasjonen: eit sesjonstoken, ein signert header eller ei PROXY-protokollinje skriven av ein proxy du kontrollerer. Desse gjev mottakaren ein identitet han berre kan stole på når proxyen sit i vegen og headeren ikkje kan setjast frå klientsida. Ver eksplisitt i runbooken om kva som gjeld, fordi den neste ingeniøren vil anta at adressa i loggen er klienten. Det er ho ikkje, og éi hending er nok til å gjere den antakinga dyr.

Byttet blir ærleg så lenge det er skrive ned.

Kontrollar som skil ein fungerande veg frå ein heldig

Test med eit ferskt samband i staden for eit buftra, og test i begge retningar. Fleire feil verkar berre periodiske fordi nye flytar tar den omskrivne vegen.

Fang tuple-en på tre punkt under éin autorisert førespurnad: rett etter dekapsulering, på utgangsgrensesnittet til VPN-poden og på backend. Viss kjelda endrar seg mellom den andre og tredje fangsten, ligg årsaka nedstraums for poden. Viss ho endrar seg før den andre, omset poden sjølv.

Slett deretter VPN-poden og gjer testen om att medan han blir omplanlagd. Ein bevart veg som bryt ved utkasting, er uferdig, og det same er ein NAT-regel fest til ei adresse som ikkje finst lenger. Send til slutt éin førespurnad frå ei kjelde du ventar blir avvist, og stadfest at avvisinga kjem frå policy og ikkje frå ei manglande rute.