چگونه حل‌کننده‌های DNS را که مک شما در VPN استفاده می‌کند بررسی کنید

scutil --dns پیکربندی حل‌کننده‌ای را چاپ می‌کند که macOS واقعاً به آن مراجعه می‌کند، نه تنها سرور DNS که در یک پنل تنظیمات تایپ کرده‌اید. خروجی طولانی‌تر از آن است که بیشتر مردم انتظار دارند، چون سیستم بلوک‌های حل‌کنندهٔ جداگانه برای مسیر پیش‌فرض، برای رابط‌های محدوده‌دار و برای ارسال ویژهٔ دامنه نگه می‌دارد. بلوک بالای خروجی لزوماً همانی نیست که به پرس‌وجو پاسخ می‌دهد. اگر یک نام خصوصی در دفتر حل شود و درست وقتی VPN بالا می‌آید شکست بخورد، ناهماهنگی در قواعد تطبیق و مسیرهاست، نه در نشانی سرور. اول ترتیب را بخوانید، بعد پاسخ را با یک جست‌وجوی واقعی ثابت کنید.

ترتیب بلوک‌ها را پیش از نشانی‌ها بخوانید

هر ورودی با resolver #N باز می‌شود و nameserver[0]، گاهی if_index، یک خط flags، reach و وقتی بلوک پیش‌فرض ساده نیست، یک domain و فهرست search domain را نشان می‌دهد. حل‌کنندهٔ شمارهٔ 1 بدون دامنه همان پیش‌فرضی است که نام‌های عمومی را اداره می‌کند. هر چیزی که در پرچم‌هایش Scoped دارد به رابطی بسته است که if_index نام می‌برد، و هر چیزی که با Supplemental علامت خورده فقط برای دامنه‌های فهرست‌شده زیر آن اعمال می‌شود.

انتخاب، تطبیق پسوند است. برای نامی مانند intranet.corp.example، macOS حل‌کننده‌ای را ترجیح می‌دهد که ورودی domain آن بلندترین پسوند منطبق است، بنابراین بلوکی با domain : corp.example حتی وقتی بسیار پایین خروجی باشد بر پیش‌فرض پیروز می‌شود. order تساوی میان دامنه‌های هم‌طول را می‌شکند. نگاه اول به‌ندرت بیش از این لازم دارد: کل خروجی وقتی می‌خواهید یک بلوک را از ابتدا تا انتها بخوانید، خطوط آغازین برای یادگیری ترتیب بلوک‌ها، و یک گذر فیلترشده که سرصفحه‌های بلوک را کنار خطوط فیلد چاپ می‌کند. بلوک‌های محدوده‌دار زیر عنوان خودشان ظاهر می‌شوند و مانند ادامهٔ فهرست بالایشان خوانده می‌شوند، پس هر وقت خروجی را نقل می‌کنید یک سرصفحه را پیش چشم نگه دارید.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

if_index را با رابط تونل تطبیق دهید

یک نمایه فقط وقتی مفید است که بتوانید رابط پشت آن را نام ببرید. scutil --nwi اطلاعات شبکه‌ای را که سیستم نگه می‌دارد فهرست می‌کند، از جمله رابط اصلی و دسترس‌پذیری، در حالی که ifconfig -l نام‌ها را به شما می‌دهد، جایی که utun0 تا utun9 نامزدهای تونل هستند که یک کلاینت معمولاً می‌سازد. اپل از scutil --dns به‌عنوان نمونهٔ بررسی خودش در راهنمای استقرار استفاده می‌کند و مستند می‌کند که چگونه Network Extension می‌تواند دامنه‌های برگزیده را به حل‌کننده‌های برگزیده هدایت کند، که همان سازوکاری است که این بلوک‌های محدوده‌دار آشکار می‌کنند.

بررسی‌ای که تصمیم می‌گیرد این است که آیا حل‌کننده روی مسیری است که تونل نصب کرده:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

اگر route -n get دروازه و رابطی برگرداند که با ورودی حل‌کننده نمی‌خواند، ممکن است نشانی کاملاً درست و در عین حال دسترس‌ناپذیر باشد. تونل شکافته‌ای که فقط زیرشبکه‌های شرکتی را حمل می‌کند، پرس‌وجوهای رو به سرور DNS بیرون آن‌ها را می‌اندازد و خرابی به‌صورت پایان مهلت ظاهر می‌شود، از همین رو خروجی پیکربندی هنوز تمیز به نظر می‌رسد.

از حل‌کنندهٔ سیستم بپرسید، سپس از سرور

سه ابزار به سه پرسش متفاوت پاسخ می‌دهند و اشتباه گرفتن آن‌ها بیشتر نتیجه‌های نادرست این حوزه را می‌سازد. dscacheutil -q host -a name از همان حل‌کنندهٔ سیستمی می‌گذرد که برنامه‌های معمولی به کار می‌برند، پس بلوک‌های محدوده‌دار و تکمیلی اعمال می‌شوند. dig بدون آرگومان سرور /etc/resolv.conf را می‌خواند که برای حل محدوده‌دار در macOS منبع حقیقت نیست و قواعد هر دامنه را کاملاً رد می‌کند. dig @address دقیقاً به یک سرور می‌رسد و دربارهٔ انتخاب چیزی نمی‌گوید.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

وقتی فرمان اول پاسخ می‌دهد و دومی NXDOMAIN برمی‌گرداند، همان شکافی را یافته‌اید که دنبالش بودید و هیچ چیز خراب نیست. وقتی اولی به پایان مهلت می‌رسد در حالی که dig @10.20.0.53 پاسخ می‌دهد، حل‌کننده کار می‌کند اما روی مسیری که تونل برگزیده دسترس‌پذیر نیست، پس گام بعدی route -n get است و نه تغییر تنظیمات DNS. نام‌های خصوصی را از هر چیزی که در تیکت یا یادداشت مشترک می‌چسبانید بیرون نگه دارید.

آنچه خروجی نمی‌تواند به شما نشان دهد

چند لایه بالای فهرست حل‌کننده‌ها یا کنار آن می‌نشینند و هر کدام می‌توانند پرس‌وجویی را جایی بفرستند که خروجی هرگز به آن اشاره نمی‌کند. مرورگری با DNS امن فعال ممکن است از کانال رمزگذاری‌شدهٔ خودش حل کند، پس صفحه‌ای که بارگذاری می‌شود در حالی که dscacheutil به پایان مهلت می‌رسد تناقض نیست. پراکسی DNS که نرم‌افزار امنیتی نصب می‌کند به‌عنوان ارائه‌دهندهٔ Network Extension اجرا می‌شود و خودش پرس‌وجوها را هدایت می‌کند، و scutil --dns نشان می‌دهد چه چیزی پیکربندی شده بود، نه نشانی بالادستی را که پراکسی در نهایت به کار برد. دامنه‌های جست‌وجو چین سوم را اضافه می‌کنند: به نامی که کامل نیست هر پسوند فهرست‌شده به ترتیب افزوده می‌شود، پس بلوکی که پاسخ داده ممکن است یکی باشد که هرگز به آن شک نکرده‌اید.

پاسخ‌های کهنه ارزان‌ترین چیزی برای کنار گذاشتن و پرش‌شده‌ترین‌اند:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

اگر خروجی پس از پاک‌سازی تغییر کند، وضعیت در حافظهٔ نهان بود و خروجی پیشین تونلی را توصیف می‌کرد که دیگر وجود نداشت. اگر تغییر نکند، پیکربندی همان است که هست و پرسش به مسیرها و سیاست برنامه‌ها منتقل می‌شود.

راهنمای کوتاهی برای پیش و پس

فقط جایی که سیاست اجازه می‌دهد خط پایه بگیرید و فایل‌ها را از هر پوشهٔ همگام‌شده بیرون نگه دارید. دنبالهٔ زیر همانی است که من روی ماشین‌های کلاینت اجرا می‌کنم: خط پایه را بگیرید، وصل شوید، دوباره بگیرید، سپس مقایسه کنید و جست‌وجو کنید.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

تفاوت را بلوک‌به‌بلوک بخوانید نه خط‌به‌خط. حل‌کنندهٔ محدوده‌دار تازه‌ای که نمایهٔ رابط تونل و ورودی domain برای پسوند خصوصی را حمل می‌کند شکل مورد انتظار است. حل‌کنندهٔ پیش‌فرض تازه‌ای که به نشانی عمومی اشاره می‌کند یافته‌ای است که ارزش دارد با صاحب پروفایل کلاینت مطرح شود. سپس جست‌وجو را درون برنامه‌ای که واقعاً شکست خورد تکرار کنید، نه فقط در پوسته، و رابط حاصل از route -n get را کنار نتیجه بنویسید.

برای برگرداندن یک تغییر، قطع کنید و گرفتن خط پایه را تکرار کنید. اگر بلوک محدوده‌دار رفته است، کلاینت پشت سر خودش را تمیز کرده. اگر بلوک هنوز در برابر رابطی فهرست شده که دیگر وجود ندارد، وضعیت کهنه است، و پاک‌سازی به‌همراه اتصال دوباره ملایم‌ترین اصلاح پیش از آن است که کسی به پروفایل دست بزند.

چهار بررسی به این ترتیب: آیا بلوکی از حل‌کننده با بلندترین پسوند نام می‌خواند، آیا آن بلوک به رابطی که تونل نصب کرده بسته است، آیا مسیر تا سرور نامش از تونل استفاده می‌کند، و آیا حل‌کنندهٔ سیستم و نه dig پاسخ را برمی‌گرداند. نخستین بررسی‌ای که شکست بخورد به شما می‌گوید سیاست DNS، مسیرهای تونل یا برنامه را تغییر دهید. اگر هر چهار مورد بگذرند و نام هنوز شکست بخورد، مشکل بالاتر از DNS است و چیز بعدی که باید بررسی شود هر چیزی است که پیش از آن به درگاه 53 پاسخ می‌دهد.