ولې د سرور نوم له ډایل-ان وروسته خپل VPN پتې ته حل کېږي

یو دفترونکی فایل سرور ټوله سهار خپلې LAN پتې ته ځواب وایي، بیا یو لیرې کاروونکی ډایل-ان کوي او نوم د دې پرځای د تونل پتې ته حل کېدل پیل کوي۔ په DNS کې په لاس کوم شی نه دی ایډیټ شوی، او دا هماغه نښه ده: ریکارډ ماشین پخپله خپور کړی و۔ درې شرطونه پرېکړه کوي چې تاسو راجستر کوونکی، ریکارډ که د مراجعینو لید سم کوئ، او که ترتیب غلط وي ریکارډ به له بلې اړیکې وروسته بېرته راشي۔

دوه پتې، یو نوم، درې شرطونه

څو-انټرفیس Windows سرور کولی شي یو LAN پته، یوه یا څو ډایل-ان پتې او کله ناکله دویمه شبکه کارت ولري۔ هر انټرفیس کولی شي خپلې پتې په DNS کې ثبت کړي که د هغه لپاره متحرک ثبت اجازه ولري۔ کله چې PPP اډاپټر ثبت شي، هماغه هوسټ نوم هغه پته ترلاسه کوي چې یوازې د تونل ملګری ورته رسېدلی شي، او LAN مراجعین یې د معتبر ځواب په توګه ترلاسه کوي۔

درې شرطونه د سمون پرېکړه کوي۔ لومړی، ایا اضافي پته د هغو مراجعینو له خوا چې ترلاسه یې کوي د رسېدو وړ ده؟ دویم، ایا لا هم کوم مصرف کوونکی په دې ثبت تکیه دی؟ دریم، ایا ریکارډ متحرک دی او نو کولی شي بېرته راشي، که ثابت دی او نو قصداً داخلول شوی دی؟

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

د راجستر کوونکي له بدلولو دمخه ریکارډ ولولئ

له هغې شبکې چې ستونزه رپوټ کوي دقیق بشپړ وړ نوم وپوښتئ، او ځوابونه د سرور له ریښتینو انټرفیسونو او اورېدونکو سره پرتله کړئ۔ یو نوم چې څو پتې بېرته راولي نورمال دی؛ پوښتنه دا ده چې هر یو یې د ترلاسه کوونکي مراجع لپاره د کارېدو وړ دی که نه۔

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

لومړۍ پوښتنه ځایي حل کوونکی کاروي، دویمه په مستقیم ډول یو ټاکلي DNS سرور ته پوښتنه کوي، او دریمه هماغه له PowerShell څخه په Windows کې کوي۔ د دوی پرتله کول زوړ مراجع کیش له باوري ځواب څخه بېلوي۔ که مستقیمه پوښتنه لا دمخه د تونل پته بېرته راولي، ستونزه په خپرې شوې ډیټا کې ده نه په ځایي کیش کې۔

د ریکارډ ټایم سټمپ او دا چې DNS کنسول یې متحرک ښیي که نه ولیکئ۔ هماغه یوه ځانګړنه درته وایي چې پورتنۍ درې شرطونه کوم یو پلي کېږي، او دا د پنځو دقیقو پاکۍ او د اوږدې دوام سمون ترمنځ توپیر دی۔

خپرونکی سم کړئ یا ریکارډ، خو پوه شئ کوم یو

که ریکارډ متحرک او ناغوښتل شوی وي، تلپاتې حل دا دی چې هغه انټرفیس له ثبت کولو منع کړئ۔ Windows د هر انټرفیس لپاره د ثبت تنظیمات وړاندې کوي، او DNS مراجع خدمت په بله اړیکه یا د پتې بدلون کې بیا خپروي۔ د ډایل-ان اډاپټر لپاره ثبت بندول د LAN اډاپټر ثبت پوره پرېږدي، چې معمولاً هماغه شی دی چې غواړئ۔

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

که ریکارډ ثابت وي، هغه قصداً هلته ایښودل شوی او خبرې د هغه چا سره دي چې ایښی یې دی۔ د ثابت ریکارډ پاکول ځکه چې نن نااسانه دی یوازینی شاهد چې ولې شته لرې کوي۔ په دواړو حالتونو کې زوړ ځواب یوازې د خپرونکي له سمولو وروسته پاک کړئ، او ولیکئ چې څه مو بدل کړل ترڅو بل کس قصداً داخلول له پېښې څخه بېل کړای شي۔

له هغې مراجع شبکې څخه چې ناکامه شوه تایید کړئ

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

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

لومړی امر د Windows حل کوونکي کیش پاکوي، او دویم ښیي چې نوم بیا کیش شو که نه او کومه پته ذخیره شوه۔ د سرور پخپله ځان سره بریالۍ اړیکه د LAN مراجع په اړه هېڅ نه ثابتوي، او ناغوښتلې پتې ته د لارې لرې کول هغه څه نه سمولي چې DNS یې خپروي۔

په پای کې، هغه پېښه تکرار کړئ چې پخوا به پته راوړله: VPN مراجع بیا وصل کړئ، یا د ډایل-ان ناسته نوي کړئ۔ له هغه ژوند-چرخ بدلون وروسته خپره شوې نوم بیا وګورئ۔ هغه سمون چې یوازې تر بلې اړیکې پورې وي پاکۍ وه، سمون نه، او پوهېدل چې کوم یو مو وکړ د ټکټ تړلو او بله اونۍ بیا خلاصولو ترمنځ توپیر دی۔