نشت DNS در VPN ویندوز: چرا متریک بر مسیر پیروز می‌شود
ویندوز حل‌کننده را بر پایه متریک رابط انتخاب می‌کند، نه فقط بر پایه مسیر. آداپتور تونلی که پایین‌تر از Wi-Fi رتبه گرفته باشد می‌تواند جست‌وجوها را نشت دهد، در حالی که هر بسته همچنان از تونل می‌گذرد.
یک پرس‌وجو دستگاه را ترک می‌کند و به روتر خانه می‌رسد، در حالی که هر بسته از تونل عبور می‌کند. نتیجه طبیعی یک مسیر گمشده است، و مسیر معمولاً سالم است. ویندوز می‌تواند با متریک رابط انتخاب کند که حل‌کننده کدام رابط پرسیده شود، و آداپتور تونل اغلب این مقایسه را به رابط بی‌سیم می‌بازد.
دو توضیح برای یک نشت
توضیح مسیر می‌گوید بخشی از ترافیک از تونل بیرون می‌زند، پس مسیر پیش‌فرض یا فهرست تونل تقسیم‌شده باید اشتباه باشد. این توضیح با یک فرمان آزمون‌پذیر است، و وقتی مسیر پیش‌فرض به داخل تونل اشاره کند کار تمام است. ابتدا آن را بررسی کنید چون ارزان است، و سپس وقتی پاک برگشت کنارش بگذارید.
توضیح رتبه‌بندی می‌گوید ترافیک کاملاً در تونل است و پرس‌وجو همچنان به حل‌کننده دیگری فرستاده می‌شود. ویندوز انتخاب حل‌کننده را ویژگی هر رابط با یک ترتیب می‌داند، پس یک آداپتور فیزیکی با متریک بهتر می‌تواند DNS یک نام را تأمین کند حتی اگر بسته‌های نشانی حل‌شده از تونل بروند. هر دو توضیح همان نشانه را در صفحه آزمون نشت پدید می‌آورند، به همین دلیل آزمون تشخیص نیست. تنها یکی از آن‌ها با ویرایش مسیرها درست می‌شود.
متریک‌ها و حل‌کننده‌ها را با هم بسنجید
تا وقتی تونل بالاست، رابط‌ها، متریک‌هایشان و سرورهای پیکربندی‌شده‌شان را ثبت کنید. آن‌ها را به شکل جدول بخوانید نه دو فهرست جدا، چون پرسش این است که کدام حل‌کننده اول است، نه اینکه چه حل‌کننده‌هایی وجود دارند.
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddressesاگر آداپتور تونل عددی بالاتر از آداپتور فیزیکی داشته باشد، حل‌کننده آن ترجیح داده نمی‌شود و نام داخلی به آنچه سمت فیزیکی عرضه می‌کند می‌رود. آن روتر می‌تواند از حافظه نهان پاسخ دهد، پرس‌وجو را جلو بفرستد یا رد کند، و هیچ‌یک از این نتیجه‌ها همان طراحی مورد نظر شما نیست. رتبه‌بندی یک ترجیح است، پس بی‌صدا می‌بازد و خطا نمی‌دهد.
آداپتور تونلی که هیچ حل‌کننده‌ای برایش پیکربندی نشده باشد گونه‌ای به همان اندازه رایج است. کارخواه رابط را بدون فرستادن DNS بالا می‌آورد، پس پرسش رتبه‌بندی حتی پیش نمی‌آید.
تونل را بالا ببرید و دوباره بررسی کنید
در یک پوسته با دسترسی بالا، به رابط تونل پایین‌ترین متریک را بدهید یا مقدار آداپتور فیزیکی را بالا ببرید. هر دو تنظیم‌های هر رابط هستند و هر دو برگشت‌پذیرند، و این وقتی مهم است که ماشینی را تغییر می‌دهید که شاید پشتش نشسته نباشید.
Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetricتغییر بی‌درنگ دیده می‌شود، و کارخواه DNS و دیگر مصرف‌کننده‌ها انتخابی را که پیش‌تر کرده‌اند در حافظه نهان نگه می‌دارند. پیش از استنباط هر چیزی از نتیجه پرس‌وجو، تونل را دوباره وصل کنید یا راه‌اندازی دوباره کنید. آزمونی که خیلی زود اجرا شود رفتار قدیمی را بازتولید می‌کند و مانند یک اصلاح ناکام به نظر می‌رسد.
سپس یک نام داخلی و یک نام عمومی را بپرسید و بررسی کنید کدام سرور پاسخ داد. مرجع متریک‌های خودکار مایکروسافت توضیح می‌دهد چرا کمترین مقدار ترجیح داده می‌شود و تخصیص خودکار چگونه به دست می‌آید.
ماندگاری در برابر اتصال دوباره
متریک دستی روی آداپتوری که در هر اتصال دوباره ساخته می‌شود تنظیمی است که ناپدید می‌شود. اگر کارخواه رابط را از نو بسازد، این بازنویسی به اسکریپت پس از اتصال، سیاست یا پیکربندی کارخواهی نیاز دارد که تا زمان اتصال مالک DNS باشد.
سرورهای ایستا پیکربندی‌شده روی آداپتور فیزیکی همان مشکل دوام را وارونه دارند. آن‌ها تا زمانی که برداشته شوند برای آن رابط پاسخ می‌دهند، و DHCP آن‌ها را از اجاره بعدی دوباره پر می‌کند، پس برداشتنشان یک اندازه‌گیری است نه یک طراحی. طراحی بادوام سیاستی برای حل نام برای فضای نام داخلی است، یا کارخواهی که برای مدت اتصال مالکیت DNS را بر عهده بگیرد. در هر حال، فهرست حل‌کننده‌ها را پیش و پس از اتصال دوباره ثبت کنید، وقتی آزمون تمام شد متریک اصلی را بازگردانید و تأیید کنید که رفتار پیشین بازگشته است.