په Kubernetes کې OpenVPN پوډ هیڅ نه لیږدوي؟ ip_forward وګورئ

ستاسو لیپ ټاپ شنه تونل ښیي، کلینټ لاګ وایي چې لارې پش شوې، او یوازینی ځواب ورکوونکی پته د VPN سرور خپله تونل IP ده. له هغې وروسته پینګ هر څه چې هدف یې ونیسئ مړ کیږي، که ClusterIP وي، د بل پوډ پته وي یا عامه هوسټ نوم وي. دا ترکیب مبهم نه دی، تشخیصي دی: د کپسول خلاصول کار کوي، او دویم ټوپ نه کوي.

ما دا په یوه Debian نوډ کې ولیدل چې د chart له لارې نصب شوي OpenVPN عکس چلاوه، او تونل اسانه برخه وه. کلینټ د 10.8.0.x کرایه واخیسته، 10.8.0.1 ځواب ورکړ، او 10.96.0.10، د کلسټر DNS خدمت، وخت ختم شو. د سرور لاګ کې هیڅ ناروغ نه ښکاریده، او همدا لامل دی چې خلک د iptables هغه قواعد بیا لیکل پیل کوي چې هغوی ته یې هیڅکله اړتیا نه وه.

VPN پوډ یو روټر دی، او دا سمه ده چې په ساده ډول وویل شي. کوډ شوي پاکټونه راځي، د پوډ په خپل شبکه یي namespace کې خلاصیږي، او بیا باید د بل انټرفیس له لارې ووځي. Linux له دې دویم ګام څخه انکار کوي پرته له دې چې په همدې namespace کې لیږد فعال وي.

کلینټ څه ته رسیدلی شي او څه ته نه

هغه پته چې ځواب ورکوي د تونل د پای نقطې ده، او VPN پروسه یې په سیمه ییز ډول لري، نو لیږد هیڅ ګډون نلري. نور هر څه، په شمول بل پوډ، د خدمت VIP یا انټرنېټ، اړتیا لري چې کرنل پاکټ له tun0 څخه eth0 ته وخوځوي. کله چې دا خوځښت رد شي، نښه یو شان ګونګتیا ده نه رد، ځکه چې هیڅ شی د تونل لاندې بیرته ICMP تېروتنه نه جوړوي. تاسو وخت ختمیدل ترلاسه کوئ، نه د نه رسیدو پیغامونه، او دا هغه نښه ده چې هیڅوک په بشپړ ډول روټ نه کوي.

دوه دقیقې طبقه بندي طبقه تنګوي. که DNS نومونه ناکام شي پداسې حال کې چې د خدمت IP ته خام پینګ بریالي شي، ستونزه په DNS پایپونو کې ده، نه په لیږد کې. که له peer پتې وروسته هر منزل وخت ختم شي، په شمول بربنډ IP، له namespace څخه پیل وکړئ.

په namespace دننه ترتیب ولولئ

هر پوډ خپل شبکه یي namespace اخلي، او net.ipv4.ip_forward د هر namespace لپاره sysctl دی. په نوډ کې یې بدلول د کانټینر په اړه هیڅ نه وایي، او دا د غلط ماشین په سر د ماسپښین تیرولو باوري لاره ده.

kubectl exec -it deploy/openvpn -- sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 0

صفر تشخیص تاییدوي. ارزښت د نوډ د چلولو ترتیب څخه هم په میراث نه رسیږي: هرکله چې کانټینر جوړ شي د عکس له ډیفالټ څخه پیل کیږي. نو په لاس د kubectl exec ... sysctl -w سره تطبیق شوی سمون په راتلونکي بیا پیل کې ورک شي او د یوې نښې په توګه چې کله ناکله ښکاري بیرته راځي.

دا فعالول ترڅو manifest یې وساتي

دوامداره انتخاب یو init کانټینر دی چې په همدې pod sandbox کې چلیږي او ارزښت د VPN کانټینر له پیل مخکې لیکي. په پوډ کې کانټینرونه یو شبکه یي namespace شریکوي، نو ترتیب اصلي کانټینر ته ځي.

initContainers:
- name: enable-forwarding
  image: busybox:1.36
  command: ["sysctl", "-w", "net.ipv4.ip_forward=1"]
  securityContext:
    privileged: true

همدا privileged: true هغه کرښه ده چې بیاکتنې کوونکي پرې اعتراض کوي، او دوی سم دي. sysctl لیکلو ته یا امتیاز یا تنګه وړتیا غواړي، او د محدود Pod Security Standard سره کلسټر کیدای شي په بشپړ ډول د امتیاز لرونکي init کانټینر انکار وکړي. که admission پوډ رد کړي، تاسو د جوړیدو په وخت پوهیږئ، چې لږترلږه صادق او د لوستلو اسان دی.

پاکتر بدیل د پوډ کچې securityContext.sysctls لیست دی، چې kubelet ته اجازه ورکوي namespace یي sysctlونه پرته له دې چې کوم کانټینر ته امتیاز ورکړي پلي کړي. دا یوازې د کلسټر د اجازه لیست نومونه پوښي. net.ipv4.ip_forward په هغه لیست کې دی که نه، د kubelet د ترتیب پورې اړه لري، او هغه پوډ چې له هغې بهر sysctl غواړي په admission کې رد کیږي یا په CreateContainerConfigError کې بند پاتې کیږي ترڅو sandbox بیا هڅه شي. مخکې له دې چې فکر وکړئ ساحه خرابه ده، اجازه لیست وګورئ.

مخکې له دې چې هر یو له دواړو لارو په لاس جوړ کړئ، وګورئ چې chart دمخه سویچ ښیي، ډیری وخت د ipForwardInitContainer: true په څیر یو څه. د chart ارزښت کارول ستاسو override فایل کوچنی ساتي او بل تازه کول ته ودریږي، کوم چې په لاس پیچ شوي Deployment بدلونونه نه کوي.

دویمه نیمه: بیرته راستنیدونکې لار او پالیسي

فعال لیږد اړین دی، کافي نه. که کلینټ داسې شخصي حوض وکاروي چې کلسټر شبکې ته ورته لار نشته، ځوابونه بیرته تونل ته لار نه مومي، او پوډ باید هغه ترافیک خپل منزل ته ماسک کړي.

پالیسي پر دې ناسته ده. NetworkPolicy شیان او د وریځې فایروال قواعد د هغه سرچینې پتې په وړاندې ارزول کیږي چې پاکټ له ژباړې وروسته یې وړي، نو د کلینټ حوض لپاره لیکل شوی قاعده کیدای شي په خاموشۍ سره د ماسک کولو له فعالیدو وروسته سمون بند کړي.

کله چې کلینټ یوازې د کلسټر دننه خدمتونو ته ورسیږي، VPN د خدمت VIP ته پای ته رسول د پوډ شبکې ته د روټ کولو په پرتله کوچنی ډیزاین دی. دا د کلینټ حوض په بشپړ ډول د CNI د روټینګ جدول څخه بهر ساتي.

نیمګړی ټوپ له کلینټ څخه جلا کول

بهر ته کار وکړئ او په لومړي خاموش ګام ودروئ. د VPN peer څخه پیل وکړئ، بیا د یو پوډ پته وآزموئ، بیا د خدمت VIP، او یوازې له هغې وروسته عامه منزل. هر بریالیتوب پوله یو ټوپ خوځوي، او هر ناکامي هغه طبقه نوموي چې د کتلو وړ ده. له هر څخه وروسته exec وکړئ او sysctl بیا ولولئ، ځکه چې بدل شوی پوډ د عکس له ډیفالټ څخه پیل کیږي او هغه سمون چې هیڅکله په manifest کې نه و، دمخه تللی دی.

د Kubernetes اسناد د په کلسټر کې د sysctl کارونې په اړه لیست ورکوي کوم نومونه د پوډ امنیتي شرایطو له لارې ټاکل کیدای شي، او کله چې admission بدلون رد کړي لومړی هماغه ځای ته کتل پکار دي.