IP odjemalca VPN v Kubernetes: ohraniti ali izvesti SNAT?
Izberite med ohranitvijo pravega naslova odjemalca VPN in izvornim NAT v Kubernetes na podlagi treh pogojev, nato preverite povratno pot in menjavo podov.
Nekje med tunelom in backendom naslov odjemalca bodisi preživi bodisi se zamenja, in oba izida sta zagovorljiva. Izbira pripada lastniku sprejemne storitve, ne tistemu, ki je namestil CNI. Ko so pomembne avtorizacije po odjemalcu, kvote ali revizijski zapisi, mora naslov preživeti vsak skok. Ko je skupno pripisovanje sprejemljivo, izvorni NAT odpravi težavo usmerjanja, ki bi jo sicer vzdrževali za vedno.
Kje naslov odjemalca v resnici izgine
Paket oddaljenega odjemalca prispe v pod VPN z notranjim izvirom v območju tunela, recimo 10.90.0.42. Ko pod ta paket posreduje proti ClusterIP ali IP-ju poda, lahko izvor prepišejo trije različni mehanizmi. Pravilo masquerade v CNI vozlišča pokriva promet, ki ga pod pošilja zunaj CIDR gruče. Vnos conntrack v kube-proxy na ciljnem vozlišču pokriva sam skok do Service. Proxy, ki povezavo zaključi, paketa sploh ne posreduje, zato izvor, ki ga na koncu vidite, pripada proxyju.
Vsak živi v drugem sloju, zato eno polje Service skoraj nikoli ne popravi celotne poti.
externalTrafficPolicy na javnem Service VPN odloča le o tem, kaj se zgodi z zunanjo povezavo: Local ohrani oddaljeni naslov na vozlišču, ki ga je prejelo, medtem ko Cluster dovoli kube-proxyju, da paket preda drugemu vozlišču in ga tam maskira. Ta nastavitev upravlja listener, na katerega se povezujejo vaši odjemalci. Ne pove ničesar o dešifriranem paketu, ki ga vaš proces VPN nato usmeri v gručo.
Trije pogoji, ki razrešijo razpravo
Vedno postavim ista tri vprašanja v istem vrstnem redu, ko se to pojavi, ker prvo običajno konča razpravo. Odgovorite zanje za konkretno delovno obremenitev in ne za gručo kot celoto. Dve gruči v istem podjetju lahko prideta do različnih odgovorov in oba sta lahko pravilna.
| 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 |
Če backend na prvo vprašanje odgovori z da in na drugo z ne, imate omrežno delo, ne manifest za urejanje. Če tretja vrstica pravi proxy, naslov ne bi nikoli preživel, in pretvarjanje nasprotnega stane teden zajemanja paketov.
Kaj način preserve zahteva od omrežja
Ohraniti izvor pomeni, da mora ciljno vozlišče vračati promet na 10.90.0.42 prek aktivnega gatewaya VPN. Skupina VPN ni CIDR gruče, zato je noben CNI privzeto ne usmerja namesto vas. Pot dodate sami in nato poskrbite, da končna točka gatewaya, na katero kaže, preživi prerazporeditev.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2Ta naslednji skok je naslov poda, naslovi podov pa se premikajo. Usmerite pot na VIP Service ali na naslov vozlišča, ki ostane na mestu, ali sprejmite, da boste gateway lovili po vsaki izselitvi. Filtriranje obratne poti je druga past: strogi način zavrže pakete, katerih povratna pot se ne ujema z vmesnikom, po katerem so prispeli, kar je natanko oblika ohranjenega toka VPN.
Ohlapno preverjanje je pogosto razlika med delujočo povratno potjo in odgovori, ki izginejo po tem, ko zapustijo backend. Pravila masquerade na vozlišču VPN morajo prav tako izključiti območje tunela, sicer posredovani paket odide z naslovom poda, ne glede na to, kakšno pot ste zgradili. Raje izrazite to izključitev v konfiguraciji samega CNI, namesto da bi iptables urejali ročno, ker agent ob ponovnem zagonu prepiše svoje verige in vaše ročno napisano pravilo preživi natanko do naslednje nadgradnje.
NetworkPolicy je nadzor dostopa, ne usmerjanje. Zaostritev pravilnika nikoli ne bo obnovila naslova, ki ga je masquerade že zamenjal.
Koliko stane SNAT in kako ga zapisati
Izvorni NAT proti gruči je cenejša zasnova in ni napaka. Backend vidi naslov poda ali vozlišča VPN, dnevniki se ujemajo in nobena povratna pot ni potrebna. Kar izgubite, je zmožnost razlikovanja dveh odjemalcev na omrežnem sloju, zato morajo kvote, prepovedi in revizijske sledi priti od drugod.
Običajno je ta drugod aplikacija: sejni žeton, podpisan header ali vrstica protokola PROXY, ki jo zapiše proxy, ki ga nadzorujete. Ti dajejo prejemniku identiteto, ki ji lahko zaupa le, ko je proxy na poti in headerja ni mogoče nastaviti z odjemalčeve strani. V runbooku bodite izrecni, katera velja, ker bo naslednji inženir domneval, da je naslov v dnevniku odjemalec. Ni, in en incident zadostuje, da to domnevo naredi drago.
Menjava ostane poštena, dokler je zapisana.
Preverjanja, ki ločijo delujočo pot od srečne
Preizkusite z novo povezavo, ne s predpomnjeno, in preizkusite v obe smeri. Več napak se zdi občasnih le zato, ker novi tokovi uberejo prepisano pot.
Zajemite tuple na treh mestih med eno odobreno zahtevo: takoj po dekapsulaciji, na izhodnem vmesniku poda VPN in na backendu. Če se izvor spremeni med drugim in tretjim zajemom, je vzrok dolvodno od poda. Če se spremeni pred drugim, prevaja sam pod.
Nato izbrišite pod VPN in test ponovite, medtem ko se prerazporeja. Ohranjena pot, ki se ob izselitvi zlomi, je nedokončana, in prav tako pravilo NAT, pripeto na naslov, ki ne obstaja več. Nazadnje pošljite eno zahtevo z izvora, za katerega pričakujete, da bo zavrnjen, in potrdite, da zavrnitev prihaja iz pravilnika in ne iz manjkajoče poti.