ولې GKE پاډونه د VPN له لارې ځایي کوربه ته نه رسیږي

پنګ له نوډ څخه کار کوي او له پاډ څخه ناکام کیږي، او ځایي خوا ته هېڅ نه رسیږي۔ ټنل او لار سم دي؛ په تار کې سرچینې پته نه ده۔ د دې دوو حالتونو توپیر دا دی چې پاکټ د کلستر پرېښودو پر مهال ځان څه بولي، او GKE په دې اړه خپل نظر لري۔ میکانیزم د masquerade استثناوو لیست دی، او د هغه لوستل یوازې یو حکم غواړي۔

له هر څه بدلولو مخکې نافذ لیست ولولئ

GKE یو ایجنټ وړاندې کوي چې د هر منزل حد لپاره پرېکړه کوي چې د پاډ ترافیک به د وتلو پر مهال نوډ پتې ته بیا ولیکل شي که نه۔ د هغه وړاندې شوې ترتیب درې RFC1918 بلاکونه، 10.0.0.0/8, 172.16.0.0/12 او 192.168.0.0/16, د استثنا شوو منزلونو په توګه نوموي۔ نو څه چې له پاډ څخه ځایي 10.x کوربه ته واستوئ، نوډ د پاډ د خپلې پتې سره پرېږدي۔ د نوډ خپل ترافیک بیا نه لیکل کیږي، او همدا لامل دی چې د هغه پنګ کار کوي۔

په پام کې نیول شوی ترتیب او نصب شوي قواعد ولولئ، ځکه چې دوی ممکن سره سمون ونه خوري۔ kubectl -n kube-system get configmap ip-masq-agent -o yaml ښیي چې ایجنټ ته څه وویل شول، او kubectl -n kube-system get pods -l k8s-app=ip-masq-agent ښیي چې د هغه د پلي کولو لپاره څه روان دي۔ په نوډ کې iptables-save | grep -i masq هغه قواعد ښیي چې واقعاً په کرنل کې شته۔ کله چې ConfigMap یوه وایي او قواعد بله، تورن ایجنټ دی نه شبکه۔

د کپچر په مرسته سرچینې پته تایید کړئ

د لیست د بدلولو دمخه کپچر وکړئ۔ په یو منزل فلټر د وتلو معلومات لوستلو وړ ساتي: tcpdump -ni any host 10.20.30.40۔

دا د بلې خوا د راپور سره پرتله کړئ۔ ځایي خوا کې کپچر چې د پاډ پته ښیي او ځواب نه لري، حلقه بندوي: استثنا لیست د ټنل له کومې خرابۍ پرته ناهمغږي تشریح کوي۔ د یوې سرچینې پتې دوه کتنې د CNI په اړه د اټکل کولو د بندولو لپاره بس دي۔

استثنا د پاډ CIDR ته محدوده کړئ

ملاتړې ترمیم استثنا د لیرې کولو پر ځای محدوده کوي: د پاډ CIDR استثنا پرېږدئ او د 10.x ځای پاتې برخه پرېږدئ۔ هغه لیست د ایجنټ په ConfigMap کې nonMasqueradeCIDRs لاندې دی، او د هغه بدلول سمون او بیا خپرول دي۔ پراخه ننوتنه د کلستر ریښتیني پاډ حد سره بدله کړئ، نور شخصي بلاکونه وساتئ که د کلستر دننه ترافیک لا ورته اړتیا لري، او resyncInterval پرېږدئ پرته له دې چې دلیل ولرئ۔ پلي یې کړئ، تایید کړئ چې د ایجنټ پاډونه بیا پیل شوي او تایید کړئ چې د کرنل قواعد بدل شوي۔

دا د ټول کلستر بدلون دی چې ریښتینی اغیز لري۔ د پلي کېدو وروسته، هغه ترافیک چې مخکې خپله پاډ سرچینه ساتله، اوس نوډ ته بیا لیکل شوی رسیږي، نو هر څه چې پر هغو پاډ پتو ولاړ و، بل لېږدونکی ویني۔ قربانیان هغه لاګونه، اجازت لیستونه او ځایي فایر وال قواعد دي چې د پاډ پتې نوموي، او دوی په غلې ډول ناکام کیږي۔ بدلون د ترمیم په توګه نه، بلکې د چلند بدلون په توګه اعلان کړئ۔

په کلستر کې چې څو نوډ پولونه لري، وګورئ چې ایجنټ په هغو نوډونو کې مهالویش شوی چې اغیزمن پاډونه واقعاً پکې ځي۔ پرته له DaemonSet پول خپل پخواني قواعد ساتي، او په ConfigMap کې به هېڅ دا ونه ښیي۔

بدیل او د هغه لګښت

بل انتخاب پاډ پتې نه لمس کوي او لارې ته د هغو په اړه ښوونه کوي۔ د پاډ CIDR د Cloud VPN ترافیک ټاکونکو ته ځي، او ځایي خوا ته د هغه لپاره د بیرته راستنیدو لار ته اړتیا ده تر څو ځوابونه پوه شي چې چېرته لاړ شي۔ دا د پاډ هویت ساتي، چې ځینې امنیتي ماډلونه یې غواړي، او دواړه د لارښوونې او د فایر وال هغه حد پراخوي چې بله خوا باید ومني۔

سودا د لوستلو وړتیا او حد ترمنځ ده۔ ژباړه ځایي خوا ته د هر نوډ لپاره یوه پته ښیي، چې په اجازت لیست کې ایښودل اسان دي او پټوي چې کوم پاډ څه واستول۔ بې ژباړې، د پاډ پته له سره تر سره پاتې کیږي، چې د نسبت لپاره ښه او د نوي حد زده کولو ته اړتیا لرونکي هر وسیله لپاره بد دي۔ دواړه انتخابونه د Docker یا CNI نیمګړتیا نه ده؛ دواړه د لارښوونې پرېکړې دي چې عملیاتي بل لري۔ هغه غوره کړئ چې ستاسو ټیم یې بل تادیه کولی شي، او ولیکئ چې ولې۔

تایید او بیرته اخیستل

هماغه کپچر بیا وچلوئ۔ که ستاسو له سمون وروسته هم د نوډ کچې کپچر د پاډ پته چاپ کړي، نو ConfigMap هر څه ووایي، قواعد هېڅکله نه دي بدل شوي۔ تار حقیقت دی؛ نور هر څه اټکل دی۔

بیا مخالف لوری وګورئ، ځکه چې د دې بدلونونو نیمایي یوازې بهر ته تاییدیږي۔ تایید کړئ چې ځواب هغه نوډ یا پاډ ته رسیږي چې غوښتنه یې لېږلې، او تایید کړئ چې اپلیکیشن بشپړ شو نه یوازې SYN ترلاسه کړ۔ کپچر چې بې ځوابه غوښتنه ښیي، د بلې خوا د لارښوونې ستونزه ده، د دې خوا د masquerade ستونزه نه ده۔

بیرته اخیستل پخوانی ConfigMap دی، په هماغه ډول پلي شوی، په هماغه تایید سره چې ایجنټ بیا پیل شو او قواعد بدل شول۔ په بدلون ریکارډ کې د یوې پېژندل شوې غوښتنې سرچینې پته مخکې او وروسته وساتئ، ځکه چې هماغه یوه کرښه ثابتوي چې بدلون هغه څه وکړل چې تاسو ویلي وو۔ د GKE IP masquerade ایجنټ لارښود ډیفالټ او د ConfigMap ساحې مستندوي۔ که له خپرولو وروسته سرچینې پته نه بدله شي، ایجنټ په هغه نوډ کې نه ځي او هېڅ YAML سمون به یې سم نه کړي۔