IP klienta VPN v Kubernetes: zachovať, alebo SNAT?
Vyberte si medzi zachovaním skutočnej adresy klienta VPN a zdrojovým NAT v Kubernetes pomocou troch podmienok, potom overte spätnú cestu a obmenu podov.
Niekde medzi tunelom a backendom adresa klienta buď prežije, alebo je nahradená, a oba výsledky sú obhájiteľné. Voľba patrí vlastníkovi prijímajúcej služby, nie tomu, kto nainštaloval CNI. Keď záleží na autorizácii podľa klienta, kvótach alebo auditných záznamoch, adresa musí prežiť každý skok. Keď je zdieľané pripísanie prijateľné, zdrojový NAT odstráni problém smerovania, ktorý by ste inak udržiavali naveky.
Kde adresa klienta naozaj mizne
Paket vzdialeného klienta dorazí do podu VPN s vnútorným zdrojom v rozsahu tunela, povedzme 10.90.0.42. Keď pod tento paket posunie ďalej smerom k ClusterIP alebo IP podu, zdroj môžu prepísať tri rôzne mechanizmy. Pravidlo masquerade v CNI uzla pokrýva prevádzku, ktorú pod posiela mimo CIDR clusteru. conntrack záznam kube-proxy na cieľovom uzle pokrýva samotný skok na Service. Proxy, ktoré spojenie ukončí, paket vôbec neposunie, takže zdroj, ktorý nakoniec vidíte, patrí proxy.
Každý žije v inej vrstve, a preto jedno pole Service takmer nikdy neopraví celú cestu.
externalTrafficPolicy na verejnom Service VPN rozhoduje len o tom, čo sa stane s vonkajším spojením: Local zachová vzdialenú adresu na uzle, ktorý ju prijal, zatiaľ čo Cluster nechá kube-proxy odovzdať paket inému uzlu a tam ho maskovať. Toto nastavenie riadi listener, na ktorý sa vaši klienti pripájajú. Nehovorí nič o dešifrovanom pakete, ktorý váš proces VPN potom smeruje do clusteru.
Tri podmienky, ktoré spor rozhodnú
Kladím rovnaké tri otázky v rovnakom poradí zakaždým, keď sa to objaví, pretože prvá zvyčajne diskusiu ukončí. Odpovedzte na ne pre konkrétnu záťaž, nie pre cluster ako celok. Dva clustery v jednej firme môžu dospieť k rôznym odpovediam a obe môžu byť správne.
| 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 |
Ak backend odpovie áno na prvú otázku a nie na druhú, máte prácu na sieti, nie manifest na úpravu. Ak tretí riadok hovorí proxy, adresa nikdy nemala prežiť, a predstierať opak stojí týždeň zachytávania paketov.
Čo režim preserve vyžaduje od siete
Zachovať zdroj znamená, že cieľový uzol musí vracať prevádzku na 10.90.0.42 cez aktívny VPN gateway. Fond VPN nie je CIDR clusteru, takže ho žiadne CNI predvolene nesmeruje za vás. Pridáte trasu sami a potom zabezpečíte, aby koncový bod gateway, na ktorý ukazuje, prežil preplánovanie.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2Ďalší skok je adresa podu a adresy podov sa pohybujú. Nasmerujte trasu na VIP Service alebo na adresu uzla, ktorá zostane na mieste, alebo prijmite, že gateway budete naháňať po každom vyhostení. Filtrovanie reverznej cesty je druhá pasca: striktný režim zahadzuje pakety, ktorých spätná cesta nezodpovedá rozhraniu, na ktorom dorazili, čo je presne podoba zachovaného toku VPN.
Voľná validácia je často rozdiel medzi funkčnou spätnou cestou a odpoveďami, ktoré po opustení backendu zmiznú. Pravidlá masquerade na uzle VPN tiež musia vylúčiť rozsah tunela, inak posunutý paket odíde s adresou podu, bez ohľadu na to, akú trasu ste postavili. Vyjadrite toto vylúčenie radšej vo vlastnej konfigurácii CNI než ručnou úpravou iptables, pretože agent pri reštarte prepisuje svoje reťazce a vaše ručne písané pravidlo prežije presne do ďalšieho upgradu.
NetworkPolicy je riadenie prístupu, nie smerovanie. Sprísnenie politiky nikdy neobnoví adresu, ktorú masquerade už nahradil.
Čo SNAT stojí a ako to zapísať
Zdrojový NAT smerom do clusteru je lacnejší dizajn a nie je to chyba. Backend vidí adresu podu alebo uzla VPN, záznamy si navzájom zodpovedajú a nemusí existovať žiadna spätná trasa. Čo stratíte, je schopnosť rozlíšiť dvoch klientov na sieťovej vrstve, takže kvóty, zákazy a auditné stopy musia prísť odinakiaľ.
Zvyčajne je tým odinakiaľ aplikácia: relačný token, podpísaná hlavička alebo riadok protokolu PROXY, ktorý zapisuje proxy, ktoré ovládate. Tie dávajú príjemcovi identitu, ktorej môže veriť len vtedy, keď proxy stojí v ceste a hlavičku nemožno nastaviť zo strany klienta. V runbooku výslovne uveďte, ktorá platí, pretože ďalší inžinier bude predpokladať, že adresa v zázname je klient. Nie je, a jeden incident stačí, aby bol tento predpoklad drahý.
Výmena zostáva poctivá, kým je zapísaná.
Kontroly, ktoré oddelia funkčnú cestu od šťastnej
Testujte s novým spojením, nie s uloženým v cache, a testujte v oboch smeroch. Niektoré poruchy vyzerajú prerušovane len preto, že nové toky idú prepísanou cestou.
Zachytte tuple na troch miestach počas jednej autorizovanej požiadavky: hneď po dekapsulácii, na výstupnom rozhraní podu VPN a na backende. Ak sa zdroj zmení medzi druhým a tretím zachytením, príčina je po prúde od podu. Ak sa zmení pred druhým, prekladá sám pod.
Potom pod VPN vymažte a test zopakujte, kým sa preplánováva. Zachovaná cesta, ktorá sa pri vyhostení zlomí, je nedokončená, a rovnako aj pravidlo NAT pripnuté k adrese, ktorá už neexistuje. Nakoniec pošlite jednu požiadavku zo zdroja, pri ktorom očakávate odmietnutie, a potvrďte, že odmietnutie prichádza z politiky, nie z chýbajúcej trasy.