ولې داخلي کوربه نومونه په dig کې حل کېږي خو په VPN کې curl کې ناکامېږي
dig ځواب وایي، خو curl راپور ورکوي چې کوربه نشي حل کولی. دواړه د لټون زنځیرونه پرتله کړئ، بیا nsswitch، د هرې اړیکې DNS یا غلط د لټون پسوند سم کړئ.
ستاسو لپ ټاپ په VPN کې دی، dig service.internal.example د 10.x پتې سره ځواب وایي، او curl بیا هم د Could not resolve host سره وتل کوي۔ تونل ستونزه نه ده: هغه د dig پوښتنه پرته له شکایت ولېږدوله۔ توپیر دا دی چې پوښتنه څوک کوي۔ dig یوه پوښتنه ستاسو نومول شوي یو سرور ته لېږي، خو curl د عملیاتي سیسټم د لټون زنځیر څخه تېرېږي، او د دې زنځیر خپل قواعد لري چې له کوم سرور څخه پوښتنه کېږي۔
د یوه نوم لپاره دوه لټونونه
dig خپل جلا stub resolver دی۔ دا /etc/resolv.conf لولي، یو نوم سرور ټاکي، یوه A یا AAAA پوښتنه لېږي او ځواب چاپوي۔ دا nsswitch بشپړ پرېږدي او د هغې د اړیکې حالت په اړه چې systemd-resolved یا NetworkManager له دې فایل څخه بهر ساتي، هېڅ نه پوهېږي، له همدې امله د dig ځواب سم کېدای شي او بیا هم تاسو ته د هغه څه په اړه هېڅ ونه وایي چې ستاسو غوښتنلیک به یې وګوري۔
غوښتنلیکونه getaddrinfo بولي، او getaddrinfo اوږده زنځیر ته ځي: د nsswitch ماډلونو ترتیب، بیا هغه ماډل چې نوم سمبالوي، او په پای کې هغه resolver چې له اوسني اړیکې ترتیباتو جوړ شوی۔ په systemd ماشین کې پوښتنه 127.0.0.53 ته ځي، او systemd-resolved د tun انټرفېس سره تړلي روټینګ ډومین له مخې د هرې اړیکې لپاره پورتنۍ سرور ټاکي۔
دوه کمانډونه دا پوړونه پرته له اټکل جلا کوي:
getent ahosts service.internal.example
resolvectl query service.internal.examplegetent هغه لاره کاروي چې curl کاروي، نو د کارکوونکي dig تر څنګ د getent ناکامي تېروتنه په پاکټ روټینګ کې نه، بلکې په لټون تګلاره کې ځای پر ځای کوي۔ resolvectl query هغه انټرفېس او پورتنی سرور هم چاپوي چې ځواب یې ورکړ، او دا ښیي چې د تونل اړیکه یا فزیکي اړیکه پرېکړه وګټله۔
هغه resolver ولولئ چې غوښتنلیک یې واقعاً کاروي
/etc/resolv.conf په ډېرو ډیسک ټاپونو کې جوړېږي، او VPN کلاینټ له هغې سره د تعامل درې لارې لري: په سر کې نوم سرور ورزیاتول، فایل باندې لیکل، یا خپل سرورونه NetworkManager ته سپارل او ډیمون ته اجازه ورکول چې بیا یې ولیکي۔ یوازې درېیم نمونه د هرې اړیکې DNS ساتي، ځکه سرورونه له انټرفېس سره تړلي پاتې کېږي پر دې باندې چې په یوه نړیوال لیست کې هوار شي۔
په NetworkManager سیستمونو کې پایله په /etc/NetworkManager/NetworkManager.conf کې د backend پورې اړه لري:
[main]
dns=systemd-resolvedد dns=default سره د کلاینټ سرورونه په resolv.conf کې د ګټونکي ترتیب له مخې یوځای کېږي، او یوه شخصي پوښتنه لا هم کولای شي عام resolver ته لاړه شي۔ له هغه backend سره چې اړیکې پېژني، systemd-resolved یا dnsmasq، د تونل سرورونه تونل ته محدود پاتې کېږي او یوازې هغه نومونه چې د هغه د روټینګ ډومین سره سمون لري هلته ځي۔ دا محدودیت هغه څه دي چې split DNS په عمل کې مانا لري، او دا هغه برخه ده چې ډېری وختونه نشتې وي کله چې کلاینټ ادعا کوي چې ملاتړ یې کوي۔
له هر څه بدلولو مخکې حالت ولولئ:
resolvectl status
resolvectl dns tun0تاسو غواړئ tun انټرفېس له DNS سرور او د شخصي پسوند لپاره د روټینګ ډومین سره لیست شوی وګورئ، چې ~internal.example بڼه ښودل شوی وي۔ په اړیکه کې د سرور نه شتون مانا دا ده چې کلاینټ هېڅ نه دی لېږلی۔ پرته له ډومین سرور مانا دا ده چې پوښتنې یا ټولې هلته ځي یا هېڅ یوه نه، د کلاینټ له مخې، او دواړه split DNS نه دي۔
چېرې nsswitch لټون ژر پای ته رسوي
یو معیاري ډیسک ټاپ کرښه داسې ښکاري:
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostnamemdns4_minimal د multicast DNS سمبالوي او د .local په پای ختمېدونکي هر نوم ادعا کوي۔ د api.infra.svc.cluster.local په څېر Kubernetes خدمت هم په .local ختمېږي۔ کله چې mDNS ماډل NOTFOUND راپور ورکړي، [NOTFOUND=return] عمل ټول لټون پای ته رسوي پر دې باندې چې dns ماډل ته دوام ورکړي، نو نوم هېڅکله VPN resolver ته نه لېږل کېږي۔ dig فایل بشپړ څنګ ته کوي، او همدا لامل دی چې دوه وسایل سره نه یوځای کېږي۔
دا په دې ستونزه کې تر ټولو تېز تضاد دی، او په هغه ترتیباتي فایل کې یوې کلمې ته رسېږي چې ستاسو له VPN څخه زوړ دی۔ عمل [NOTFOUND=continue] ته بدلول د پرنټرونو او سیمه ییزو وسایلو لپاره mDNS ساتي او DNS ته اجازه ورکوي چې نوم وویني۔ کرښه په hosts: files dns بدلول هم کار کوي او خامتر دی: د هغه پرنټر لپاره .local حل لرې کوي چې تاسو یې واقعاً کاروئ۔
هغه نومونه چې په یوازې یوه شبکه کې ژوند کوي
شخصي زونونه په یوازې یو ځای واکمن دي۔ د ip-10-0-4-31.eu-west-1.compute.internal په څېر AWS نوم د هغه سیمې VPC resolver له لارې ځواب ورکول کېږي، او یوازې تر هغه پورې چې ستاسو VPN پای ټکی په هغه سیمه کې وي چې سرچینه پکې ده۔ له فرانکفورټ پای ټکي سره وصل شئ، د ایرلینډ compute.internal نوم وپوښتئ، او هېڅ سیمه ییز ترتیب به مرسته ونه کړي: هغه زون چې ریکارډ لري له هغه ځایه د لاسرسي وړ نه دی۔
د لټون ډومینونه انځور انعکاس جوړوي۔ خالي service په هغه پسوند بشپړېږي چې resolver یې د تطبیق وړ ګڼي، او له VPN اړیکې سره سیمه ییز ډومین کولای شي شرکت ډومین ته ماتې ورکړي۔ د اټکل د لرې کولو لپاره په پای کې نقطه لګولې وپوښتئ، getent ahosts service.internal.example.، او که دا کار وکړ او لنډ نوم ناکام شي، سمون په تونل باندې د لټون ډومین دی، نه د سرور پته۔
مدیریت شوي کلاینټونه د سیسټم resolver پورته درېیم پوړ ورزیاتوي۔ د Windows VPN پروفایل کولای شي خپله د نوم حل تګلاره، د هر اپلیکیشن قواعد او د NRPT جدول راوړي چې حتی کله تونل بند وي هم تطبیقېږي۔ هغه اپلیکیشنونه چې خپل DNS کیش لري، چې په .NET او Java چاپېریالونو کې عام دي، تر زنځیر سمولو وروسته هم زوړ ناکامي اوږد ساتي۔ Apple کلاینټونه split DNS د DNS ترتیباتو کې د سمون ډومینونو له لارې تنظیموي، نه د resolv.conf له لارې، او Chromium یا Firefox په خوندي DNS حالت کې کولای شي د عامو نومونو لپاره سیسټم resolver څنګ ته کړي۔ د Microsoft د VPN نوم حل مرجع د دې تګلارې پوړ Windows اړخ تشریح کوي۔
پرېکړه وکړئ چې کوم پوړ سم کړئ
د سمونونو له ترتیب سره د ازموینې پر ځای له نښې پوړ ته لاړ شئ:
| Symptom | What it means | Check first |
|---|---|---|
| dig answers, getent fails | lookup chain, not the packet path | nsswitch line and resolvectl status |
| Timeout rather than NXDOMAIN | private resolver unreachable through the tunnel | resolvectl dns tun0, route to that address |
| NXDOMAIN | an authority answered and does not know the name | zone owner, endpoint region |
| FQDN works, short name fails | search suffix mismatch | resolvectl domain on the tun link |
| getent works, app fails | app cache or its own resolver | restart the app, check secure DNS |
دوه کرښې ډېر دروند بار وړي۔ د وخت ختمېدل د لاسرسي ستونزه ده: شخصي resolver د تونل له لارې ځواب نه وایي، نو د هغې پتې ته لاره او دا چې په اړیکه کې DNS سرور هغه دی چې تاسو یې فکر کوئ، وګورئ۔ NXDOMAIN د واک ستونزه ده: یو څه ځواب وویل او نوم نه پېژني، چې زون، سیمې یا هغه resolver ته اشاره کوي چې دا پوښتنه یې باید هېڅکله نه وای ترلاسه کړې۔
وروستې کرښه هغه ده چې خلک یې پرېږدي ځکه دواړه نیمې برخې بریالیتوب ښکاري۔ له FQDN څخه په بېل ډول حل کېدونکی لنډ نوم د پسوند ناسمون دی، او تونل بیا نښلول به دې ته نه بدل شي چې کلاینټ کوم پسوند لېږي۔
له ترتیباتي فایل تدوین مخکې حالت ثبت کړئ، تر څو ووایاست چې تدوین څه وکړل که نه:
resolvectl status > before.txt
getent ahosts service.internal.example >> before.txtازموینې په دې ترتیب چل کړئ او په لومړنۍ ناکامۍ ودرېږئ۔ getent او resolvectl query باید سره سمون ولري؛ که getent ناکام شي او dig ځواب ووایي، په لټون زنځیر کې پاتې شئ او روټینګ ته لاس مه وروړئ۔ resolvectl status باید په tun انټرفېس کې DNS سرور او روټینګ ډومین وښیي۔ nsswitch باید د ازمویل شوي پسوند لپاره په NOTFOUND ژر بیرته رانه شي۔ نوم باید په هغه شبکه کې واکمن وي چې ستاسو پای ټکی ورسره نښل شوی، په پای کې نقطې سره ازمویل شوی۔ غوښتنلیک باید خپل کیش یا د خوندي DNS بیاځلي لیکل ونه ساتي۔
یوازې لومړنی ناکام پوړ سم کړئ، بیا هماغه کمانډونه بیا چل کړئ۔ په یو وخت کې دوه بدلونونه تاسو د دې وړ نه ګرځوي چې ووایاست کوم یو مهم و، او بل خرابي څېړنه له صفر څخه پیلوي۔