آیا VPN DNS من را تغییر داد؟ پیش و پس را مقایسه کنید
یک پروفایل می‌تواند جست‌وجوهای شما را عمداً جابه‌جا کند. سیاست مفسر و پاسخ واقعی را پیش و پس از اتصال VPN مقایسه کنید و یک متغیر را ثابت نگه دارید.
تونل را وصل می‌کنید، یک داشبورد خصوصی باز می‌کنید و نام به نشانی حل می‌شود که هرگز آن را ندیده‌اید. یا عکس آن رخ می‌دهد: مرورگر به کار خود ادامه می‌دهد در حالی که ابزار خط فرمان ناگهان هیچ چیز را حل نمی‌کند. هر دو نتیجه از یک تغییر می‌آیند و مردم معمولاً آن را با یک جمله دربارهٔ VPN که «از DNS خودش استفاده می‌کند» توضیح می‌دهند، که برای عیب‌یابی یا راستی‌آزمایی به‌اندازهٔ کافی دقیق نیست. دو پرسش در آن جمله پنهان است: این پروفایل قرار است کدام جست‌وجوها را بر عهده بگیرد، و آیا دستگاه شما واقعاً آن‌ها را به مفسری که به آن داده شده فرستاد؟ جدا نگه داشتن این دو، تمام روش است، زیرا آزمونی که آن‌ها را درهم آمیزد در هر دو جهت پاسخی مطمئن و نادرست می‌دهد.
چرا یک پروفایل اصلاً مفسر عرضه می‌کند
درون تونل، نام‌های پشت انتهای دور معمولاً به نشانی‌هایی حل می‌شوند که فقط در همان شبکه وجود دارند. یک ناحیهٔ خصوصی مانند corp.internal تفویض عمومی ندارد، پس مفسری که به آن پاسخ می‌دهد باید از درون تونل در دسترس باشد. همین سازوکار هدف دومی را هم برمی‌آورد: وقتی جست‌وجوها در غیر این صورت از طریق ارائه‌دهندهٔ شما بیرون می‌رفتند، مفسری در سمت دور پرس‌وجو را درون مسیر رمزنگاری‌شده نگه می‌دارد. به همین دلیل نشانی سرور DNS به‌عنوان بخشی از سیاست اتصال می‌آید و نه به‌عنوان تنظیمی سراسری که یک بار برای دستگاه انتخاب کرده‌اید.
نشانی به‌تنهایی چیزی را روشن نمی‌کند. مفسر فقط وقتی می‌تواند پاسخ دهد که مسیری به آن وجود داشته باشد، و شایع‌ترین خرابی مفسری است که فقط تا وقتی تونل برپاست در دسترس است. وقتی تونل قطع می‌شود و سیاست می‌ماند، جست‌وجوها به نشانی‌ای می‌روند که مسیری ندارد و نشانه، پایان مهلت است نه خطای تمیز. این تفاوت وقتی نتیجهٔ آزمون بعدی را می‌خوانید مهم است، زیرا پایان مهلت مردم را به تنظیمات انتقالی می‌فرستد که هرگز درگیر نبوده‌اند.
پیش از مقایسهٔ پاسخ‌ها، دو طراحی را مقایسه کنید
تونل کامل و DNS تقسیم‌شده انتظارهای متضاد می‌سازند و هیچ‌یک خرابی نیست. در تونل کامل هر جست‌وجو می‌تواند به ارائه‌دهنده یا به مفسر شرکتی برود، پس متفاوت پاسخ دادن نام‌های عمومی پس از اتصال طبیعی است. در DNS تقسیم‌شده فقط دامنه‌های فهرست‌شده به مفسر خصوصی می‌روند و بقیه محلی می‌مانند؛ در ویندوز فهرست دامنه‌ها در Name Resolution Policy Table زندگی می‌کند، در macOS در دامنه‌های منطبق تنظیمات DNS، و در میزبان دارای systemd-resolved در دامنه‌های مسیریابی هر پیوند.
همین مقایسه را باید اول انجام داد، چون تعیین می‌کند چه چیزی خرابی شمرده می‌شود. با DNS تقسیم‌شده، نام عمومی‌ای که از مفسر تازه پاسخ می‌گیرد همان چیزی است که ارزش بررسی دارد، در حالی که نام داخلی که درست پاسخ می‌گیرد یعنی سامانه کار خودش را می‌کند. با تونل کامل، ناهنجاری نام عمومی‌ای است که هنوز از مفسر ارائه‌دهندهٔ شما پاسخ می‌گیرد. مستندات مایکروسافت دربارهٔ حل نام VPN ترتیب ویندوز برای این قواعد را توصیف می‌کند، از جمله اینکه چگونه یک ورودی سیاست منطبق پیش از سرورهای خود آداپتور بررسی می‌شود.
مفسر سومی هم در اتاق هست که فراموش کردنش آسان است. DNS امن مرورگر خودش نام‌ها را حل می‌کند و می‌تواند پس از آنکه تونل سیاست سیستم‌عامل را تغییر داد همچنان پاسخ دهد، پس صفحه‌ای که بارگذاری می‌شود اثبات می‌کند مفسر مرورگر کار کرده است، نه اینکه پروفایل اعمال شده باشد. اگر فقط چیزی را مقایسه کنید که مرورگر نشان می‌دهد، نیمی از وقت لایهٔ اشتباه را می‌آزمایید.
یک خط پایه با تنها یک متغیر ثبت کنید
تونل را عوض کنید. در همان گام نام، ابزار یا پسوند جست‌وجو را هم عوض نکنید. نامی را انتخاب کنید که اجازهٔ پرس‌وجو دربارهٔ آن را دارید، یادداشت کنید از کدام برنامه استفاده کردید، و یا نشانی برگشته یا خطای دقیق را بنویسید. در ویندوز Get-DnsClientServerAddress -AddressFamily IPv4 سرورهای هر آداپتور را چاپ می‌کند و Get-DnsClientNrptPolicy ورودی‌های سیاست را؛ در لینوکس با systemd-resolved، resolvectl status سرورهای DNS و دامنه‌های مسیریابی هر پیوند را نشان می‌دهد؛ در macOS، scutil --dns ترتیب مفسرهایی را چاپ می‌کند که سامانه واقعاً دنبال خواهد کرد.
سپس از طریق کنترل‌های معمول کلاینت وصل شوید و دقیقاً همان فرمان‌ها را تکرار کنید. خروجی نخست را نگه دارید نه خاطرهٔ آن را، چون مقایسه تمام ماجراست و خواندن دوم پس از پاک کردن حافظهٔ نهان از پیش اندازه‌گیری دیگری است. اگر خط پایه با مرورگر در جلو گرفته شده و اجرای پس از اتصال در ترمینال رخ می‌دهد، دو مفسر را مقایسه می‌کنید نه دو حالت یک مفسر.
پرس‌وجوی صریح و جست‌وجوی برنامه دو آزمون متفاوت‌اند
پرسیدن از یک سرور مشخص، با nslookup name 10.20.0.1 یا dig @10.20.0.1 name، فقط یک چیز را اثبات می‌کند: سروری که نام بردید وقتی به آن دسترسی دارید پاسخ می‌دهد. این کار منطق انتخاب را کاملاً دور می‌زند، پس نمی‌تواند بگوید سامانه آیا آن سرور را برای این نام انتخاب می‌کرد یا نه. از آن برای آزمودن دسترس‌پذیری مفسر تخصیص‌یافته استفاده کنید و برای آزمودن سیاست استفاده نکنید.
جست‌وجو از طریق مفسر محلی واقعاً انتخاب را به کار می‌گیرد. resolvectl query name همان قواعد دامنه‌های مسیریابی را طی می‌کند و گزارش می‌دهد کدام پروتکل پاسخ داده است، Resolve-DnsName در ویندوز از جدول سیاست و حافظهٔ نهان کلاینت می‌گذرد، و scutil --dns ترتیبی را نشان می‌دهد که یک جست‌وجو دنبال می‌کند. هر دو نوع را اجرا کنید و آن‌ها را در ستون‌های جداگانهٔ یادداشت‌هایتان نگه دارید. پرس‌وجوی صریح موفق در کنار جست‌وجوی ناموفق برنامه، مشکلی در مسیریابی یا انتخاب است نه مفسری که از کار کردن سر باز می‌زند.
حافظهٔ نهان میان شما و پاسخ ایستاده است. سیستم‌عامل، مفسر میانی محلی، مرورگر و حافظهٔ نهان منفی همه نتیجه‌ها را نگه می‌دارند، پس یک جست‌وجو می‌تواند موفق شود بدون آنکه بسته‌ای دستگاه را ترک کند. نتیجه را پیش از پاک کردن هر چیزی ثبت کنید: ipconfig /flushdns، resolvectl flush-caches یا sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder در macOS. بازنشانی گستردهٔ شبکه را در این مرحله رد کنید، چون شواهدی را که هنوز جمع می‌کنید نابود می‌کند.
تفاوت چه معنایی دارد
دو ردیفی را که ثبت کردید مقایسه کنید و تغییر را پیش از دست زدن به حتی یک تنظیم دسته‌بندی کنید.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
یک ردیف شایستهٔ تأکید است. نامی که حل می‌شود خدمتی نیست که کار می‌کند، و موفقیت DNS فقط می‌گوید نشانی‌ای پیدا شد. دربارهٔ ارسال، قواعد دیوار آتش یا اینکه حساب شما اصلاً اجازهٔ استفاده از خدمت را دارد چیزی نمی‌گوید، پس کار را با آزمودن برنامهٔ واقعی تمام کنید نه با فرض اینکه خرابی خودبه‌خود رفته است.
خط پایه را برگردانید و راستی‌آزمایی کنید
از طریق کنترل‌های خود کلاینت قطع کنید نه با کشتن فرایند، سپس همان سه فرمان را دوباره بخوانید. سرورهای هر پیوند، ورودی‌های سیاست و پاسخ نام آزمون شما باید به خط پایه‌ای که پیش‌تر نوشتید برگردند. ورودی سیاستی که پس از قطع تمیز باقی می‌ماند نقص واقعی و ارزش ثبت دارد، و همین دلیل بد بودن ویرایش دستی پروندهٔ مفسر تولیدشده است: پرونده بازنویسی می‌شود و ویرایش ناپدید می‌شود، یا ویرایش می‌ماند و مفسری را میخکوب می‌کند که دیگر مسیری ندارد.
این فهرست را یک بار و به ترتیب پیش ببرید. پیش از داوری هر نتیجه تصمیم بگیرید پروفایل کدام طراحی را پیاده می‌کند. نام، ابزار و پسوند را در هر دو اجرا ثابت نگه دارید. پرس‌وجوی صریح را از جست‌وجوی برنامه جدا کنید. سیاست مؤثر را بخوانید نه فقط پاسخ را. حافظه‌های نهان را آخر پاک کنید، پس از نوشتن مقایسه. با برنامهٔ واقعی راستی‌آزمایی کنید، سپس یک بار راه‌اندازی مجدد کنید و تأیید کنید که وضعیت قطع‌شده هنوز تمیز است.