IP VPN klijenta unutar Kubernetes: sačuvati ga ili ga SNAT-ati?

Negdje između tunela i backenda adresa klijenta ili preživi ili bude zamijenjena, a oba su ishoda obranjiva. Izbor pripada onome tko posjeduje uslužni servis, a ne onome tko je instalirao CNI. Kada su autorizacija po klijentu, kvote ili revizijski zapisi važni, adresa mora preživjeti svaki skok. Kada je zajedničko pripisivanje prihvatljivo, izvorni NAT uklanja problem usmjeravanja koji biste inače održavali zauvijek.

Gdje adresa klijenta zapravo nestaje

Paket udaljenog klijenta stiže na VPN pod s unutarnjim izvorom unutar raspona tunela, recimo 10.90.0.42. Kada pod proslijedi taj paket prema ClusterIP-u ili IP-u poda, tri različita mehanizma mogu prepisati izvor. Pravilo masquerade na CNI-ju čvora pokriva promet koji pod šalje izvan CIDR-a klastera. conntrack zapis kube-proxyja na odredišnom čvoru pokriva sam skok do Servicea. Proxy koji prekida vezu uopće ne prosljeđuje paket, pa izvor koji na kraju vidite pripada proxyju.

Svaki živi u drugom sloju, zato jedno polje Servicea gotovo nikad ne popravlja cijelu putanju.

externalTrafficPolicy na javnom Serviceu VPN-a odlučuje samo što se događa s vanjskom vezom: Local zadržava udaljenu adresu na čvoru koji ju je primio, dok Cluster dopušta kube-proxyju da paket preda drugom čvoru i tamo ga maskira. Ta postavka upravlja listenerom na koji se vaši klijenti spajaju. Ne govori ništa o dešifriranom paketu koji vaš VPN proces zatim usmjerava u klaster.

Tri uvjeta koja rješavaju raspravu

Postavljam ista tri pitanja istim redoslijedom svaki put kad se ovo pojavi, jer prvo obično završava raspravu. Odgovorite na njih za konkretno radno opterećenje, a ne za cijeli klaster. Dva klastera unutar jedne tvrtke mogu doći do različitih odgovora i oba biti točna.

Ako backend odgovori da na prvo pitanje i ne na drugo, pred vama je mrežni posao, a ne manifest za uređivanje. Ako treći redak kaže proxy, adresa nikad nije ni trebala preživjeti, a pretvaranje da nije tako košta tjedan dana hvatanja paketa.

Što preserve način zahtijeva od mreže

Čuvanje izvora znači da odredišni čvor mora vraćati promet na 10.90.0.42 kroz aktivni VPN gateway. VPN pool nije CIDR klastera, pa ga nijedan CNI ne usmjerava umjesto vas prema zadanim postavkama. Rutu dodajete sami, a zatim se pobrinete da gateway endpoint na koji pokazuje preživi ponovno raspoređivanje.

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

Taj sljedeći skok je adresa poda, a adrese podova se sele. Usmjerite rutu na Service VIP ili adresu čvora koja ostaje na mjestu ili prihvatite da ćete loviti gateway nakon svakog izbacivanja. Filtriranje obrnute putanje druga je zamka: strogi način odbacuje pakete čija povratna putanja ne odgovara sučelju na kojem su stigli, a to je upravo oblik sačuvanog VPN toka.

Labava validacija često je razlika između povratne putanje koja radi i odgovora koji nestanu nakon što napuste backend. Pravila masquerade na VPN čvoru također moraju isključiti raspon tunela, inače proslijeđeni paket izlazi s adresom poda, bez obzira na rutu koju ste izgradili. Radije izrazite to isključenje u vlastitoj konfiguraciji CNI-ja umjesto ručnog uređivanja iptablesa, jer agent prepisuje svoje lance pri ponovnom pokretanju i vaše ručno napisano pravilo preživi točno do sljedeće nadogradnje.

NetworkPolicy je kontrola pristupa, a ne usmjeravanje. Zaostravanje pravila nikada neće vratiti adresu koju je masquerade već zamijenio.

Koliko košta SNAT i kako ga zapisati

Izvorni NAT prema klasteru je jeftiniji dizajn i nije pogreška. Backend vidi adresu VPN poda ili čvora, zapisi se međusobno slažu i nikakva povratna ruta ne mora postojati. Ono što gubite jest mogućnost razlikovanja dvaju klijenata na mrežnom sloju, pa kvote, zabrane i revizijski tragovi moraju doći odnekud drugdje.

Obično je to negdje drugdje aplikacija: sesijski token, potpisano zaglavlje ili PROXY protokolni redak koji piše proxy koji kontrolirate. Oni daju primatelju identitet kojem može vjerovati samo kad je proxy na putanji i zaglavlje se ne može postaviti s klijentske strane. Budite izričiti u runbooku o tome koje se primjenjuje, jer će sljedeći inženjer pretpostaviti da je adresa u zapisu klijent. Nije, a jedan incident dovoljan je da tu pretpostavku učini skupom.

Razmjena ostaje poštena dokle god je zapisana.

Provjere koje razlikuju putanju koja radi od one koja ima sreće

Testirajte sa svježom vezom, a ne s onom iz predmemorije, i testirajte u oba smjera. Nekoliko kvarova izgleda povremeno samo zato što novi tokovi idu prepisanom putanjom.

Snimite tuple na tri mjesta tijekom jednog ovlaštenog zahtjeva: odmah nakon dekapsulacije, na izlaznom sučelju VPN poda i na backendu. Ako se izvor promijeni između drugog i trećeg snimanja, uzrok je nizvodno od poda. Ako se promijeni prije drugog, sam pod prevodi.

Zatim obrišite VPN pod i ponovite test dok se ponovno raspoređuje. Sačuvana putanja koja se slomi pri izbacivanju nedovršena je, a takvo je i NAT pravilo vezano uz adresu koja više ne postoji. Na kraju pošaljite jedan zahtjev s izvora za koji očekujete da će biti odbijen i potvrdite da odbijanje dolazi od pravila, a ne od rute koja nedostaje.