ولې د macvlan کانټینر نشي کولی VPN پیرودونکي ته ځواب ورکړي

د Linux هوسټ تصور وکړئ چې VPN پای ته رسوي او په هماغه وخت کې په macvlan شبکه کې کانټینر چلوي۔ LAN 192.168.60.0/24 دی، کانټینر 192.168.60.210 لري، او VPN پیرودونکي له 10.95.0.0/24 څخه راځي۔ پیرودونکی خدمت ته رسېږي، ځواب هېڅکله نه راګرځي، او په هوسټ باندې هر فایر وال قاعده سمه ښکاري۔ دا نښه دوه جلا محدودیتونه جوړوي، او د یوې سمول بله په خپل ځای پرېږدي۔

دوه محدودیتونه، یوه نښه

لومړی محدودیت جلاوالی دی: د Docker macvlan ډرایور کانټینر ته اجازه نه ورکوي چې د مورني انټرفېس له لارې له خپل هوسټ سره خبرې وکړي۔ د هوسټ سټک او کانټینر ترمنځ ترافیک هیڅ لاره نه لري، که په هوسټ کې لارې هر ډول ولیکل شي۔

دویم محدودیت د بېرته راستنېدو لار ده۔ د کانټینر اصلي ګیټ وې معمولاً د LAN راوټر دی، نو VPN پیرودونکي ته لېږل شوی ځواب له هماغه راوټر څخه وځي۔ که راوټر VPN حوض ته د بېرته تګ لاره نه لري، ځواب په مینځ کې چېرته غورځول کېږي۔

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

د هوسټ په اړخ کې shim تنګ جوړ کړئ

د هوسټ په سر دویم macvlan انټرفېس چې په پل حالت کې له هماغه مورني سره نښلول شوی وي، هوسټ سټک ته په هغه LAN برخه کې خپله پېژندنه ورکوي۔ د هغه لپاره د DHCP حوض څخه بهر او د کانټینر له حد څخه بهر پته وسپارئ، او یوازې کانټینر د هغه له لارې تېر کړئ۔

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

لومړی حکم انټرفېس په پل حالت کې جوړوي، چې د دې ډرایور لپاره مستنده اصلي حالت دی او هغه حالت چې د هوسټ او کانټینر ترمنځ ترافیک لپاره غواړئ۔ دویم /32 ورکوي ترڅو پته د LAN مخکښې سره ټکر ونه کړي، او څلورم یوازې د کانټینر پته د shim له لارې لېږي۔

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

دا حکمونه په روان هوسټ باندې شبکه تنظیمات بدلوي۔ په وسیله یا مدیریت شوې پلیټ فارم کې د هغه پلیټ فارم ملاتړ شوې ترتیبي طریقه وکاروئ، ځکه په root-shell کې انټرکټیو بدلون ممکن د اپ گریډ وروسته پاتې نشي۔

پرېکړه وکړئ چې سرچینه څنګه ساتل کېږي

کله چې shim په خپل ځای وي، کانټینر هوسټ ته رسېدلی شي، او پوښتنه دا کېږي چې ځواب کومه سرچینه پته لېږي۔ اصلي VPN سرچینه ساتل پاک ماډل دی: کانټینر د پیرودونکي ریښتینې پته ویني، او د خدمت لاګونه او د لاسرسي قاعدې یې کارولی شي۔

د دې لپاره چې کار وکړي، د کانټینر شبکه ترتیب باید دې لارې لپاره د 10.95.0.0/24 ترافیک 192.168.60.250 ته د خپل ګیټ وې په توګه ولېږي۔ دا د کانټینر په خپل ترتیب کې ملاتړ شوې لار یا ګیټ وې تنظیم دی، د هوسټ په اړخ کې چل نه دی۔ د تنظیم د پلي کېدو فرض کولو پرځای یې د کانټینر له داخله تصدیق کړئ۔ هغه اصلي ګیټ وې چې لا هم LAN راوټر ته اشاره کوي، ځوابونه هماغه سوري ته لېږل به دوام وکړي۔

که تصویب شوې طرحه پرځای یې VPN سرچینې پټوي، ژباړه تنګه محدوده کړئ: ریښتینی VPN حوض، shim د وتلو انټرفېس په توګه، او ځانګړی کانټینر او خدمت۔

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

shim د وتلو انټرفېس سره سم کړئ، نه ټنل۔ هغه قاعده چې ټنل د وتلو انټرفېس بولي، د کانټینر په لور تلونکي پاکټ سره سمون نه خوري، او همدا هغه تېروتنه ده چې دا ډول ترتیبات معمولاً لري۔ قاعده تر پورتني جملې پورې تنګه وساتئ او کله چې حوض بدل شي بیا وګورئ۔

له پیرودونکي تصدیق کړئ، د هوسټ نه

د هوسټ له خپله shim پتې ته تړلې غوښتنه ثابتوي چې shim کانټینر ته رسېدلی شي۔ دا نه ثابتوي چې کانټینر کولی شي ترافیک ساتل شوې 10.95.0.x سرچینې ته بېرته ولېږي، ځکه په هغه ازموینه کې سرچینه پته د shim خپله ده۔

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

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

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

ریښتینی اپلیکیشن د ریښتینو اعتبار پاڼو سره وچلوئ، بیا وګورئ چې په هماغه کانټینر باندې دویم، نامتعلق خدمت لا هم تاسو ردوي۔ که د کارولو یوازینۍ لار د هرې فوروارډنګ قاعدې خلاصول وو، نو طرحه بشپړه نه ده۔ همدا راز یاد ولرئ چې خدمت کومه سرچینه پته ثبت کړه، ځکه له دې وروسته به د هغې خپلې د لاسرسي قاعدې هماغه وکاروي۔