د VPN کوربه نومونه ناکامېږي، IP پتې کار کوي: چېرته وګورو

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

نوم هغه پوښتنه کوي چې پته یې نه کوي

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

له پتې بهر کار وکړئ: لومړی بشپړ نوم، بیا لوڅ کوربه نوم، او ولیکئ چې له دریو څخه کوم کار کوي۔ بڼه تاسو ته وایي چې د یوې تنظیمي پردې پرانیستلو دمخه کوم پوړ وګورئ۔ کله چې بشپړ نوم حل شي لارو ته اټکل کول بې ګټې زحمت دی۔

هغه حل کوونکی ولولئ چې تونل ریښتیا لګولی دی

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

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

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

Get-DnsClientNrptPolicy
ipconfig /all

که داخلي زون د سم سرور له لارې حل شي، ودرېږئ۔ حل کوونکی ستاسو ستونزه نه ده۔

پسوندونه ناکام لنډ نومونه څرګندوي

یو لیبل نوم د پوښتنې لېږلو دمخه د اړیکې د پسوندونو لیست سره پراخېږي۔ که VPN داخلي پسوند ونه رسوي، fileserver هیڅکله fileserver.corp.example نه شي، او پوښتنه داسې نوم وباسي چې هېڅ عامه حل کوونکی نه پېژني۔ پسوند ټینګول، یا بشپړ نوم لیکل، فرضیه ازمويي پرته له دې چې په سرور کې څه بدل کړي۔

nslookup fileserver.corp.example
ping -a 192.168.50.20

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

که د پسوند زیاتول یې سم کړل، پاتې کار دا دی چې هماغه پسوند د VPN پروفایل له لارې ورسوئ پر ځای دې چې له هر کاروونکي یې لیکل وغواړئ۔

NetBIOS او WINS بېله میکانیزم دی

زوړ SMB لا هم کولای شي لوڅ نوم د NetBIOS نوم خدمت سره ولټوي، کوم چې د خپرونې له لارې یا د WINS سرور له لارې ځواب وایي۔ خپرونه په یوه خپرونې ډومین کې پاتې کېږي او په لومړي روټر کې درېږي، نو نه شي کولای تونل واوړي؛ WINS کار کوي ځکه کليانټ یوه unicast پته لري چې پرې ثبت شي او پوښتنه وکړي۔ همدا لامل دی چې یوازې IP وړونکی VPN لا هم کولای شي زاړه نومونه ملاتړ کړي کله چې WINS تنظیم شوی او د لاسرسي وړ وي۔

nbtstat -n
nbtstat -R

د نوي SMB لپاره پر DNS او بشپړ نوم تکیه وکړئ، او زوړ لار تقاعد کړئ۔ که ریښتیا زوړ وي، WINS برابروئ یا اپلیکیشن بدل کړئ؛ منځنی لار د ملاتړ یوه قطار ده چې هېڅکله تش نه شي۔

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