VPN-kliendi IP Kubernetes sees: säilitada või SNAT-ida?
Valige kolme tingimuse põhjal, kas säilitada tegelik VPN-kliendi aadress või kasutada Kubernetes sees lähtekomponenti NAT-i, seejärel kontrollige tagasiteed ja podide vahetust.
Kusagil tunnelija backend vahel kas kliendi aadress jääb püsima või asendatakse, ja mõlemad tulemused on kaitstavad. Valik kuulub vastuvõtva teenuse omanikule, mitte sellele, kes CNI paigaldas. Kui kliendipõhine autoriseerimine, kvoodid või auditikirjed loevad, peab aadress iga hüppe üle elama. Kui jagatud omistamine on vastuvõetav, kõrvaldab lähtekomponent NAT marsruutimisprobleemi, mida muidu igavesti hooldaksite.
Kus kliendi aadress tegelikult kaob
Kaugkliendi pakett saabub VPN-podini sisemise lähtekohaga tunneli vahemikus, näiteks 10.90.0.42. Kui pod edastab selle paketi ClusterIP või podi IP suunas, võivad lähtekohta ümber kirjutada kolm erinevat mehhanismi. Sõlme CNI masquerade-reegel katab liiklust, mille pod saadab väljapoole klastri CIDR-i. kube-proxy conntrack-kirje sihtsõlmel katab Service hüppe enda. Ühenduse lõpetav proxy ei edasta paketti üldse, seega lõpuks nähtav lähtekoht kuulub proxy-le.
Igaüks elab erinevas kihis, mistõttu üks Service'i väli peaaegu kunagi ei paranda kogu teed.
externalTrafficPolicy VPN-i avalikul Service'il otsustab ainult selle üle, mis juhtub välise ühendusega: Local hoiab kaugema aadressi sõlmel, mis selle vastu võttis, samas kui Cluster lubab kube-proxy-l paketti teisele sõlmele anda ja seda seal maskeerida. See säte juhib listeneri, millele teie kliendid ühenduvad. See ei ütle midagi dekrüpteeritud paketi kohta, mille teie VPN-protsess seejärel klastrisse suunab.
Kolm tingimust, mis vaidluse lahendavad
Esitan samad kolm küsimust samas järjekorras iga kord, kui see teema tõuseb, sest esimene lõpetab tavaliselt arutelu. Vastake nendele konkreetse töökoormuse, mitte kogu klastri kohta. Kaks klastrit ühes ettevõttes võivad jõuda erinevate vastusteni ja mõlemad võivad olla õiged.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
Kui backend vastab esimesele küsimusele jah ja teisele ei, on teil võrgutööd teha, mitte manifesti muuta. Kui kolmas rida ütleb proxy, ei oleks aadress kunagi püsinud, ja vastupidise teesklemine maksab nädala pakettide püüdmist.
Mida preserve-režiim võrgult nõuab
Lähtekoha säilitamine tähendab, et sihtsõlm peab liikluse saatma tagasi aadressile 10.90.0.42 aktiivse VPN-gateway kaudu. VPN-i pool ei ole klastri CIDR, seega ei marsruudi ükski CNI seda teie eest vaikimisi. Lisate marsruudi ise ja seejärel veendute, et gateway'i lõpp-punkt, millele see osutab, elab üle ümberplaneerimise.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2See järgmine hüpe on podi aadress ja podi aadressid liiguvad. Suunake marsruut Service VIP-ile või sõlme aadressile, mis jääb paigale, või leppige sellega, et jälitate gateway'd pärast iga väljatõrjumist. Pöördtee filtreerimine on teine lõks: range režiim hülgab paketid, mille tagasitee ei vasta liidesele, millel need saabusid, ja see on täpselt säilitatud VPN-voo kuju.
Lõtv valideerimine on sageli vahe toimiva tagasitee ja vastuste vahel, mis pärast backendist lahkumist kaovad. VPN-sõlme masquerade-reeglid peavad samuti tunneli vahemikku välja jätma, muidu lahkub edastatud pakett podi aadressiga, olenemata sellest, millise marsruudi ehitasite. Väljendage see väljajätmine pigem CNI enda konfiguratsioonis, mitte iptables'i käsitsi muudates, sest agent kirjutab taaskäivitamisel oma ahelad ümber ja teie käsitsi kirjutatud reegel püsib täpselt järgmise uuenduseni.
NetworkPolicy on juurdepääsukontroll, mitte marsruutimine. Poliitika karmistamine ei taasta kunagi aadressi, mille masquerade on juba asendanud.
Mida SNAT maksab ja kuidas seda kirja panna
Lähtekomponent NAT klastri suunas on odavam disain ja see ei ole viga. Backend näeb VPN-podi või sõlme aadressi, logid on omavahel kooskõlas ja ühtki tagasiteed ei pea olema. Kaotate võime eristada kahte klienti võrgukihis, seega peavad kvoodid, keelud ja auditijäljed tulema mujalt.
Tavaliselt on see mujalt rakendus: sessioonitoken, allkirjastatud päis või PROXY-protokolli rida, mille kirjutab teie juhitav proxy. Need annavad vastuvõtjale identiteedi, mida ta saab usaldada ainult siis, kui proxy on teel ja päist ei saa kliendi poolelt määrata. Olge runbookis selgesõnaline, milline kehtib, sest järgmine insener eeldab, et logis olev aadress on klient. See ei ole, ja ühest intsidendist piisab, et see eeldus kalliks muuta.
Vahetus jääb ausaks seni, kuni see on kirja pandud.
Kontrollid, mis eristavad toimivat teed õnnelikust
Testige värske ühendusega, mitte vahemällu salvestatud ühendusega, ja testige mõlemas suunas. Mitmed tõrked tunduvad katkendlikud ainult seetõttu, et uued vood lähevad ümberkirjutatud teed.
Püüdke tuple'i ühe volitatud päringu ajal kolmes punktis: kohe pärast dekapsuleerimist, VPN-podi väljumisliidesel ja backendis. Kui lähtekoht muutub teise ja kolmanda püüdmise vahel, asub põhjus podist allavoolu. Kui see muutub enne teist, tõlgib pod ise.
Seejärel kustutage VPN-pod ja korrake testi, samal ajal kui see ümber planeeritakse. Säilitatud tee, mis väljatõrjumisel katkeb, on lõpetamata, ja nii on ka NAT-reegel, mis on kinnitatud aadressile, mida enam ei ole. Lõpuks saatke üks päring allikast, mille puhul eeldate keeldumist, ja kinnitage, et keeldumine tuleb poliitikast, mitte puuduvast marsruudist.