IP cleient VPN o fewn Kubernetes: ei gadw neu ei SNAT-io?

Rhywle rhwng y tiwnel a'r backend, mae cyfeiriad cleient naill ai'n goroesi neu'n cael ei ddisodli, ac mae'r ddau ganlyniad yn amddiffynadwy. Eiddo pwy bynnag sy'n berchen ar y gwasanaeth derbyn yw'r dewis, nid pwy bynnag a osododd y CNI. Pan fo awdurdodiad fesul cleient, cwotâu neu gofnodion archwilio yn bwysig, rhaid i'r cyfeiriad oroesi pob naid. Pan fo cydbriodoliad yn dderbyniol, mae NAT ffynhonnell yn dileu problem llwybrau y byddech fel arall yn ei chynnal am byth.

Lle mae cyfeiriad y cleient yn diflannu mewn gwirionedd

Mae pecyn cleient o bell yn cyrraedd y pod VPN â ffynhonnell fewnol o fewn ystod y tiwnel, dyweder 10.90.0.42. Pan fo'r pod yn anfon y pecyn hwnnw tuag at ClusterIP neu IP pod, gall tri mecanwaith wahanol ailysgrifennu'r ffynhonnell. Mae rheol masquerade CNI y nod yn cwmpasu traffig y mae'r pod yn ei anfon y tu allan i CIDR y clwstwr. Mae cofnod conntrack kube-proxy ar y nod cyrchfan yn cwmpasu'r naid Service ei hun. Nid yw proxy sy'n terfynu'r cysylltiad yn anfon y pecyn o gwbl, felly mae'r ffynhonnell a welwch yn y pen draw yn perthyn i'r proxy.

Mae pob un yn byw mewn haen wahanol, a dyna pam nad yw un maes Service bron byth yn trwsio'r llwybr cyfan.

Mae externalTrafficPolicy ar Service cyhoeddus y VPN yn penderfynu'n unig beth sy'n digwydd i'r cysylltiad allanol: mae Local yn cadw'r cyfeiriad pell ar y nod a'i derbyniodd, tra mae Cluster yn gadael i kube-proxy drosglwyddo'r pecyn i nod arall a gwneud masquerade yno. Mae'r gosodiad hwnnw'n llywodraethu'r gwrandawr y mae eich cleientiaid yn cysylltu ag ef. Nid yw'n dweud dim am y pecyn dadgryptio y mae eich proses VPN yn ei lwybro i'r clwstwr wedyn.

Tri amod sy'n setlo'r ddadl

Rwy'n gofyn yr un tri chwestiwn yn yr un drefn bob tro y mae hyn yn codi, oherwydd mae'r cyntaf fel arfer yn diweddu'r drafodaeth. Atebwch nhw ar gyfer y llwyth gwaith penodol yn hytrach nag ar gyfer y clwstwr cyfan. Gall dau glwstwr o fewn un cwmni gyrraedd atebion gwahanol a bod y ddau yn gywir.

Os yw'r backend yn ateb ie i'r cwestiwn cyntaf a na i'r ail, mae gennych waith rhwydwaith i'w wneud yn hytrach na manifest i'w olygu. Os yw'r drydedd res yn dweud proxy, nid oedd y cyfeiriad byth yn mynd i oroesi, ac mae esgus fel arall yn costio wythnos o gasglu pecynnau.

Beth mae modd preserve yn ei ofyn gan y rhwydwaith

Mae cadw'r ffynhonnell yn golygu bod yn rhaid i'r nod cyrchfan ddychwelyd traffig i 10.90.0.42 drwy gateway VPN gweithredol. Nid CIDR clwstwr yw pwll y VPN, felly nid oes CNI yn ei lwybro i chi yn ddiofyn. Rydych chi'n ychwanegu'r llwybr eich hun, yna'n sicrhau bod pen draw'r gateway y mae'n cyfeirio ato yn goroesi ailamserlennu.

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

Mae'r naid nesaf honno'n gyfeiriad pod, ac mae cyfeiriadau pod yn symud. Cyfeiriwch y llwybr at VIP Service neu gyfeiriad nod sy'n aros yn ei le, neu dderbyn y byddwch yn hela'r gateway ar ôl pob dadfeddiannu. Mae hidlo llwybr cefn yn y fagl arall: mae modd caeth yn gollwng pecynnau nad yw eu llwybr dychwelyd yn cyfateb i'r rhyngwyneb y cyrhaeddasant arno, sef yn union siâp llif VPN a gadwyd.

Mae dilysu llac yn aml yw'r gwahaniaeth rhwng llwybr dychwelyd sy'n gweithio a atebion sy'n diflannu ar ôl gadael y backend. Rhaid i reolau masquerade ar y nod VPN hefyd eithrio ystod y tiwnel, neu bydd y pecyn a anfonwyd yn gadael â chyfeiriad y pod, waeth pa lwybr a adeiladwyd gennych. Mae'n well mynegi'r eithriad hwnnw yn ffurfweddiad y CNI ei hun yn hytrach na golygu iptables â llaw, oherwydd mae'r asiant yn ailysgrifennu ei gadwyni wrth ailddechrau ac mae eich rheol â llaw yn goroesi'n union tan y diweddariad nesaf.

NetworkPolicy yw rheolaeth mynediad, nid llwybro. Ni fydd tynhau polisi byth yn adfer cyfeiriad y mae masquerade eisoes wedi'i ddisodli.

Beth mae SNAT yn ei gostio, a sut i'w ysgrifennu i lawr

NAT ffynhonnell tuag at y clwstwr yw'r dyluniad rhatach, ac nid yw'n gamgymeriad. Mae'r backend yn gweld cyfeiriad pod neu nod y VPN, mae'r cofnodion yn cytuno â'i gilydd, ac nid oes rhaid i unrhyw lwybr dychwelyd fodoli. Yr hyn a gollwch yw'r gallu i wahaniaethu dau gleient ar haen y rhwydwaith, felly rhaid i gwotâu, gwaharddiadau ac olion archwilio ddod o rywle arall.

Fel arfer yr 'rywle arall' hwnnw yw'r cymhwysiad: tocsen sesiwn, pennawd wedi'i lofnodi, neu linell protocol PROXY a ysgrifennwyd gan proxy rydych yn ei reoli. Mae'r rhain yn rhoi i'r derbynnydd hunaniaeth y gall ymddiried ynddi dim ond pan fo'r proxy ar y llwybr ac na ellir gosod y pennawd o ochr y cleient. Byddwch yn eglur yn y runbook pa un sy'n berthnasol, oherwydd bydd y peiriannydd nesaf yn tybio mai'r cyfeiriad yn y cofnod yw'r cleient. Nid yw, ac mae un digwyddiad yn ddigon i wneud y dybiaeth honno'n gostus.

Mae'r cyfnewid yn parhau'n onest cyhyd ag y caiff ei ysgrifennu.

Gwiriadau sy'n gwahanu llwybr gweithredol oddi wrth un lwcus

Profwch â chysylltiad newydd yn hytrach nag un wedi'i gacheio, a phrofwch y ddau gyfeiriad. Mae sawl methiant yn ymddangos yn ysbeidiol dim ond oherwydd bod llifau newydd yn cymryd y llwybr a ailysgrifennwyd.

Cipiwch y tuple ar dri phwynt yn ystod un cais awdurdodedig: yn syth ar ôl dadgapsiwleiddio, ar ryngwyneb allanfa pod y VPN, ac ar y backend. Os yw'r ffynhonnell yn newid rhwng yr ail a'r trydydd cipiad, mae'r achos yn is i lawr na'r pod. Os yw'n newid cyn yr ail, mae'r pod ei hun yn cyfieithu.

Yna dilëwch y pod VPN ac ailadroddwch y prawf tra mae'n ailamserlennu. Mae llwybr a gadwyd sy'n torri ar ddadfeddiannu yn anorffenedig, ac felly hefyd rheol NAT wedi'i phinio i gyfeiriad nad yw'n bodoli mwyach. Yn olaf, anfonwch un cais o ffynhonnell rydych yn disgwyl iddi gael ei gwrthod a chadarnhewch fod y gwrthodiad yn dod o bolisi yn hytrach nag o lwybr ar goll.