VPN-kliënt-IP in Kubernetes: bewaar dit of SNAT dit?

Iewers tussen die tonnel en die backend oorleef ’n kliëntadres of word vervang, en albei uitkomste is verdedigbaar. Die keuse behoort aan die eienaar van die ontvangende diens, nie aan die een wat die CNI geïnstalleer het nie. Wanneer per-kliënt-magtiging, kwotas of ouditspore saak maak, moet die adres elke hop oorleef. Wanneer gedeelde toeskrywing aanvaarbaar is, verwyder bron-NAT ’n routeringsprobleem wat jy anders vir altyd sou onderhou.

Waar die kliëntadres werklik verdwyn

’n Pakket van ’n afgeleë kliënt bereik die VPN-pod met ’n interne bron binne die tonnelreeks, sê 10.90.0.42. Wanneer die pod daardie pakket na ’n ClusterIP of ’n pod-IP aanstuur, kan drie verskillende meganismes die bron herskryf. Die node se CNI-masquerade-reël dek verkeer wat die pod buite die cluster-CIDR stuur. kube-proxy se conntrack-inskrywing op die bestemmingsnode dek die Service-hop self. ’n Proxy wat die verbinding termineer, stuur die pakket glad nie aan nie, so die bron wat jy uiteindelik sien, behoort aan die proxy.

Elkeen woon in ’n ander laag, daarom herstel een Service-veld byna nooit die hele pad nie.

externalTrafficPolicy op die VPN se publieke Service bepaal net wat met die buitenste verbinding gebeur: Local hou die afgeleë adres op die node wat dit ontvang het, terwyl Cluster kube-proxy toelaat om die pakket aan ’n ander node te gee en dit daar te masquerade. Daardie instelling beheer die luisteraar waarmee jou kliënte skakel. Dit sê niks oor die ontslote pakket wat jou VPN-proses daarna in die cluster instuur nie.

Drie voorwaardes wat die argument besleg

Ek vra elke keer dieselfde drie vrae in dieselfde volgorde wanneer dit opduik, want die eerste een beëindig gewoonlik die bespreking. Antwoord hulle vir die spesifieke werklading eerder as vir die cluster as geheel. Twee clusters in een maatskappy kan op verskillende antwoorde beland en albei reg wees.

As die backend ja antwoord op die eerste vraag en nee op die tweede, het jy netwerkwerk om te doen eerder as ’n manifest om te wysig. As die derde ry proxy sê, sou die adres nooit oorleef het nie, en om anders voor te gee kos ’n week se pakketopnames.

Wat preserve-modus van die netwerk vereis

Om die bron te bewaar, beteken die bestemmingsnode moet verkeer na 10.90.0.42 deur ’n aktiewe VPN-gateway terugstuur. Die VPN-poel is nie ’n cluster-CIDR nie, so geen CNI roeteer dit vir jou by verstek nie. Jy voeg die roete self by en maak dan seker dat die gateway-eindpunt waarheen dit wys, ’n herskedulering oorleef.

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

Daardie volgende hop is ’n pod-adres, en pod-adresse beweeg. Rig die roete op ’n Service-VIP of ’n node-adres wat bly staan, of aanvaar dat jy die gateway na elke uitsetting sal jaag. Omgekeerde-pad-filtering is die ander valstrik: streng modus laat pakkette val wie se terugpad nie ooreenstem met die koppelvlak waarop hulle aangekom het nie, wat presies die vorm van ’n bewaarde VPN-vloei is.

Losse validering is dikwels die verskil tussen ’n werkende terugpad en antwoorde wat verdwyn nadat hulle die backend verlaat het. Masquerade-reëls op die VPN-node moet ook die tonnelreeks uitsluit, anders verlaat die aangestuurde pakket met die pod se adres, maak nie saak watter roete jy gebou het nie. Verkies om daardie uitsluiting in die CNI se eie konfigurasie uit te druk eerder as om iptables met die hand te wysig, want die agent herskryf sy kettings met herstart en jou handgeskrewe reël oorleef presies tot die volgende opgradering.

NetworkPolicy is toegangsbeheer, nie routering nie. Om ’n beleid te verskerp sal nooit ’n adres herstel wat masquerade reeds vervang het nie.

Wat SNAT kos, en hoe om dit neer te skryf

Bron-NAT na die cluster is die goedkoper ontwerp, en dit is nie ’n fout nie. Die backend sien die VPN-pod of node-adres, logs stem met mekaar ooreen, en geen terugroete hoef te bestaan nie. Wat jy verloor, is die vermoë om twee kliënte op netwerkvlak uit mekaar te ken, so kwotas, verbannings en ouditspore moet van elders kom.

Gewoonlik is daardie elders die toepassing: ’n sessietoken, ’n ondertekende kop, of ’n PROXY-protokolreël wat deur ’n proxy geskryf word wat jy beheer. Dit gee die ontvanger ’n identiteit wat hy net kan vertrou wanneer die proxy in die pad sit en die kop nie van die kliëntkant af gestel kan word nie. Wees uitdruklik in die runbook oor watter een van toepassing is, want die volgende ingenieur sal aanvaar dat die adres in die log die kliënt is. Dit is nie, en een insident is genoeg om daardie aanname duur te maak.

Die ruil bly eerlik solank dit neergeskryf word.

Kontroles wat ’n werkende pad van ’n gelukkige een skei

Toets met ’n vars verbinding eerder as ’n gekaste een, en toets in albei rigtings. Verskeie foute lyk net wisselvallig omdat nuwe vloei die herskryfde pad neem.

Vang die tuple op drie punte tydens een gemagtigde versoek: reg ná dekapsulering, by die VPN-pod se uitgangskoppelvlak, en op die backend. As die bron verander tussen die tweede en derde opname, sit die oorsaak stroomaf van die pod. As dit voor die tweede verander, vertaal die pod self.

Verwyder dan die VPN-pod en herhaal die toets terwyl dit herskeduleer. ’n Bewaarde pad wat op uitsetting breek, is onvoltooi, en so ook ’n NAT-reël wat vasgepen is aan ’n adres wat nie meer bestaan nie. Stuur laastens een versoek van ’n bron wat jy verwag om geweier te word en bevestig die weiering kom van beleid eerder as van ’n ontbrekende roete.