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

Et sted mellom tunnelen og backend overlever en klientadresse eller blir erstattet, og begge utfallene er forsvarlige. Valget tilhører den som eier den mottakende tjenesten, ikke den som installerte CNI-et. Når autorisasjon per klient, kvoter eller revisjonsspor betyr noe, må adressen overleve hvert hopp. Når delt tilskrivning er akseptabelt, fjerner kilde-NAT et rutingsproblem du ellers ville vedlikeholdt for alltid.

Hvor klientadressen faktisk forsvinner

En ekstern klients pakke ankommer VPN-poden med en indre kilde innenfor tunnelområdet, si 10.90.0.42. Når poden videresender pakken mot en ClusterIP eller en pod-IP, kan tre forskjellige mekanismer skrive om kilden. Nodens CNI-masquerade-regel dekker trafikk poden sender utenfor klyngens CIDR. kube-proxys conntrack-oppføring på destinasjonsnoden dekker selve Service-hoppet. En proxy som avslutter forbindelsen, videresender ikke pakken i det hele tatt, så kilden du til slutt ser, tilhører proxyen.

Hver av dem lever i et annet lag, og derfor reparerer ett Service-felt nesten aldri hele veien.

externalTrafficPolicy på VPN-ens offentlige Service avgjør bare hva som skjer med den ytre forbindelsen: Local beholder fjernadressen på noden som tok imot den, mens Cluster lar kube-proxy gi pakken videre til en annen node og masquerade den der. Den innstillingen styrer listeneren klientene dine kontakter. Den sier ingenting om den dekrypterte pakken som VPN-prosessen din deretter ruter inn i klyngen.

Tre betingelser som avgjør diskusjonen

Jeg stiller de samme tre spørsmålene i samme rekkefølge hver gang dette dukker opp, fordi det første vanligvis avslutter diskusjonen. Svar på dem for den konkrete arbeidsbelastningen og ikke for klyngen som helhet. To klynger i samme selskap kan ende med ulike svar og begge ha rett.

Hvis backend svarer ja på det første spørsmålet og nei på det andre, har du nettverksarbeid å gjøre i stedet for et manifest å redigere. Hvis den tredje raden sier proxy, ville adressen aldri overlevd, og å late som noe annet koster en uke med pakkefangst.

Hva preserve-modus krever av nettverket

Å bevare kilden betyr at destinasjonsnoden må sende trafikk tilbake til 10.90.0.42 gjennom en aktiv VPN-gateway. VPN-poolen er ikke en klynge-CIDR, så ingen CNI ruter den for deg som standard. Du legger til ruten selv og sikrer deretter at gateway-endepunktet den peker på overlever en 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 en pod-adresse, og pod-adresser flytter seg. Rett ruten mot en Service-VIP eller en nodeadresse som blir stående, eller godta at du jager gatewayen etter hver utkastelse. Omvendt veifiltrering er den andre fellen: streng modus slipper pakker hvis returvei ikke samsvarer med grensesnittet de kom inn på, og det er nøyaktig formen på en bevart VPN-flyt.

Løs validering er ofte forskjellen mellom en fungerende returvei og svar som forsvinner etter å ha forlatt backend. Masquerade-regler på VPN-noden må også utelukke tunnelområdet, ellers forlater den videresendte pakken med podens adresse, uansett hvilken rute du har bygget. Foretrekk å uttrykke den utelukkelsen i CNI-ets egen konfigurasjon i stedet for å redigere iptables for hånd, fordi agenten skriver om kjedene sine ved omstart, og din håndskrevne regel overlever nøyaktig til neste oppgradering.

NetworkPolicy er tilgangskontroll, ikke ruting. Å stramme inn en policy vil aldri gjenopprette en adresse som masquerade allerede har erstattet.

Hva SNAT koster, og hvordan du skriver det ned

Kilde-NAT mot klyngen er det billigere designet, og det er ikke en feil. Backend ser VPN-podens eller nodens adresse, loggene stemmer overens, og ingen returrute trenger å finnes. Det du mister, er evnen til å skille to klienter på nettverkslaget, så kvoter, bans og revisjonsspor må komme fra et annet sted.

Vanligvis er det andre stedet applikasjonen: et sesjonstoken, en signert header eller en PROXY-protokollinje skrevet av en proxy du kontrollerer. Disse gir mottakeren en identitet den bare kan stole på når proxyen sitter i veien og headeren ikke kan settes fra klientsiden. Vær eksplisitt i runbooken om hvilken som gjelder, fordi den neste ingeniøren vil anta at adressen i loggen er klienten. Det er den ikke, og én hendelse er nok til å gjøre den antakelsen dyr.

Byttet forblir ærlig så lenge det er skrevet ned.

Kontroller som skiller en fungerende vei fra en heldig

Test med en fersk forbindelse i stedet for en bufret, og test i begge retninger. Flere feil virker bare periodiske fordi nye flyter tar den omskrevne veien.

Fang tuple-en på tre punkter under én autorisert forespørsel: rett etter dekapsulering, på VPN-podens utgangsgrensesnitt og på backend. Hvis kilden endres mellom den andre og tredje fangsten, ligger årsaken nedstrøms for poden. Hvis den endres før den andre, oversetter poden selv.

Slett deretter VPN-poden og gjenta testen mens den omplanlegges. En bevart vei som bryter ved utkastelse, er uferdig, og det samme er en NAT-regel festet til en adresse som ikke lenger finnes. Send til slutt én forespørsel fra en kilde du forventer blir avvist, og bekreft at avvisningen kommer fra policy og ikke fra en manglende rute.