اسمح بـDNS فقط عبر مُحلِّل VPN الخاص بك: دليل تنفيذ خطوة بخطوة
تابع عملية بحث واحدة عن اسم من المتصفح حتى الإجابة. اعرف أين يُختار المُحلِّل، وأين تفرضه الجدار الناري، وما لا تغطيه قاعدة المنفذ 53 أبدًا.
تابع عملية بحث واحدة عن اسم من اللحظة التي تكتبها فيها. يسأل المتصفح نظام التشغيل، ويسأل نظام التشغيل المُحلِّل الذي تختاره سياسته، ويخرج الاستعلام عبر واجهة ما بنقل ما. يقول تصميم VPN لديك إن الإجابة يجب أن تأتي من مُحلِّل محدد عبر مسار محدد. والفجوة بين هذين القولين هي ما تضبطه ثم تفرضه.
الخطوة 1: سمِّ المُحلِّل والمسار
اكتب ثلاثة أشياء قبل أن تلمس الجدار الناري: عنوان المُحلِّل، والبروتوكول والمنفذ اللذان تتوقعهما، والواجهة التي يجب أن يخرج منها الاستعلام. بدون هذه القائمة تكون القاعدة تخمينًا عن حركة المرور لا تنفيذًا لقرار. يمكن لـVPN أن يحمل بيانات التطبيقات بينما يتبع DNS ترتيبًا منفصلًا، وهذا ليس خطأً في حد ذاته، بل هو ما يحدث عندما لا يخبر أحد العميل بغير ذلك.
تسمية المسار صراحةً هي الفرق بين تصميم ومصادفة. وهي تعطيك أيضًا شيئًا تختبره لاحقًا، لأن كل ملاحظة يمكن مقارنتها بتوقع مكتوب. احتفظ بتلك القائمة في تذكرة التغيير لا في ذاكرة أحدهم.
الخطوة 2: اضبط السياسة حيث تسكن فعلًا
اختيار المُحلِّل من شأن العميل: إعداد الشبكة في نظام التشغيل، أو إعدادات عميل VPN نفسه، أو سياسة متصفح مُدارة. اضبطه هناك أولًا بالآلية التي تدعمها المنصة، لأن الجدار الناري لا يستطيع أن يجعل العميل يختار مُحلِّلًا لم يُخبر به قط. في عميل النفق المنقسم، قل صراحةً أي النطاقات تذهب إلى المُحلِّل الداخلي. وفي أسطول مُدار قد تكون سياسة المتصفح الرافعة الوحيدة لـDoH، لأن المتصفح يستطيع اختيار مُحلِّله المشفَّر باستقلال عن إعداد النظام.
إن تجاوزت هذا وذهبت مباشرة إلى الجدار الناري حصلت على قاعدة تسمح بالمُحلِّل الصحيح مع عميل لا يستخدمه أبدًا. تبدو القاعدة صحيحة وتبقى سجلات المُحلِّل فارغة، وهما أمران مربكان عند التصحيح. اضبط الاختيار أولًا ثم افرضه.
الخطوة 3: افرض المسار بضيق
أضف الآن إذن الشبكة للمسار المسموح: عنوان المُحلِّل، والبروتوكول والمنفذ، والواجهة التي يجب أن يخرج منها. أبقِ القاعدة محدودة بذلك المُحلِّل بدلًا من السماح بكل DNS الصادر. المسارات الثلاثة أدناه هي ما يستطيع عميل حديث سلوكه، والأول فقط هو ما تغطيه قاعدة المنفذ 53.
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
حجب DoH وDoT مشروع؛ أما افتراض أن قاعدة المنفذ 53 حجبتهما بالفعل فليس كذلك. المتصفح الذي يستخدم DoH يحل الأسماء عبر مسار لم تصفه قاعدتك قط، والتطبيق الذي يحمل مُحلِّله الخاص يفعل الشيء نفسه. اكتب كل مسار تنوي السماح به وكل مسار تنوي رفضه. القاعدة التي لا تسمي مسارًا لم تتخذ قرارًا بشأنه.
الخطوة 4: تتبَّع الأسماء الخاصة والعامة
يرسل DNS المنقسم عمدًا النطاقات الخاصة فقط إلى مُحلِّل داخلي بينما تذهب الأسماء العامة إلى مكان آخر، لذا وجود أكثر من مُحلِّل في التصميم ليس تسريبًا. التسريب هو استعلام كان يجب أن يذهب إلى مُحلِّلك فيصل إلى مكان آخر، أو مسار مقصود غير قابل للوصول يجعل العميل يرتد بصمت. هاتان الحالتان هما ما تبحث عنه. تتبَّع اسمًا داخليًا واسمًا عامًا تحت السياسة المقصودة وسجِّل أي مُحلِّل أجاب عن كل منهما.
موقع اختبار يبلِّغ عن مُحلِّلك هو تلميح لا دليل، لأنه لا يرى إلا الاستعلامات التي وصلته. التقط الاستعلام على جانب العميل حين تحتاج إلى معرفة المسار الذي سلكه فعلًا، ثم قارن الملاحظتين. وعندما تختلفان تكون قد وجدت ارتدادًا لم يوثقه أحد.
إذا كان عنوان المُحلِّل صحيحًا لكنه غير قابل للوصول، فالمشكلة في التوجيه أو التصفية لا في السياسة. تتبَّع الاستعلام إلى ذلك العنوان وتأكد من أن الإجابة تعود على الواجهة المتوقعة قبل تغيير أي إعداد للمُحلِّل.
الخطوة 5: أبقِ طريقًا للعودة
قبل تشديد الوصول إلى DNS على البوابة، أكِّد طريقة استرجاع لا تعتمد على حل الأسماء. فالمُحلِّل المعطوب يجعل كل أداة إصلاح أصعب وصولًا، بما فيها تلك التي ستستخدمها للتراجع عن التغيير. أبقِ وحدة تحكم محلية أو مسارًا خارج النطاق مفتوحًا حتى تُثبت السياسة الجديدة. ولا تزله إلا بعد أن تصمد السياسة أمام إعادة اتصال.
بعد إعادة اتصال أو تحديث لسياسة المتصفح، افحص الحالة الفعلية مرة أخرى، لأن كليهما قد يغيّر المُحلِّل دون أن يغيّر قاعدتك. المطلوب مستلم معروف ومسار محمي للاستعلامات، لا لافتة مُحلِّل مطمئنة في لقطة شاشة واحدة. ومواصفة RFC 8484 لـDNS over HTTPS هي المرجع للمسار المشفَّر الذي لا تراه قاعدة المنفذ لديك.