مرشّح DNS في VPN: حجب الأسماء لا يحجب الإعلانات

يمكن لسطر واحد في dnsmasq أن يجيب عن اسم بـ NXDOMAIN، وهذه هي الآلية كلها. فهو لا يقرأ HTML أبدًا، ولا يفحص مسار الطلب، ولا يرى ما يفعله تطبيق باتصال فتحه بالفعل. لذلك فإن مقارنته بإضافة متصفح هي مقارنة بين مهمتين مختلفتين. الأولى تقرر ما إذا كان الاسم يُحلّ؛ والثانية تقرر ما يحدث بعد ذلك.

ما الذي يتحكم فيه مرشّح الأسماء فعلًا

الخيار address=/metrics.example/، دون أي شيء بعد الشرطة الأخيرة، يجعل المُحلِّل يعيد NXDOMAIN لذلك الاسم ونطاقاته الفرعية. ترك العنوان فارغًا هو الجزء المهم: فهو يمنع إرسال العملاء إلى خادم بديل لا علاقة له بالموضوع، أو الادعاء بأن عنوان الاسترجاع هو الوجهة الحقيقية. ويصف دليل dnsmasq هذا الشكل بأنه إجابة سلبية لا إعادة توجيه.

كل ما يمكن للقاعدة فعله ينبع من ذلك القرار الواحد. العميل الذي يسأل هذا المُحلِّل يحصل على إجابة سلبية؛ والعميل الذي يسأل مُحلِّلًا آخر يحصل على ما يقوله ذلك المُحلِّل. ولا يعرف المرشّح شيئًا عن المسار أو سلسلة الاستعلام أو الحساب الذي كان التطبيق سيستخدمه.

هذه الدقة مهمة لأن اسم مضيف واحد يخدم غالبًا أغراضًا عدة. يمكن لنقاط تسجيل الدخول والصور والتتبع أن تتشارك نطاقًا واحدًا، والقاعدة التي تحذف الاسم كله قد تحذف معه سير عمل كاملًا. وعلى سياسة على مستوى الاسم أن تقبل هذه المقايضة أو تختار أسماء أضيق.

أين يختلف مانع الإعلانات في جانب العميل

ترى إضافة المتصفح الطلب قبل خروجه، فيمكنها مطابقة مسار URL وإلغاء طلب محدد وإخفاء العنصر الذي كان سيعرض النتيجة. ويمكنها السماح بـ example.com/article مع رفض example.com/ads/، وهو ما لا تستطيع أي إجابة DNS التعبير عنه. هذه الرؤية على مستوى المسار هي القدرة التي لا يملكها المُحلِّل ببساطة. وهي أيضًا سبب ندرة أن تعمل قائمة تصفية بُنيت لأداة واحدة بالطريقة نفسها في الأداة الأخرى.

الثمن هو النطاق. تلك الحماية تعيش داخل متصفح واحد، في ملف تعريف واحد، على جهاز واحد، وتختفي حين ينتقل المستخدم إلى تطبيق آخر. أما مرشّح DNS المهيأ على البوابة فيغطي كل جهاز يستخدم مُحلِّل البوابة، بما في ذلك أجهزة لا يمكن تثبيت أي إضافة عليها.

لا يكتمل أي من الترتيبين بمفرده. فمرشّح DNS لا يستطيع إزالة معرّف أرسلته الصفحة بالفعل، وإضافة المتصفح لا تستطيع حماية تطبيق لا يحمّلها أبدًا.

مسار المُحلِّل هو ما يحدد إن كان أي من ذلك ينطبق

يمكن لـ VPN أن يعلن خادم DNS ومع ذلك لا يستقبل كل استعلام. فالمتصفح المهيأ بـ DNS مشفّر، أو التطبيق الذي يملك مُحلِّلًا خاصًا به، أو الجهاز على مسار شبكة يستبعد البوابة، كلها ستنظر في مكان آخر. وتقدم منصات الهواتف المحمولة بشكل متزايد إعداد DNS خاص يتجاوز بهدوء ما يقترحه النفق.

لذا اختبر المسار لا السياسة. استعلم من المُحلِّل المقصود مباشرة من البوابة، ثم استعلم منه من عميل وقارن، ثم راقب ما إذا كان اسم يجب حجبه يفشل فعلًا في التطبيق الذي يشغله المستخدم.

الإجابات المخزنة في الذاكرة والمقابس المفتوحة تجعل ذلك مشوشًا. فالصفحة التي حمّلت مواردها بالفعل ستستمر في العمل بعد تغيير القاعدة، لذا فإن اتصالًا جديدًا اختبار أفضل من إعادة تحميل علامة تبويب قديمة.

اختبر الاتجاهين قبل أن تعلن نتيجة

استخدم اسم توثيق محجوبًا عمدًا، واسمًا عامًا مسموحًا، واسمًا خاصًا يحتاجه الخدمة:

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

الإجابة الفارغة للاسم المحجوب، وعنوان عادي للاسم العام، وعنوان خاص للاسم الداخلي، تُظهر مجتمعة أن التصفية والتحليل من المنبع والسجلات المحلية تعمل جميعًا. وإن فشلت الثلاثة، فأنت تنظر إلى مشكلة في المنبع أو في المستمع لا إلى مشكلة تصفية.

أبقِ الادعاء ضيقًا في كل ما تنشره داخليًا. فهذه تصفية نطاقات على مُحلِّل، لا فحص محتوى، ولا تصفية مسارات، ولا وعدًا بأن لا أحد يُتتبَّع. اذكر مالك السياسة ومسار الاستثناء ومدة الاحتفاظ بالاستعلامات إلى جانب القواعد، لأن المرشّح الذي يسجل كل بحث يتحمل تكلفة خصوصية خاصة به.