ولې د Docker کانټینر د VPN شاته کوربه ته نه رسیږي

هغه کانټینر چې د شرکت VPN شاته هيڅ شي ته نه رسیږي، معمولاً د تونل په پرتله په بل شبکه نومځای کې اوسیږي۔ د کوربه کلاینټ لارې، DNS سرورونه او د اورپنې نښې د کوربه سټیک پورې اړه لري؛ د پل شبکې کانټینر خپل سټیک لري۔ همدا یوه حقیقت د پلیټفارم ټیم ته رسیدونکي ډیر رپوټونه تشریح کوي، او همدا لامل دی چې «VPN خراب دی» او «Docker د VPN څخه تیرږي» دواړه یو ځای غلط کیدای شي۔ د یوې نښې شاته دوه بشپړ مختلف ترتیبات پټ دي، نو د هر تنظیم د بدلولو دمخه معلومه کړئ چې کوم یې لرئ۔

ومومئ چې تونل د چا نومځای دی

د macOS یا Windows لپاره Docker Desktop کې کانټینرونه د Linux مجازي ماشین دننه چلیږي۔ په ډیسکټاپ نصب شوی VPN کلاینټ د ډیسکټاپ عملیاتي سیسټم کې تونل جوړوي، او مجازي ماشین هغه هیڅکله نه ویني۔ هیڅ کانټینر ترتیبات دا نه سمولي، ځکه چې هغه انټرفیس چې کانټینر ته یې اړتیا وي په بشپړه توګه د هغه په شبکه نومځای کې نشته۔

په Linux کوربه کې تونل د کوربه نومځای کې اوسیږي، او د پل کانټینرونه معمولاً د وتلو پر مهال د سرچینې NAT په تطبیق سره د کوربه د لارښوونې جدول له لارې هغه ته رسیږي۔ کله چې دا لار ناکامه شي، لامل معمولاً نه ورک لار ده، بلکې د لیږد پالیسي، د بیرته لار فلټر کول یا یو له بل سره تیت سبنیټ دی۔ د نور لوستلو دمخه تایید کړئ چې په کوم یو له دوو نړیو کې یاست:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

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

د کوربه شبکه ازموینه ده، ډیزاین نه

کانټینر د کوربه شبکې سره چلول، کوم چې Docker د کوربه شبکه نومځای شریکولو په توګه مستند کوي، هغه ته د تونل انټرفیس او د هغه لارې مستقیم میراث ورکوي۔ که هماغه غوښتنه بیا بریالۍ شي، د لارې تیوري تاییدیږي او ناکامي د نومځای جلاوالی دی، نه اعتبارنامې، DNS یا د لاسرسي قاعده۔

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

دا د تشخیص په توګه وساتئ۔ د کوربه شبکه د پورټ خپرولو او هغه جلاوالي څخه چې تاسو یې له کانټینر څخه غوښتي وو ډیره برخه پریږدي، او په Docker Desktop کې «host» مجازي ماشین ته وایي، نه ډیسکټاپ ته، نو هلته بریا یا ناکامي کیدای شي تاسو ګمراه کړي که هیر کړئ چې کوم کوربه ته یې مخ وړاندې کړی و۔

tun وسیله او هغه امتیازونه چې ورسره راځي

د کانټینر دننه VPN کلاینټ ته د تونل وسیلې او د هغې د تنظیم اجازې ته اړتیا ده۔ عام لنډه لار --privileged ده، چې هر وسیله ورکوي او په ټول کانټینر کې د امنیت پالیسي نرموي۔ دا د دې کار له اړتیا څخه ډیر څه دي، او په بیاکتنه کې یې توجیه کول ستونزمن دي۔

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

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

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

د پل NAT هغه سرچینه بدلوي چې VPN یې ویني

د اصلي پل سره د کانټینر وتونکی ترافیک د کوربه پتې ته ژباړل کیږي۔ له همدې امله د VPN شاته شرکت اړخ د کانټینر نه، بلکې د کوربه د تونل پته ویني، د سرچینې له مخې د لاسرسي قواعد داسې چلند کوي لکه غوښتنه چې کوربه لیږلې وي، او دوه کانټینرونه د VPN سرور لپاره نه جلا کیدونکي کیږي۔

macvlan یا ipvlan پرځای کانټینر ته LAN پته ورکوي، کوم چې په LAN کې موندلو کې مرسته کوي او کانټینر په برخه کې برابر ښکاري۔ دا د کوربه تونل هم په بشپړه توګه تیروي، نو داسې کانټینر یوازې-VPN مخکیني ته نه رسیږي پرته له دې چې VPN له هماغه LAN څخه هم لاسرسي وړ وي۔

دواړه بڼې قانوني دي؛ دوی مختلفو اړتیاوو ته ځواب وایي۔ که اړتیا دا وي چې «دا کانټینر باید یوازې-VPN خدمت ته ورسیږي»، تاسو د کوربه له لارې لارښوونه او د کانټینر دننه د تونل پای ته رسولو ترمنځ انتخاب کوئ۔ دا انتخاب د ځای پرځای کولو دمخه ولیکئ، نه د لومړنۍ ناکامه غوښتنې وروسته۔ هر څه چې غوره کړئ، هغه سرچینه پته ثبت کړئ چې لرې پای به یې ویني، ځکه چې د هغه د لاسرسي قواعد او لاګونه به همدا ښیي۔ هغه ډیزاین چې دا پته نه شي ویلای، بشپړ نه دی۔

DNS د ډیمون پیروي کوي، نه د تونل

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

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

همدا منطق د وتلو پتې پوښتنې ته هم تطبیقیږي۔ که هر کانټینر باید له بل VPN پتې څخه ښکاره شي، یو کوربه تونل نشي کولی دا برابر کړي ځکه چې NAT دوی په یوه سرچینه کې غونډوي۔ د کار وړ بڼې د هر کانټینر په نومځای کې کلاینټ یا هغه sidecar چې تونل لري او خپل سټیک شریکوي دي، او دواړه هغه څه بدلوي چې اپلیکیشن ته څنګه پته ورکول کیږي۔

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