تسريب DNS في VPN على Windows: لماذا يتفوق المقياس على المسار
يختار Windows الخادم المُحلِّل وفق مقياس الواجهة، لا وفق المسار وحده. وقد يُسرّب محوّل النفق استعلامات بينما تمر كل حزمة عبر النفق إذا جاء ترتيبه أدنى من Wi-Fi.
يغادر الاستعلام الجهاز ويصل إلى موجّه المنزل بينما تُمرَّر كل حزمة عبر النفق. والاستنتاج الطبيعي هو وجود مسار مفقود، والمسار يكون سليمًا في الغالب. ويستطيع Windows أن يختار أي واجهة يُستشار مُحلِّلها بحسب مقياس الواجهة، وكثيرًا ما يخسر محوّل النفق هذه المقارنة أمام الواجهة اللاسلكية.
تفسيران لتسريب واحد
يقول تفسير التوجيه إن جزءًا من حركة المرور يفلت من النفق، فلا بد أن المسار الافتراضي أو قائمة النفق المنقسم خطأ. وهذا التفسير قابل للاختبار بأمر واحد، ويكفي أن يشير المسار الافتراضي إلى داخل النفق لينتهي الأمر. افحصه أولًا لأنه رخيص، ثم ضعه جانبًا حين يعود سليمًا.
يقول تفسير الترتيب إن حركة المرور تمر كلها عبر النفق وأن الاستعلام ما زال يُرسل إلى مُحلِّل آخر. ويعامل Windows اختيار المُحلِّل كخاصية لكل واجهة لها ترتيب، لذا قد يوفّر محوّل مادي بمقياس أفضل استجابة 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 والمستهلكون الآخرون بالاختيار الذي اتخذوه سابقًا. أعد توصيل النفق أو أعد التشغيل قبل أن تستنتج شيئًا من نتيجة استعلام. فالاختبار المُبكّر يعيد السلوك القديم ويبدو كإصلاح فاشل.
ثم استعلم باسم داخلي واحد واسم عام واحد وتحقق أي خادم أجاب. ويشرح المرجع الخاص بالمقاييس التلقائية من Microsoft لماذا تُفضَّل القيمة الأدنى وكيف يُشتق الإسناد التلقائي.
اجعله يصمد بعد إعادة الاتصال
المقياس اليدوي على محوّل يُعاد إنشاؤه عند كل اتصال إعداد يزول. فإذا أعاد العميل بناء الواجهة، يحتاج التجاوز إلى سكربت بعد الاتصال أو سياسة أو تهيئة عميل تملك DNS أثناء الاتصال.
الخوادم المُهيّأة ساكنًا على المحوّل المادي تواجه مشكلة الاستدامة نفسها بالعكس. فهي تستمر في الإجابة عن تلك الواجهة حتى تُزال، وسيعيد DHCP تعبئتها من الإيجار التالي، لذا فإزالتها قياس لا تصميم. والتصميم المستدام هو سياسة تحليل أسماء للنطاق الداخلي، أو عميل يتولى ملكية DNS مدة الاتصال. وفي كلتا الحالتين سجّل قائمة المُحلِّلات قبل إعادة الاتصال وبعدها، وأعد المقياس الأصلي حين تنتهي من الاختبار، وتأكد من عودة السلوك السابق.