IP ng VPN client sa Kubernetes: panatilihin o SNAT?
Pumili sa pagitan ng pagpapanatili ng tunay na address ng VPN client at source NAT sa Kubernetes gamit ang tatlong kundisyon, pagkatapos i-verify ang return path at pod churn.
Sa isang punto sa pagitan ng tunnel at backend, ang address ng kliyente ay maaaring manatili o mapalitan, at parehong resulta ay depensable. Ang pagpili ay pag-aari ng may-ari ng tumatanggap na serbisyo, hindi ng nag-install ng CNI. Kapag mahalaga ang awtorisasyon bawat kliyente, mga quota o audit record, kailangang mabuhay ang address sa bawat hop. Kapag katanggap-tanggap ang shared attribution, inaalis ng source NAT ang isang routing problem na kung hindi ay aalagaan mo magpakailanman.
Saan talaga nawawala ang address ng kliyente
Ang packet ng isang malayong kliyente ay dumarating sa pod ng VPN na may panloob na source sa loob ng tunnel range, sabihin nating 10.90.0.42. Kapag ipinasa ng pod ang packet na iyon patungo sa ClusterIP o pod IP, tatlong magkaibang mekanismo ang maaaring mag-rewrite ng source. Sinasaklaw ng masquerade rule ng CNI sa node ang trapikong ipinapadala ng pod sa labas ng CIDR ng cluster. Sinasaklaw ng conntrack entry ng kube-proxy sa destination node ang mismong hop sa Service. Ang proxy na nagtatapos ng koneksyon ay hindi nagpapasa ng packet, kaya ang source na nakikita mo sa huli ay pag-aari ng proxy.
Bawat isa ay nabubuhay sa magkaibang layer, kaya isang field ng Service ang halos hindi kailanman nag-aayos ng buong landas.
externalTrafficPolicy sa pampublikong Service ng VPN ang nagpapasya lamang sa mangyayari sa panlabas na koneksyon: pinapanatili ng Local ang malayong address sa node na tumanggap nito, habang hinahayaan ng Cluster ang kube-proxy na ibigay ang packet sa ibang node at i-masquerade doon. Ang setting na iyon ang kumokontrol sa listener na kinokonektahan ng mga kliyente mo. Wala itong sinasabi tungkol sa decrypted na packet na ipinapadala ng proseso ng VPN mo sa cluster pagkatapos.
Tatlong kundisyon na nagtatapos sa debate
Itinatanong ko ang parehong tatlong tanong sa parehong pagkakasunod-sunod tuwing lumalabas ito, dahil ang una ay karaniwang nagtatapos sa usapan. Sagutin ang mga ito para sa partikular na workload at hindi para sa buong cluster. Dalawang cluster sa isang kumpanya ay maaaring makarating sa magkaibang sagot at pareho silang tama.
| 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 |
Kung ang backend ay sumagot ng oo sa unang tanong at hindi sa pangalawa, mayroon kang network work na gagawin kaysa manifest na i-edit. Kung sinabi ng ikatlong hilera na proxy, hindi sana nabuhay ang address, at ang pagpapanggap na hindi ay nagkakahalaga ng isang linggong packet capture.
Ano ang hinihingi ng preserve mode mula sa network
Ang pagpapanatili ng source ay nangangahulugang kailangang ibalik ng destination node ang trapiko sa 10.90.0.42 sa pamamagitan ng aktibong VPN gateway. Ang VPN pool ay hindi CIDR ng cluster, kaya walang CNI ang nagro-route nito para sa iyo bilang default. Ikaw mismo ang nagdaragdag ng ruta, at pagkatapos ay tinitiyak na ang gateway endpoint na tinutumbok nito ay nakakaligtas sa rescheduling.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2
Ang susunod na hop ay address ng pod, at gumagalaw ang mga address ng pod. Ituro ang ruta sa VIP ng Service o sa address ng node na nananatili sa lugar, o tanggapin na hahabulin mo ang gateway pagkatapos ng bawat eviction. Ang reverse path filtering ay ang isa pang bitag: ang strict mode ay nagtatapon ng mga packet na ang return path ay hindi tumutugma sa interface kung saan sila dumating, at ito ang eksaktong hugis ng isang preserve na VPN flow.
Ang maluwag na validation ay madalas ang pagkakaiba sa pagitan ng gumaganang return path at mga sagot na nawawala pagkatapos umalis sa backend. Kailangan din ng mga masquerade rule sa node ng VPN na ibukod ang tunnel range, kung hindi ay lalabas ang ipinasang packet na may address ng pod, anuman ang rutang ginawa mo. Mas mainam na ipahayag ang pagbubukod na iyon sa sariling configuration ng CNI kaysa i-edit ang iptables nang manu-mano, dahil muling isinusulat ng agent ang mga chain nito sa restart at ang manu-manong isinulat mong rule ay tumatagal nang eksakto hanggang sa susunod na upgrade.
NetworkPolicy ay access control, hindi routing. Ang paghigpitan ng policy ay hindi kailanman magbabalik ng address na napalitan na ng masquerade.
Magkano ang gastos ng SNAT, at paano ito isusulat
Ang source NAT patungo sa cluster ay ang mas murang disenyo, at hindi ito pagkakamali. Nakikita ng backend ang address ng pod o node ng VPN, nagtutugma ang mga log, at hindi kailangang may return route. Ang nawawala sa iyo ay ang kakayahang makilala ang dalawang kliyente sa network layer, kaya ang mga quota, ban at audit trail ay kailangang manggaling sa ibang lugar.
Kadalasan ang ibang lugar na iyon ay ang aplikasyon: session token, signed header, o PROXY protocol line na isinusulat ng proxy na kontrolado mo. Ang mga ito ay nagbibigay sa tumatanggap ng pagkakakilanlan na maaasahan lamang kapag ang proxy ay nasa landas at ang header ay hindi maitatakda mula sa panig ng kliyente. Maging tahasan sa runbook kung alin ang naaangkop, dahil ipagpapalagay ng susunod na inhinyero na ang address sa log ay ang kliyente. Hindi, at sapat na ang isang insidente para gawing mahal ang pagpapalagay na iyon.
Nananatiling tapat ang palitan hangga't nakasulat ito.
Mga pagsusuri na naghihiwalay ng gumaganang landas sa isang mapalad
Subukan gamit ang sariwang koneksyon kaysa naka-cache, at subukan sa parehong direksyon. Maraming pagkabigo ay mukhang paminsan-minsan lamang dahil ang mga bagong flow ay dumadaan sa na-rewrite na landas.
Hulihin ang tuple sa tatlong punto sa isang awtorisadong kahilingan: kaagad pagkatapos ng decapsulation, sa egress interface ng pod ng VPN, at sa backend. Kung magbabago ang source sa pagitan ng pangalawa at pangatlong huli, nasa ibaba ng pod ang dahilan. Kung magbabago bago ang pangalawa, ang pod mismo ang nagsasalin.
Pagkatapos ay tanggalin ang pod ng VPN at ulitin ang pagsubok habang nire-reschedule ito. Ang preserve na landas na nasisira sa eviction ay hindi tapos, at gayundin ang NAT rule na nakapako sa address na wala na. Sa huli, magpadala ng isang kahilingan mula sa source na inaasahan mong tatanggihan at kumpirmahin na ang pagtanggi ay nagmumula sa policy at hindi sa nawawalang ruta.