VPN وصل است اما نام‌ها شکست می‌خورند: DNS در کجا واقعاً می‌شکند

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

یک جست‌وجو واقعاً به چه چیزی نیاز دارد

یک جست‌وجو به سه چیز نیاز دارد: نشانی resolver، مسیری به آن نشانی و پاسخی که با پرسش جور باشد. هر یک می‌تواند به‌تنهایی شکست بخورد و نشانه ظاهری همان صفحه‌ای است که بارگذاری نمی‌شود. به همین دلیل صفحه خطا تا زمانی که ندانید کدام یک از این سه شکسته است تقریباً هیچ چیزی به شما نمی‌گوید.

کلاینت resolver خود را از پروفایل VPN، از DHCP روی تونل یا از پیکربندی خودش می‌آموزد و اینکه کدام منبع برنده شود به سکو بستگی دارد. در ویندوز، ipconfig /all سرورهای DNS را برای هر آداپتور فهرست می‌کند، پس می‌بینید آیا مقدار ارسال‌شده واقعاً رسیده است یا نه. مقداری که هرگز به سیستم‌عامل نرسید، یک شکست خاموش و رایج است. پیش از دست زدن به پروفایل، مقدار پیکربندی‌شده را بخوانید.

لینوکس و macOS به همان پرسش با فرمان‌های متفاوت پاسخ می‌دهند و پاسخ سزاوار همان خواندن است: resolvectl status و scutil --dns هر دو سرورها را برای هر واسط فهرست می‌کنند. این فهرست را با نشانی‌ای که پروفایل ادعا می‌کند ارسال می‌کند مقایسه کنید. ناسازگاری در اینجا همه چیز پایین‌دست را توضیح می‌دهد، پس پیش از آزمایش نام‌ها آن را روشن کنید.

یک نام عمومی و یک نام خصوصی را آزمایش کنید

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

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

nslookup هم سروری را که از آن پرسیده و هم پاسخی را که گرفته چاپ می‌کند و دقیقاً همان جفتی است که لازم دارید. آن را دو بار در همان پوسته اجرا کنید و نشانی پاسخ‌دهنده را کنار هر پاسخ بنویسید.

nslookup example.com
nslookup host.corp.example 10.20.30.53

تأیید کنید که کلاینت واقعاً به آن سرور می‌رسد

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

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

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

در پروفایل تونل تقسیم‌شده ممکن است resolver بیرون از مسیرهای ارسال‌شده باشد، که مشکلی در پروفایل است نه در سرور. نشانی resolver را با پیشوندهای ارسال‌شده مقایسه کنید و تأیید کنید که یکی از آن‌ها آن را پوشش می‌دهد. همین ناسازگاری توضیح می‌دهد چرا DNS در یک شبکه کار می‌کند و در شبکه دیگر با پروفایل یکسان شکست می‌خورد.

به یاد داشته باشید که مرورگرها می‌توانند resolver سیستم را دور بزنند

مرورگری با DNS امن فعال می‌تواند پرس‌وجوها را از طریق HTTPS به ارائه‌دهنده‌ای به انتخاب خود بفرستد و resolver سیستم‌عامل را کاملاً نادیده بگیرد. آن‌گاه سیستم درست به نظر می‌رسد در حالی که مرورگر شکست می‌خورد، یا برعکس. این پرسشی سیاستی برای مرورگر است، نه برای تونل.

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

حافظه نهان را پاک کنید و وظیفه واقعی را دوباره آزمایش کنید

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

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

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

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