VPN-klienta IP en Kubernetes: ĉu konservi aŭ fari SNAT?

Ie inter la tunelo kaj la backend, klienta adreso aŭ postvivas aŭ estas anstataŭigita, kaj ambaŭ rezultoj estas defendeblaj. La elekto apartenas al la posedanto de la ricevanta servo, ne al tiu, kiu instalis la CNI. Kiam per-klienta rajtigo, kvotoj aŭ reviziaj registro-buroj gravas, la adreso devas travivi ĉiun salteton. Kiam komuna atribuo estas akceptebla, fonta NAT forigas vojigan problemon, kiun vi alie prizorgus por ĉiam.

Kie la klienta adreso vere malaperas

Paketo de fora kliento alvenas al la VPN-podo kun interna fonto ene de la tunela gamo, diru 10.90.0.42. Kiam la podo plusendas tiun paketon al ClusterIP aŭ poda IP, tri malsamaj mekanismoj povas reskribi la fonton. La masquerade-regulo de la CNI sur la nodo kovras trafikon, kiun la podo sendas ekster la CIDR de la klastero. La conntrack-enskribo de kube-proxy sur la cellnodo kovras la Service-salteton mem. Prokuro, kiu finas la konekton, tute ne plusendas la paketon, do la fonto, kiun vi finfine vidas, apartenas al la prokuro.

Ĉiu el ili vivas en malsama tavolo, tial unu Service-kampo preskaŭ neniam riparas la tutan vojon.

externalTrafficPolicy sur la publika Service de la VPN decidas nur, kio okazas al la ekstera konekto: Local tenas la foran adreson sur la nodo, kiu ricevis ĝin, dum Cluster permesas al kube-proxy transdoni la paketon al alia nodo kaj masquerade ĝin tie. Tiu agordo regas la aŭskultanton, kiun viaj klientoj kontaktas. Ĝi diras nenion pri la malĉifrita paketo, kiun via VPN-procezo poste enkursigas en la klasteron.

Tri kondiĉoj, kiuj finas la debaton

Mi starigas la samajn tri demandojn en la sama ordo ĉiufoje, kiam ĉi tio aperas, ĉar la unua kutime finas la diskuton. Respondu ilin por la konkreta laborŝarĝo, ne por la tuta klastero. Du klasteroj en unu firmao povas atingi malsamajn respondojn kaj ambaŭ pravas.

Se la backend respondas jes al la unua demando kaj ne al la dua, vi havas retan laboron, ne manifeston por redakti. Se la tria vico diras prokuro, la adreso neniam postvivus, kaj ŝajnigi la malon kostas semajnon da paketa kaptado.

Kion la reĝimo preserve postulas de la reto

Konservi la fonton signifas, ke la cellnodo devas resendi trafikon al 10.90.0.42 tra aktiva VPN-pordego. La VPN-baseno ne estas CIDR de la klastero, do neniu CNI enkursigas ĝin por vi defaŭlte. Vi aldonas la itineron mem, poste certigas, ke la pordega finpunkto, al kiu ĝi montras, postvivas replanadon.

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

Tiu sekva salteto estas poda adreso, kaj podaj adresoj moviĝas. Direktu la itineron al Service-VIP aŭ al noda adreso, kiu restas surloke, aŭ akceptu, ke vi postkuros la pordegon post ĉiu elpelado. Inversa voja filtrado estas la alia kaptilo: la strikta reĝimo faligas paketojn, kies reena vojo ne kongruas kun la interfaco, per kiu ili alvenis, kaj tio estas ĝuste la formo de konservita VPN-fluo.

Loza validigo ofte estas la diferenco inter funkcianta reena vojo kaj respondoj, kiuj malaperas post forlasi la backend. La masquerade-reguloj sur la VPN-nodo ankaŭ devas ekskludi la tunelan gamon, alie la plusendita paketo eliras kun la adreso de la podo, sendepende de la itinero, kiun vi konstruis. Prefere esprimu tiun ekskludon en la agordo de la CNI mem anstataŭ redakti iptables permane, ĉar la agento reskribas siajn ĉenojn ĉe restarto kaj via permane skribita regulo postvivas ĝuste ĝis la sekva ĝisdatigo.

NetworkPolicy estas alirkontrolo, ne enkursigado. Plistreĉigo de politiko neniam restarigos adreson, kiun masquerade jam anstataŭigis.

Kiom kostas SNAT, kaj kiel noti ĝin

Fonta NAT al la klastero estas la pli malmultekosta dezajno, kaj ĝi ne estas eraro. La backend vidas la adreson de la VPN-podo aŭ nodo, la protokoloj kongruas unu kun la alia, kaj neniu reena itinero devas ekzisti. Kion vi perdas, estas la kapablo distingi du klientojn ĉe la reta tavolo, do kvotoj, malpermesoj kaj reviziaj spuroj devas veni de aliloke.

Kutime tiu aliloke estas la aplikaĵo: sesia ĵetono, subskribita kaplinio aŭ linio de la protokolo PROXY skribita de prokuro, kiun vi kontrolas. Ĉi tiuj donas al la ricevanto identecon, kiun ĝi povas fidi nur kiam la prokuro estas en la vojo kaj la kaplinio ne povas esti agordita de la klienta flanko. Estu eksplicita en la runbook pri tio, kiu validas, ĉar la sekva inĝeniero supozos, ke la adreso en la registro estas la kliento. Ĝi ne estas, kaj unu okazaĵo sufiĉas por igi tiun supozon multekosta.

La interŝanĝo restas honesta tiel longe, kiel ĝi estas skribita.

Kontroloj, kiuj apartigas funkciantan vojon de bonŝanca

Testu per freŝa konekto anstataŭ kaŝmemorigita, kaj testu en ambaŭ direktoj. Pluraj fiaskoj ŝajnas intermitaj nur ĉar novaj fluoj prenas la reskribitan vojon.

Kaptu la tuple en tri punktoj dum unu rajtigita peto: tuj post malĉifrado, sur la elira interfaco de la VPN-podo, kaj sur la backend. Se la fonto ŝanĝiĝas inter la dua kaj tria kaptoj, la kaŭzo estas malsupre de la podo. Se ĝi ŝanĝiĝas antaŭ la dua, la podo mem tradukas.

Poste forigu la VPN-podon kaj ripetu la teston dum ĝi estas replanata. Konservita vojo, kiu rompiĝas ĉe elpelado, estas nefinita, kaj same itinero NAT fiksita al adreso, kiu ne plu ekzistas. Fine, sendu unu peton de fonto, kiun vi atendas esti rifuzita, kaj konfirmu, ke la rifuzo venas de politiko, ne de mankanta itinero.