د Windows کوربه په یوځای کې د VPN د نښلولو سره سم د اپلیکیشن داخلي نوم حل کېږي، خو د Ubuntu مېلمه په داخل کې نه۔ مېلمه خپلې ریزالور تنظیمات ساتي, او د هغه مخ ته NAT اډاپټر کولای شي DNS پوښتنو ته په دوو بېلو لارو ځواب ووايي۔ مېلمه عامه ریزالور ته اړول وېبپاڼې بیا لوډوي، خو شخصي نومونه مات پاتې کېږي۔ له همدې کبله د ریزالور لاره د هر بدلون دمخه تعقیبېږي۔

د NAT اډاپټر له لارې یوه پوښتنه تعقیب کړئ

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

د ادامه دمخه تایید کړئ چې اډاپټر واقعاً ساده NAT دی۔ د پل اډاپټر، نومول شوي NAT شبکې او د مېلمه په داخل کې دویم VPN کلاینټ هر یو خپل ترتیب او خپله تشریح لري۔ په دې مرحله کې اټکل کول پاتې څیړنه ضایع کوي۔

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

لومړی حکم د اډاپټر حالت او له هغه سره نښلول شوې هرې NAT شبکې ښیي۔ د Ubuntu مېلمه په داخل کې دویم د هرې اړیکې DNS تنظیمات لیستوي، او دریم ډیری وخت یوازې یو ځایي stub پته ښکاره کوي، یعنې ریښتینی upstream بل ځای کې دی۔

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

پروکسي حالت او د کوربه ریزالور حالت بېل میکانېزمونه دي

په پروکسي حالت کې NAT انجن د مېلمه پوښتنې هغو DNS سرورونو ته لیږي چې دمخه یې پېژني۔ د کوربه ریزالور حالت کې هغه پوښتنه نیسي او د کوربه عملیاتي سیسټم ته وایي چې نوم د هغه څه سره حل کړي چې کوربه اوس کاروي۔ یوازې دویم د هغه VPN کلاینټ پیروي کوي چې د تونل د پورته کېدو پر مهال د کوربه حل بیا لیکي۔ له همدې کبله دوه تنظیمات په یوه ماشین کې بېل ځوابونه ورکوي۔

هماغه توپیر په یوه جمله کې ټوله ستونزه ده۔ مېلمه ته د سرور پتو لیست ورکول د Windows ته د دې ویلو سره سم ندي چې نوم د هغه د ترتیب شوي ریزالور له لارې حل کړي، او په ویشل شوي DNS VPN کې دوه ځوابونه توپیر لري۔ د اډاپټر انتخاب د میکانېزم په اړه دی، نه د اجازې۔

هیڅ حالت هم هیڅ شي ته لاسرسی نه ورکوي۔ اجازه د VPN تګلارې او خدمت کې ژوند کوي، او کار کوونکی پوښتنه یوازې دا مانا لري چې نوم پته شو۔

اډاپټر بدل کړئ، بیا وګورئ چې مېلمه څه ترلاسه کوي

لومړی د VM شبکې او DNS تنظیمات ولیکئ، بیا ماشین بند کړئ تر څو تلپاتې ترتیب سم کړئ۔ د work-ubuntu نومي VM لپاره چې لومړی اډاپټر یې NAT لري، د هر اډاپټر انتخاب د VM بند حالت کې له کوربه څخه ټاکل کېږي۔ بیا یې بیا پیل کړئ او د وتلو حالت ته د باور پر ځای پایله وګورئ۔

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

وروستی عدد د اډاپټر شمېره ټاکي، نو دا نړیوال ارزښت نه دی؛ د اډاپټر 2 تنظیم به په هغه ځای کې 2 ولري۔ د نصب شوي VirtualBox نسخې پورې اړوند VBoxManage باینري وکاروئ، ځکه په لاره کې زوړ یو کولای شي هغه تنظیمات ولیکي چې روانه نسخه یې نه مني۔

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

د VPN د ژوند ټول دوره کې ازموینه وکړئ، نه یوازې یو ځل

دواړه پوښتنې په مېلمه کې تکرار کړئ، بیا ریښتینی اپلیکیشن پرانیزئ او اجازه ورکړئ چې TLS کوربه نوم تایید کړي۔ یوازې د IP له مخې د اړیکې ازموینه DNS ښه جلا کوي، خو دا د سند ازموینه نه ده او باید داسې راپور نه شي۔ نوم، پته او د اپلیکیشن پایله یوځای ولیکئ۔

د اجازه شوې کړکۍ په جریان کې د کوربه VPN قطع او بیا ونښلوئ او ازموینه تکرار کړئ۔ پایله باید د لاسرسي تګلارې سره سمه وي، او دا چې عامه حل بیا کار کوي د دې په اړه هیڅ نه وایي چې آیا شخصي پوښتنې پر ټاکل شوې لاره پاتې شوې۔

کله چې د کوربه ریزالور حالت هیڅ نه بدلوي، ثبت شوې ارزښت بېرته کېږدئ او مشاهدې وساتئ۔ هغه VPN کلاینټ چې د hypervisor ترافیک لرې کوي، نه رسېدونکی داخلي ریزالور او ټینګه شوې مېلمه تنظیم هر یو بېل سمون ته اړتیا لري، او اډاپټر پل کول DNS بیا تنظیمولو پر ځای د شبکې ډیزاین بدلوي۔

اړوندې مقالې