د VirtualBox میلمه DNS وروسته له دې چې کوربه VPN ته ووصل شي ماتېږي

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

تایید کړه چې کوم اډاپټر حالت ډیبګ کوې

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

یوه مجازي ماشین کولی شي په بېلو حالتونو کې دوه اډاپټرونه ولري، او اغېزمن شوی تل لومړی نه وي۔

همدا راز تایید کړه چې کوربه نوم اصلاً حل کوي۔ هماغه اپلیکیشن په کوربه کې د تونل سره پرانیزه، او هماغه بشپړ نوم وکاروه چې میلمه به یې کاروي۔ که کوربه هم ناکام شي، تور میلمې ته نه دی او د مجازي شبکې هېڅ بدلون به یې ترمیم نه کړي۔

یو نوم د میلمې د حل کوونکي له لارې تعقیب کړه

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

د میلمې دننه وګوره چې حل کوونکی واقعاً د څه لپاره تنظیم شوی۔ په Ubuntu میلمه کې چې systemd-resolved چلوي، د هرې اړیکې حالت هغه سرورونه ښیي چې راغلي، او د resolv.conf فایل کېدای شي یوازې یو stub پته ولري، چې سمه ده نه شکمنه۔ په لاس سمونل شوی فایل یا جلا کوډ شوی DNS کلاینټ کولی شي پوښتنې بشپړ بل ځای ته ولېږي۔ د بدلون دمخه هغه څه ولیکه چې وموندل شول۔

resolvectl status
resolvectl query app.internal.example

دلته حل له رسېدونکيتیا جلا کړه۔ هغه پته چې رارسي خو خدمت لا هم نه رسیږي، د لارښوونې یا تګلارې پوښتنه ده نه د DNS۔

هماغه اډاپټر کې د کوربه د حل کوونکي حالت وآزمویه

د VirtualBox د NAT DNS انتخابونه بېلابېل میکانېزمونه تشرېح کوي، او توپیر هغه وخت مهم کېږي چې د کوربه خپل حل کوونکی د تونل سره بدل شي۔ DNS پراکسي د میلمې غوښتنې هغو سرورونو ته لېږي چې ورته ورکړل شوي۔ د کوربه د حل کوونکي حالت غوښتنې نیسي او د کوربه DNS API بولي، او دا هغه حالت دی چې د VPN کلاینټ لخوا بیا تنظیم شوی Windows حل کوونکی تعقیبوي۔

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

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

د مجازي ماشین اوسني تنظیمات ولیکه، ګړندی یې کړه او هغه اډاپټر په نښه کړه چې مخکې دې تایید کړی و۔ په انتخاب کې وروستی عدد ثابت نه دی بلکې د اډاپټر شمېره ده، نو هغه ماشین ته چې اغېزمن اډاپټر یې دوهم دی تطبیقول یې غږ نه لرونکې بې اغېزې کړنه ده۔ میلمه پیل کړه او هغه حل کوونکي ترتیب وګوره چې واقعاً یې ترلاسه کړی، ځکه چې په میلمه کې لاسي تنظیم هر هغه څه ته ماتې ورکوي چې د NAT پوښ وړاندې کوي۔ په یاد ولره چې د کوربه د حل کوونکي حالت دا هم انګېري چې د کوربه خپله DNS لاره هغه ده چې شریکول دې غوښتل۔

هماغه ازموینې د VPN د بیا نښلولو په اوږدو کې تکرار کړه

په میلمه کې دواړه پوښتنې تکرار کړه، بیا ریښتینی اپلیکیشن پرانیزه او پرېږده چې سند پخپله تایید کړي۔ یوازې د پتې پر بنسټ ازموینه د نوم حل جلا کولو لپاره ګټوره ده او د کار کوونکي TLS ناستې سره برابر نه ده، نو په ping مه ودروېږه۔ بیا په تصویب شوې موده کې د کوربه تونل قطع او بیا وصل کړه او یو ځل نور تکرار کړه۔ هغه چلند چې یوازې له پیل وروسته لومړنۍ اړیکه کې پاتې کېږي، د ژوند دورې ستونزه ده چې راپور ورکړل شي، نه د DNS راز چې بل حل کوونکی ورسره تعقیب شي۔

د عامه حل کار کول دا نه ثابتوي چې شخصي پوښتنې په هغه لار کې پاتې شوې چې ستا تګلاره غواړي۔

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