په Kubernetes کې د VPN کلاينټ IP: ساتل یې یا SNAT کول؟
په Kubernetes کې د VPN کلاينټ ریښتیني پتې او د سرچینې NAT ترمنځ د درې شرطونو پر بنسټ غوره کړئ، بیا د بېرته راستنېدو لاره او د pod بدلون وګورئ.
د تونل او backend ترمنځ یو ځای کې د کلاينټ پته یا ژوندې پاتې کېږي یا بدلېږي، او دواړه پایلې د دفاع وړ دي. غوره کول د ترلاسه کوونکې خدمت مالک ته اړه لري، نه هغه چا ته چې CNI نصب کړی. کله چې د هر کلاينټ اجازه، کوټې یا د پلټنې ثبتونه مهم وي، پته باید هر ګام ته ورسېږي. کله چې ګډ انتساب د منلو وړ وي، د سرچینې NAT هغه د لارښوونې ستونزه لرې کوي چې که نه وي تل ساتلې.
چېرې چې د کلاينټ پته واقعاً ورکېږي
د لرې کلاينټ بنډل د VPN pod ته د تونل سیمې دننه داخلي سرچینې سره رارسېږي، ووایو 10.90.0.42. کله چې pod دا بنډل د ClusterIP یا د pod IP په لوري ورپسې لېږي، درې بېل میکانېزمونه کولای شي سرچینه بیا ولیکي. د نوډ CNI masquerade قاعده هغه ترافیک پوښي چې pod د کلسټر CIDR څخه بهر لېږي. د منزل نوډ پر kube-proxy conntrack ننوتنه پخپله د Service ګام پوښي. هغه پراکسي چې اړیکه پای ته رسوي بنډل هېڅ نه لېږي، نو هغه سرچینه چې په پای کې یې وینئ د پراکسي ده.
هر یو په بېله طبقه کې ژوند کوي، نو ځکه یو Service ساحه تقریباً هېڅکله ټوله لاره نه سمېږي.
د VPN عامه Service پر externalTrafficPolicy یوازې د بهرنۍ اړیکې په اړه پرېکړه کوي: Local لرې پته په هغه نوډ کې ساتي چې ترلاسه کړې یې ده، په داسې حال کې چې Cluster kube-proxy ته اجازه ورکوي چې بنډل بل نوډ ته وسپاري او هلته masquerade وکړي. هغه ترتیب هغه اورېدونکی کنټرولوي چې ستاسو کلاينټان ورته نښلېږي. دا د هغه ډيکريپټ شوي بنډل په اړه هېڅ نه وایي چې ستاسو VPN بهیر وروسته کلسټر ته لېږي.
درې شرطونه چې بحث فیصله کوي
زه هره ورځ چې دا راپاڅي هماغه درې پوښتنې په هماغه ترتیب پوښتم، ځکه لومړۍ معمولاً بحث پای ته رسوي. دوی ته د مشخص کاري بار لپاره ځواب ووایاست، نه د ټول کلسټر لپاره. په یو شرکت کې دوه کلسټرونه کولای شي بېلو ځوابونو ته ورسېږي او دواړه سم وي.
| 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 |
که backend لومړنۍ پوښتنې ته هو او دویمې ته نه ووایي، تاسو شبکه یی کار لرئ نه د manifest سمون. که درېیمه کرښه پراکسي ووایي، پته هېڅکله نه ژوندې پاتې کېدله، او د هغې خلاف ادعا یوه اونۍ د بنډلونو نیول لګښت لري.
preserve حالت له شبکې څه غواړي
د سرچینې ساتل یعنې منزل نوډ باید ترافیک د فعال VPN لارښوونکي له لارې 10.90.0.42 ته بېرته ولېږي. د VPN حوض د کلسټر CIDR نه دی، نو هېڅ CNI یې ستاسو لپاره په ډیفالټ ډول نه لارښوونکي کوي. تاسو پخپله لاره ورزیاته کړئ، بیا ډاډ ترلاسه کړئ چې د لارښوونکي هغه پای ټکی چې دا ورته اشاره کوي د بیا مهالوېش څخه ژغورل کېږي.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2هغه راتلونکی ګام د pod پته ده، او د pod پتې خوځېږي. لاره د Service VIP یا د نوډ هغې پتې ته وګرځوئ چې ځای پر ځای پاتې کېږي، یا ومنئ چې له هر اېستلو وروسته به لارښوونکي پسې منډې وهئ. د بېرته راستنېدو لارې فلټرول بله تله ده: سخت حالت هغه بنډلونه غورځوي چې د بېرته راستنېدو لاره یې له هغه انټرفېس سره نه ځانګړي کېږي چې پرې راغلي، او دا په سمه توګه د ساتل شوي VPN بهیر شکل دی.
نرمه تصدیقېدنه ډېری وخت د کار کوونکې بېرته راستنېدو لارې او هغو ځوابونو ترمنځ توپیر دی چې له backend څخه له وتلو وروسته ورکېږي۔ د VPN نوډ پر masquerade قواعدو هم باید د تونل سیمه واستوي، که نه لېږل شوی بنډل د pod پتې سره وځي، که هر لاره مو جوړه کړې وي. غوره دا ده چې دا استثنا په خپله د CNI ترتیباتو کې څرګنده کړئ نه دا چې iptables په لاس سم کړئ، ځکه اجنټ د بیا پیل په وخت خپلې زنځیرونه بیا لیکي او ستاسو په لاس لیکل شوې قاعده دقیقاً تر راتلونکي اپګریډ پورې پاتې کېږي.
NetworkPolicy د لاسرسي کنټرول دی، نه لارښوونه. د یوې پالیسۍ سختول هېڅکله هغه پته نه بحالوي چې masquerade لا دمخه بدله کړې ده.
SNAT څه لګښت لري، او دا څنګه ولیکو
کلسټر ته د سرچینې NAT ارزانه ډیزاین دی، او دا تېروتنه نه ده. backend د VPN pod یا نوډ پته ویني، ثبتونه سره سمون لري، او اړینه نه ده چې د بېرته راستنېدو لاره موجوده وي. هغه څه چې له لاسه ورکوئ د شبکې په کچه د دوو کلاينټانو توپیر دی، نو کوټې، بندیزونه او د پلټنې نښې باید له بل ځای څخه راشي.
معمولاً هغه بل ځای غوښتنلیک دی: د غونډې ټوکن، لاسلیک شوی سرلیک یا د PROXY پروتوکول کرښه چې ستاسو تر کنټرول لاندې پراکسي لیکي. دا ترلاسه کوونکي ته هغه هویت ورکوي چې یوازې هغه وخت پرې باور کولای شي چې پراکسي په لار کې وي او سرلیک د کلاينټ له خوا نه شي ټاکل کېدای. په runbook کې روښانه کړئ کومه یې پلي کېږي، ځکه راتلونکی انجینر به فرض کړي چې په ثبت کې پته کلاينټ دی. داسې نه ده، او یوه پېښه بس ده چې دا فرض ګران کړي.
تبادله تر هغه پورې رښتینې پاتې کېږي چې لیکل شوې وي.
هغه کتنې چې کار کوونکې لاره له بختورې لارې بېلوي
له تازه اړیکې سره وآزمایئ نه له کیش شوې سره، او په دواړو لورو وآزمایئ. څو نیمګړتیاوې یوازې ځکه وقفه یي ښکاري چې نوي بهیرونه بیا لیکل شوې لاره اخلي.
د یوې اجازه لرونکې غوښتنې پر مهال tuple په درې نقطو کې ونیسئ: سمدلاسه له ډيکريپشن وروسته، د VPN pod په وتلو انټرفېس او پر backend. که سرچینه د دویم او درېیم نیول ترمنځ بدله شي، لامل له pod څخه لاندې دی. که له دویم دمخه بدله شي، pod پخپله ژباړي.
بیا VPN pod حذف کړئ او ازموینه هغه وخت تکرار کړئ چې بیا مهالوېش کېږي. ساتل شوې لاره چې پر اېستلو ماتېږي نیمګړې ده، او هغه NAT قاعده هم چې له نور شتون نلرونکې پتې سره تړلې وي. په پای کې له هغې سرچینې یوه غوښتنه ولېږئ چې د ردېدو تمه یې لرئ او تایید کړئ چې رد له پالیسۍ راځي نه له ورکې لارې.