ایا VPN زما DNS بدل کړ؟ مخکې او وروسته پرتله کړئ
یو پروفایل کولی شي ستاسو پوښتنې په قصد سره ځای په ځای کړي۔ د VPN له نښلولو مخکې او وروسته د حل کوونکي تګلاره او ریښتینې ځواب پرتله کړئ، یو متغیر ثابت ساتل۔
تاسو تونل نښلوئ، یو خصوصي ډشبورډ پرانیزئ، او نوم هغه پتې ته حل کیږي چې تاسو هیڅکله نه دي لیدلي۔ یا برعکس پیښیږي: براوزر کار کوي خو د کمانډ کرښې وسیله ناڅاپه هیڅ نه حل کوي۔ دواړه پایلې له یوې بدلون څخه راځي، او خلک معمولاً دا د VPN په اړه په یوه جمله تشریح کوي چې "خپل DNS کاروي"، کوم چې د خرابیو موندلو یا تایید لپاره کافي دقیق نه دی۔ په هغې جملې کې دوه پوښتنې پټې دي: دا پروفایل باید کومې پوښتنې پخپله واخلي، او ایا ستاسو ماشین هغوی ریښتیني هغه حل کوونکي ته ولېږلې چې ورته ورکړل شوی و؟ دوی جلا ساتل ټوله طریقه ده، ځکه چې دوی ګډونکی ازموینه په دواړو لورو کې باوري غلط ځواب ورکوي۔
ولې یو پروفایل په اصل کې حل کوونکی ورکوي
د تونل په داخل کې، د لرې پای شاته نومونه معمولاً هغو پتو ته حل کیږي چې یوازې په هغه شبکه کې شته۔ لکه corp.internal ډوله خصوصي زون عمومي استازیتوب نه لري، نو هغه حل کوونکی چې ځواب ورکوي باید د تونل له داخله د لاسرسي وړ وي۔ هماغه میکانیزم دویم هدف هم پوره کوي: کله چې پوښتنې بل ډول ستاسو د ISP له لارې بهر ووځي، د لرې اړخ حل کوونکی پوښتنه د کوډ شوې لارې دننه ساتي۔ له همدې امله د DNS سرور پته د اړیکې د تګلارې برخې په توګه راځي، نه د ماشین لپاره یو ځل ټاکل شوې نړیوالې تنظیم په توګه۔
پته پخپله هیڅ نه فیصله کوي۔ حل کوونکی یوازې هغه وخت ځواب ورکولی شي چې ورته لار موجوده وي، او تر ټولو عامه خرابي هغه حل کوونکی دی چې یوازې د تونل پورته والی پر مهال د لاسرسي وړ وي۔ کله چې تونل ولوېږي او تګلاره پاتې شي، پوښتنې بې لارې پتې ته ځي، او نښه پاکه تېروتنه نه بلکې د وخت پای ته رسیدل دي۔ دا توپیر مهم دی کله چې بل ازموینه پایله لولئ، ځکه چې د وخت پای ته رسیدل خلک هغو ټرانسپورټ تنظیماتو ته لیږي چې هیڅکله ښکېل نه وو۔
د ځوابونو پرتله کولو دمخه دوه ډیزاینونه پرتله کړئ
بشپړ تونل او ویشل شوی DNS مخالف توقعات جوړوي، او هیڅ یو یې خرابي نه ده۔ د بشپړ تونل لاندې هره پوښتنه کولی شي چمتوکوونکي یا شرکتي حل کوونکي ته لاړه شي، نو د نښلولو وروسته د عامو نومونو توپیر لرونکی ځواب طبیعي دی۔ د ویشل شوي DNS لاندې یوازې لیست شوي ډومینونه خصوصي حل کوونکي ته ځي او پاتې نور محلي پاتې کیږي؛ په Windows کې د ډومین لیست Name Resolution Policy Table کې، په macOS کې د DNS تنظیماتو سمون لرونکو ډومینونو کې، او په systemd-resolved کوربه کې د هرې اړیکې د لارښودنې ډومینونو کې وي۔
همدا لومړی کول باید د پرتلې وړ ده، ځکه چې دا فیصله کوي چې کوم شی خرابي وشمېرل شي۔ د ویشل شوي DNS سره، هغه عام نوم چې د نوي حل کوونکي نه ځواب ورکوي د څیړنې وړ دی، خو هغه داخلي نوم چې سم ځواب ورکوي سیستم خپله دنده ترسره کوي۔ د بشپړ تونل سره، بې نظمي هغه عام نوم دی چې لا هم ستاسو د ISP حل کوونکي نه ځواب ورکوي۔ د Microsoft د VPN نومونو حل په اړه لاسوند د دې قاعدو Windows ترتیب بیانوي، په شمول دا چې څنګه سمون لرونکی تګلاره ننوتنه د اډاپټر خپلو سرورونو دمخه وګړل شي۔
په کوټه کې دریم حل کوونکی هم شته چې هیرول اسانه دي۔ د براوزر خوندي DNS پخپله نومونه حل کوي او کولی شي د تونل لخوا د عملیاتي سیستم تګلارې بدلولو وروسته هم ځواب ورکول ته دوام ورکړي، نو هغه پاڼه چې پورته کیږي دا ثابتوي چې د براوزر حل کوونکی کار کړی، نه دا چې پروفایل پلي شوی۔ که تاسو یوازې هغه څه پرتله کوئ چې براوزر ښیي، نیم وخت تاسو غلط پوړ ازموئ۔
یوازې د یو متغیر سره بنسټیزه کرښه ثبت کړئ
تونل بدل کړئ۔ په ورته ګام کې نوم، وسیله یا د لټون پسوند هم مه بدلوئ۔ هغه نوم وټاکئ چې د پوښتنې اجازه لرئ، ولیکئ کومه اپلیکیشن مو کارولې، او یا بیرته راغلې پته یا دقیقه تېروتنه ولیکئ۔ په Windows کې Get-DnsClientServerAddress -AddressFamily IPv4 د هر اډاپټر سرورونه چاپوي او Get-DnsClientNrptPolicy د تګلارې ننوتنې چاپوي؛ systemd-resolved سره په Linux کې resolvectl status د هرې اړیکې DNS سرورونه او لارښودنې ډومینونه ښیي؛ په macOS کې scutil --dns هغه حل کوونکو ترتیب چاپوي چې سیستم به ریښتیا تعقیب کړي۔
بیا د کلاینټ عادي کنټرولونو له لارې ونښلوئ او هماغه حکمونه په سمه توګه تکرار کړئ۔ لومړی تولید وساتئ نه هغه په یاد، ځکه چې پرتله کول ټول اصل دی او د کیش خالي کولو وروسته دویم لوستل لا دمخه بله اندازه ده۔ که بنسټیزه کرښه د براوزر مخکې کېدو سره اخیستل شوې وه او د نښلولو وروسته چلند په ټرمینل کې کیږي، تاسو دوه حل کوونکي پرتله کوئ، نه د یو حل کوونکي دوه حالتونه۔
روښانه پوښتنه او د اپلیکیشن لټون دوه بېلې ازموینې دي
یو ځانګړي سرور ته پوښتنه، د nslookup name 10.20.0.1 یا dig @10.20.0.1 name سره، یوازې یوه خبره ثابتوي: هغه سرور چې نوم یې واخلئ کله چې ورته ورسیږئ ځواب ورکوي۔ دا د ټاکلو منطق په بشپړه توګه پرېږدي، نو نشي ویلای چې سیستم به دې نوم لپاره هغه سرور ټاکلی و که نه۔ دا د دې لپاره وکاروئ چې ګمارل شوی حل کوونکی د لاسرسي وړ دی که نه، او د تګلارې ازموینې لپاره یې مه کاروئ۔
د محلي حل کوونکي له لارې لټون ټاکل ریښتیا عملي کوي۔ resolvectl query name هماغه لارښودنې ډومین قاعدې تیریږي او راپور ورکوي چې کوم پروتوکول ځواب ورکړ، Resolve-DnsName په Windows کې د تګلارې جدول او د کلاینټ کیش څخه تیریږي، او scutil --dns هغه ترتیب ښیي چې لټون به یې تعقیب کړي۔ دواړه ډولونه وچلوئ او په خپلو یادښتونو کې جلا کالمونو کې یې وساتئ۔ د بریالۍ روښانې پوښتنې ترڅنګ ناکامه اپلیکیشن لټون د لارښودنې یا ټاکلو ستونزه ده، نه هغه حل کوونکی چې کار کولو ته انکار کوي۔
کیش ستاسو او ځواب ترمنځ ولاړ دی۔ عملیاتي سیستم، محلي stub حل کوونکی، براوزر او منفي کیش ټول پایلې ساتي، نو یوه لټون کولی شي بریالۍ شي پرته له دې چې یو ګیډۍ ماشین پریږدي۔ پایله ثبت کړئ دمخه له دې چې هر څه خالي کړئ: ipconfig /flushdns، resolvectl flush-caches یا په macOS کې sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder۔ په دې پړاو کې پراخه شبکه بیا تنظیمول پرېږدئ، ځکه چې هغه شواهد له منځه وړي چې لا یې راټولوئ۔
د دې توپیر معنا څه ده
هغه دوې کرښې پرتله کړئ چې ثبت کړې مو، او د یو تنظیم لمس کولو دمخه بدلون طبقه بندي کړئ۔
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
یوه کرښه ځانګړي ټینګار وړ ده۔ هغه نوم چې حل کیږي کار کوونکې خدمت نه دی، او د DNS بریا یوازې دا وایي چې پته وموندل شوه۔ دا د لیږد، د اور دېوال قاعدو یا د دې په اړه هیڅ نه وایي چې ایا ستاسو حساب کولی شي دا خدمت وکاروي، نو د دې فرض کولو پرځای چې خرابي پخپله ولاړه، ریښتینې اپلیکیشن ازموئ او پای ته یې ورسوئ۔
بنسټیزه کرښه بیرته راوړئ او تایید یې کړئ
د پروسې وژلو پرځای د کلاینټ خپلو کنټرولونو له لارې قطع کړئ، بیا هماغه درې حکمونه بیا ولولئ۔ د هرې اړیکې سرورونه، تګلارې ننوتنې او ستاسو د ازموینې نوم ځواب باید هغې بنسټیزې کرښې ته بیرته راشي چې مخکې مو لیکلې وه۔ له پاک قطع کیدو وروسته پاتې تګلاره ننوتنه ریښتینی نیمګړتیا ده چې ثبت یې ارزي، او همدا لامل دی چې په جوړ شوي حل کوونکي فایل کې لاسي سمون بد عادت دی: فایل بیا لیکل کیږي او سمون ورک کیږي، یا سمون پاتې کیږي او هغه حل کوونکی ټینګوي چې نوره لار نه لري۔
دا لیست یو ځل، په ترتیب سره ترسره کړئ۔ د هرې پایلې قضاوت کولو دمخه فیصله وکړئ چې پروفایل کوم ډیزاین پلي کوي۔ په دواړو چلندونو کې نوم، وسیله او پسوند ثابت وساتئ۔ روښانه پوښتنه د اپلیکیشن لټون څخه جلا کړئ۔ یوازې ځواب نه، اغیزمنه تګلاره ولولئ۔ پرتله کول لیکلو وروسته کیشونه په پای کې خالي کړئ۔ د ریښتیني اپلیکیشن سره تایید کړئ، بیا یو ځل بیا پیل کړئ او تایید کړئ چې قطع شوی حالت لا هم پاک دی۔