Dev کانټینر یوازې VPN ته د لاسرسي وړ کوربه ته نه رسیږي: چیرته وګورو

شخصي API ستاسو په ډیسکټاپ براوزر کې خلاصیږي او په پراختیایي کانټینر کې ناکامه کیږي. دا هېڅ تضاد نه دی، او په نادره توګه پخپله VPN لامل وي. د براوزر غوښتنه او ناکامه غوښتنه جلا پروسو جوړې کړې وې، د جلا resolver، proxy او لارو سره، او ډېری وختونه له بشپړ جلا شبکې نومونو ځایونو څخه. «زما په لپ ټاپ کې» کېدای شي Windows کوربه، یو WSL وېش، د Docker Desktop مجازي ماشین او د هغې VM دننه کانټینر مانا ولري — څلور شرایط چې هر یو یې یو شان کوربه نوم ته جلا ځواب ورکولی شي. مخکې له دې چې یو تنظیم ته لاس ووهئ، ومومئ چې ناکامه پروسه کوم کاروي.

د تنظیم له بدلولو مخکې پروسه ومومئ

له VPN کلاینټ نه، بلکې د کانټینر انجن څخه پیل وکړئ. وپوښتئ چې کمانډ لاین له کوم شرایطو سره خبرې کوي او هغه انجن په کوم عملیاتي سیستم کار کوي، ځکه چې د ډیسکټاپ VM لخوا اداره شوی Linux کانټینر له هغه څخه جلا لار اخلي چې محلي ډیمون یې اداره کوي:

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

په Windows کې، wsl -l -v وایي چې وېش د WSL 2 لاندې روان دی که نه، کوم چې هغه د خپل مجازي سویچ شاته ږدي. همدا جزئیات فیصله کوي چې کانټینر د کوربه د لارښوونې جدول شریکوي که د NAT شاته ناست دی چې کوربه ته د رسېدو لپاره مخته لېږل شوی پورټ یا کوربه نوم ته اړتیا لري.

یوه غوښتنه ثابته وساتئ او پرتله وکړئ

په شخصي کوربه کې یو بې ضرره پای ټکی وټاکئ او د هرې پرتلې لپاره یې وکاروئ: له براوزر، د کوربه له ټرمینل، له WSL وېش او د کانټینر له دننه. د هر هڅې لپاره څلور شیان ولیکئ: حل شوی پته، چې proxy وکارول شو که نه، د ناکامۍ ډول او تېر شوی وخت. د نوم پلټنه، د اړیکې جوړول، TLS تصدیق او HTTP حالت څلور جلا ستونزې دي، او د دوی «کار نه کوي» کې ګډول یوه سهار ضایع کوي.

پرته د ناکامه کانټینر له دننه، د وخت محدودیت سره ترسره کړئ، تر څو یو خاموش فایر وال ټرمینل د دقیقو لپاره ونه نیسي. نوی کانټینر د انجن شبکه یي شرایط بیا تولیدوي، خو د اپلیکیشن کانټینر نومونه ځای، proxy متغیرونه یا resolver نه، نو په ریښتیني کانټینر کې docker exec کول هغه معتبره ازموینه ده، او څنګ کانټینر یوازې د دې جلا کولو لاره ده چې توپیر په انجن کې دی که په کانټینر کې:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

alpine بنسټیز عکس busybox لري او curl نه لري، او همدا ډول جزئیات کاپي شوې تشخیصي بلاک ناکاموي: د کلاینټ سره عکس وټاکئ، یا یې په هماغه چلند کې اضافه کړئ. له بې اړیکې عامه سایټونو سره پرتله هېڅ جلا نه کوي. که له کانټینر څخه https://example.com کار وکړ، یوازې دې ته پوه شوئ چې کانټینر انټرنیټ ته لاسرسی لري، او دې ته نه چې آیا له تونل څخه شخصي پتې ته رسیږي. همدارنګه، نوی ټرمینل خلاصول یوازې دا ثابتوي چې نوی ټرمینل کار کوي، نه دا چې له ناکامه اپلیکیشن سره یو ګډ چلند محیط لري.

Docker Desktop کولای شي له VPN سره کار وکړي

د Docker خپل د VPN او کوربه اړیکې په اړه اسناد دا د ملاتړ شوي ترتیب په توګه بیانوي، او صادقانه لنډیز دا دی چې دا کار کوي، نه دا چې په اتوماتيک ډول مات دی. مه فکر کوئ چې ډیسکټاپ VM په ډیزاین سره د کوربه تونل ته څنګه اوړي؛ په ډېرو ترتیباتو کې ترافیک په سمه توګه د کوربه تونل تعقیبوي، او همدا لامل دی چې «Docker VPN ته پام نه کوي» افسانه باوري او غلط مشورې تولیدوي.

لا هم مهم دا دی چې کوم backend کارول کیږي، د کلاینټ split-tunnel تګلاره او هغه resolver ترتیب چې VM ترلاسه کړی. هغه VPN کلاینټ چې لارې نصبوي خو DNS نه، یا هغه DNS سرور ټېل وهی چې VM ورته نه رسیږي، د کانټینر دننه د نوم پلټنې ناکامي رامنځته کوي، په داسې حال کې چې کوربه کار کوي ځکه چې اضافي resolver یا کیش شوی ځواب لري. دا په کانټینر کې د resolver ستونزه ده. دا ستونزه ستاسو هر VPN بیاځلي اړیکه زغملې شي، ځکه چې تونل لا دمخه هغه ترافیک وړي چې تاسو غوښتی و.

پته اوورلیپ او MTU جلا ناکامۍ دي

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

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

دوهمه د MTU ستونزه ده. که اړیکه جوړه شي او TLS بشپړ شي خو لوی ځوابونه ودریږي، تاسو د بسته اندازې ستونزه لرئ، نه د اجازې، او د DNS ریکارډونو بدلول به یې هېڅکله سم نه کړي. مخکې له دې چې څه بدل کړئ، په کوچنۍ او لویه غوښتنه ازموینه وکړئ او دواړه پایلې ولیکئ.

د اوورلیپ حل بله کانټینر فرعي شبکه یا محدوده لار ده چې د پتې پلان خاوند یې غوره کوي. د MTU د بندېدو حل د تونل یا انټرفیس MTU د هغه ارزښت پورې ټینګول یا کمول دي چې په لار کې پاتې کیږي، او په هغه پوړ کې تطبیق شي چې تاسو یې کنټرولوئ.

Proxy ترتیب د ماشین نه، د پروسې پورې اړه لري

د کانټینر دننه، localhost د هماغه کانټینر خپل شبکه یي شرایط نوموي، نو هغه proxy چې په کوربه کار کوي هلته په دې نوم نه رسیږي. Docker Desktop د کوربه لاسرسي لپاره host.docker.internal برابروي، او په Linux کې تاسو هغه په ښکاره ډول د --add-host=host.docker.internal:host-gateway سره اضافه کوئ. په هر حال، هغه نوم تاسو ته کوربه ته لار درکوي؛ دا د proxy خدمت نه جوړوي او نه تاسو ته د هغې کارولو اجازه درکوي.

د ریښتیني چاپیریال لپاره ورکړل شوې proxy پته او پورټ وکاروئ، او وګورئ چې څوک یې لولي. په متقابل شیل کې صادر شوي متغیرونه په اتوماتيک ډول هر ایډیټر غځونې، ژبې سرور، جوړونې وسیلې او شالید ډیمون ته ترتیب نه ورکوي. مهمه هغه پروسه ده چې ناکامه غوښتنه یې کړې، نو د هغې چاپیریال وګورئ، نه د خپل ټرمینل.

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