وېشل شوی DNS او VPN: د ډومین قواعد IP لارې نه دي
وېشل شوی DNS د نوم له مخې حل کوونکی غوره کوي، او ځواب بیا هم لار غواړي۔ د ډومین قاعده او لار جلا ازموینه کړئ، په هغه پلیټفارم کې چې واقعا یې چلوئ۔
ستاسو لیپ ټاپ intranet.corp د تونل له لارې حل کوي، پداسې حال کې چې gitlab.com د خدمت وړونکي حل کوونکي ته ځي، او دا هغه ترتیب دی چې د طرحې له مخې کار کوي۔ دوه جلا پرېکړو دا جوړ کړ: د نوم د تطابق قاعده حل کوونکی غوره کړ، او لار ځواب بیرته راوړ۔ د دواړو څخه یو مات کړئ او براوزر به داسې ناکامي وښیې چې له بهر څخه ورته ښکاري۔ د وېشل شوي DNS په اړه ډیری راپورونه دوهمه ناکامي بیانوي او د لومړي په اړه شواهد نقلوي۔
دوه نیمایي په جلا ځایونو کې ژوند کوي او معمولا یې جلا خلک سمون کوي۔ یوه VPN پروفایل ته تړل شوې DNS پالیسي ده، بله هغه لار ده چې تونل نصبوي یا بندوي۔ کله چې هیڅوک ونه ټاکي کومه نیمایي واقعا وښویېده، ډیبګنګ ودرېږي۔
په یوه غوښتنه کې پټې دوه پرېکړې
د نوم نیمایي د پالیسۍ شی دی، نه لار۔ په Windows کې دا د VPN پروفایل نوم-حلولو پالیسي ده؛ په Apple پلیټفارمونو کې د DNS تنظیماتو شي باندې د تطابق ډومینونو ټولګه؛ په Linux کې د لارښوونې ډومین، وېشل شوې حل کوونکې کرښه یا د نوم خدمت سویچ ترتیب۔ د لارې نیمایي عادي لارښوونه ده چې تونل یا لاس نصبوي، او پوهه نه لري چې هوسټ نوم څه دی۔ هغه پروفایل چې یو ضمیمه مني یوازې پرېکړه کوي چې څوک ځواب ورکوي؛ دا ځواب هېڅکله د رسېدو وړ نه ګرځوي۔
یو چټک د نښو ازموینه دواړه جلا کوي: نوم د یوې پتې سره بدل کړئ۔ که پته کار وکړ، لار سمه ده او قاعده غلطه۔ که پته هم ناکامه شي، قاعده سمه او لار ورکه کېدای شي۔
هر پلیټفارم هماغه د نوم قاعده څنګه بیانوي
موخه یو شان ده او د ساحو نومونه نه۔ د یو کلاینټ څخه بل ته کاپي شوې بېلګه پاکه تجزیه کېږي او هېڅکله نه مطابقت کوي۔ درې بڼې داسې ښکاري:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
د تطابق یا لارښوونې ډومین د ضمیمې ازموینه ده، نو intranet.corp د git.intranet.corp پوښي او corp.intranet نه پوښي، او د هغې اړول په ټوله ترتیب کې تر ټولو عامه تېروتنه ده۔ Windows نقشه د پروفایل سره تړلې د نوم-حلولو پالیسي په توګه وړي، د انټرفیس سره د مخکې موجود هر ضمیمې لیست په مقابل کې خپل لومړیتوب ترتیب لري۔ Apple پلیټفارمونه د تطابق ډومینونه د شبکې غځونې DNS تنظیماتو شي سره نښلوي، او سیسټم یې هر محدود حل کوونکي لپاره پلي کوي۔ د دې بڼو هیڅ یوه لار نه ده، او هیڅ یوه نه شي کولای نه-رسېدونکې پته رسېدونکې کړي۔ Windows نوم-حلولو پالیسي حواله د هغه پلیټفارم د ساحو نومونه او لومړیتوب قواعد لیستوي، او هغه هغه قواعد نه دي چې Apple یا systemd اسناد یې کاروي۔
سم ځواب بیا هم لار غواړي
د حل کوونکي ځواب یوازې پته ده، او اپلیکیشن باید بیا هم هلته ورسېږي۔ د وېشل شوي تونل ډیزاین ډیری وخت 10.20.0.0/16 ټېل وهل کوي او اصلي لار بندوي، نو داخلي نوم حل کېږي او بیا اړیکه ځوړندېږي۔ برعکس حالت هم هومره عام دی: لار شته، عامه حل کوونکی شخصي نوم ته NXDOMAIN ځواب ورکوي، او ناکامي د لارښوونې ستونزه ثبتېږي۔ لومړی لار ازموینه کول تاسو هغې لارې ته ګوري چې هېڅکله به نه حل کېده۔
درېیمه دروازه هم شته چې هیڅ نیمایي نه پوښي۔ په ګېټوې باندې ACL، د اور دېوال قاعده یا د کلاینټ خوا پالیسي کولای شي اړیکه وغورځوي وروسته له دې چې دواړه پرېکړې سمې وې۔ کله چې نوم حل شي، لار شته او اړیکه بیا هم وخت تېروي، DNS ازموینه بندوئ۔
نومونه او لارې په ټاکلي ترتیب ازموینه کول
یو ترتیب غوره کړئ او وساتئ، که نه تاسو به هغه ګام تعقیب کړئ چې وروستی ناکام شو۔ مستند بشپړ داخلي نوم حل کړئ، تایید کړئ چې ځواب هغه پته ده چې د لارښوونې جدول یې وړلای شي، بیا د عامه نوم سره تکرار کړئ ترڅو ثابته شي چې تونل هر څه ونه نیول۔ په systemd هوسټ باندې پوښتنه او د حل کوونکي لارښوونې ډومین یوې کمانډ فاصله لري:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows کلاینټ هماغه دوه پوښتنې د بېلو cmdlet سره کوي۔ دوهم هغه انټرفیس راپور کوي چې سیسټم به واقعا کاروي:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10که لټون پته راوګرځوي او د لارې کتنه فزیکي انټرفیس نوموي، نو د نوم قاعده کار وکړ او لار نه۔ که لنډ نوم ناکام شي پداسې حال کې چې بشپړ نوم حل کېږي، ضمیمې لیست غلط دی، نه حل کوونکی۔
چېرته چې پرتله معمولا غلطېږي
لومړۍ تېروتنه داده چې له یو ناتړلي عامه حل کوونکي څخه د شخصي نوم په اړه وپوښتئ او ردول د VPN په اړه شاهد وګڼئ۔ دوهمه دا ده چې فرض کړئ کار کوونکی عامه لټون د تونل د حل کوونکي لار ثابتوي۔ درېیمه دا ده چې وېشل شوی تونل او وېشل شوی DNS یوه ډیزاین پرېکړه وګڼئ، پداسې حال کې چې ځای پرځای کول په یوه کې سم او په بل کې مات وي۔ هره تېروتنه له هغې ازموینې څخه ډاډمنې پایلې ورکوي چې هیڅکله تورن شوی برخه نه ده تمرین کړې۔
هغه براوزر چې خپل خوندي DNS لري هم کولای شي سیسټم قاعده پریږدي، له همدې امله یو براوزر ناکامېدل پداسې حال کې چې بل بریالی کېږي تناقض نه دی۔ هغه حل کوونکی پرتله کړئ چې ځواب یې ورکړ، نه هغه براوزر چې شکایت یې وکړ۔
کله چې دواړه نیمایي ښکاره شي، پاتې پوښتنه تخنیکي نه ده، د پالیسۍ پوښتنه ده: کوم د نوم تشې سازمان ته اړه لري، د هر ځواب مالک څوک دی، او کوم یې باید ماشین پریږدي۔ هغه د پروفایل تر څنګ ولیکئ، ځکه چې قاعده ته د بل چا لاس ورکولو لپاره به یې اړتیا وي۔