ولې د Docker کانټینرونه د VPN د DNS حل کوونکي له پامه غورځوي

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

د یوې ماشین پر سر د حل کوونکي دوه لیدونه

په Linux کې، Docker د جوړېدو پر مهال هر کانټینر ته د کوربه د حل کوونکي ترتیباتو یوه کاپي ورکوي، د loopback پتې فلټروي، او په 127.0.0.11 کې یو دننه DNS سرور چلوي چې پوښتنې بهر لېږي. هغه VPN کلاینټ چې د کانټینر له پیلېدو وروسته /etc/resolv.conf بیا لیکي، د هغه په داخل کې هېڅ نه بدلوي. د کانټینر بیا پیلول یوازې هغه وخت مرسته کوي چې په هغه شیبه کې د کوربه حل کوونکی ناڅاپه سم وي.

په macOS یا Windows کې Docker Desktop یوه طبقه ورزیاتوي، ځکه چې ډیمون په مجازي ماشین کې ژوند کوي. کېدای شي د کوربه VPN حل کوونکی هغه VM ته هېڅکله نه ښکاري، نو بیا پیلول هېڅ نه بدلوي. د حل لارې له ټاکلو مخکې دواړه لیدونه پرتله کړئ: د کوربه د حل کوونکو لیست ترڅنګ docker exec mycontainer cat /etc/resolv.conf۔

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

لار A: د هر کانټینر لپاره د تونل حل کوونکی سپارل

Docker د هر کانټینر لپاره د DNS ترتیبات مني، او دا تر ټولو کوچنی بدلون دی چې کار کوي. لومړی د VPN د حل کوونکي پتې ولولئ: په macOS کې scutil --dns، په Linux کې resolvectl status یا د کلاینټ خپله د وضعیت پایله. بیا کانټینر له هغو سره پیل کړئ، مثلاً docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage۔ په Compose کې هماغه ترتیبات د خدمت لاندې یو لیست دی، چېرې چې دا د چا د shell تاریخچې پر ځای په نسخې کنټرول کې ژوند کوي.

په /etc/docker/daemon.json کې dns لړلیست د هر نوي کانټینر لپاره پلي کېږي، چې ډېر ښکلی ښکاري او نه دی. دا هغه وخت هم پلي کېږي چې تونل بند وي، او بیا یوازې د VPN له لارې د لاسرسي وړ حل کوونکی عادي د عکسونو راکښل خرابوي. د هر کانټینر ترتیبات هم اسانه توجیه کېږي او هم اسانه بېرته اخیستل کېږي.

لار B: پرېږدئ کانټینر د کوربه شبکه شریکه کړي

د کوربه شبکه کاپي په بشپړ ډول څنګ ته اړوي، ځکه کانټینر د کوربه حل کوونکی او د کوربه تونل کاروي. دا هغه شبکه ایز جلاوالی هم لرې کوي چې تاسو یې غوښتل، او د Docker Desktop لاندې یو شان چلند نه کوي. په Linux کې دا د یو ځلي وسیلې لپاره عملي انتخاب دی چې باید داخلي نومونه حل کړي.

د جوړولو لپاره د دواړو لارو هېڅ یوه نه پلي کېږي، ځکه چې د جوړولو ګامونه د چلېدو پر مهال بیرغونه په میراث نه اخلي. چېرې چې پلیټفارم اجازه ورکوي د کوربه شبکې سره جوړ کړئ، یا د انحصارونو نصب په هغه پړاو کې وساتئ چې تونل ته اړتیا نه لري.

هغه څه چې دواړه لارې یې نه سمولای شي

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

د حل کوونکي خپله د سمولو مخکې د Docker شبکې فرعي شبکه د VPN فرعي شبکې سره وګورئ. یو بل ته ننوتل داسې ناکامي پیدا کوي چې په ټینګار سره د خراب DNS سرور په څېر ښکاري.

د کانټینر په داخل کې تایید کړئ

د براوزر یا د ژبې د چلېدو چاپېریال پر ځای د کانټینر په داخل کې د getent hosts db.internal سره ازموینه وکړئ، ځکه هغوی خپله DNS تګلاره او خپل کاش پلي کوي. که getent نوم حل کړ او اپلیکیشن بیا هم ناکام شي، نو حل کوونکی اوس سم دی او پاتې ستونزه د اپلیکیشن په کچه ده. که یې حل نه کړ، نو د DNS ګام بشپړ شوی نه دی.

د DNS ترتیباتو له بدلولو وروسته کانټینر بیا جوړ کړئ. په چلېدونکي کانټینر کې د /etc/resolv.conf سمول له هغه سره ورکېږي او د ترتیباتو ستونزه په هماغه اندازه پټوي چې څوک یې د بیا پیلولو لپاره وخت لګوي.