توقف تحليل أسماء DNS بعد أن يحجب مفتاح الإيقاف في VPN المنفذ 53
يمكن لمفتاح الإيقاف أن يحجب DNS عمدًا. قارن بين التحليل داخل النفق فقط واستثناء لمحلّل محلي، ثم حدّد أي طبقة فشلت فعلًا.
عندما يُسقط مفتاح الإيقاف النفق، فإنه يأخذ معه مسار DNS، والمحلّل الذي يبقى في الخلف نادرًا ما يكون الذي تتوقعه. هناك تصميمان يتعاملان مع تلك اللحظة بطريقتين مختلفتين جدًا: حجب كل حزمة DNS لا تقع داخل النفق، أوإبقاء محلّل واحد قائمًا كاستثناء. كلاهما أمر يمكن الدفاع عنه. من علامة تبويب في المتصفح تبدو الأعراض متطابقة تقريبًا، لذا فإن المهمة الأولى هي تحديد التصميم الذي نشرته فعلًا.
أُبقي هذا التمييز أمامي لأن الإصلاح معاكس في كل حالة. أحد التصميمين يحتاج استثناءً أوسع، والآخر يحتاج استثناءً أضيق. التخمين يكلّفك إما الخصوصية أو بعد ظهر كامل.
تصميمان لـ DNS من أجل العطل نفسه
يعامل التصميم A المحلّل كأي خدمة أخرى خلف النفق. تسمح قواعد جدار الحماية بالمنفذين UDP و TCP 53 على واجهة النفق فقط، والعنوان الذي يُسلَّم للعميل هو محلّل داخل النفق. عندما يسقط النفق تتوقف عمليات البحث، وهذه هي النتيجة المقصودة وليست عطلًا.
يُبقي التصميم B محلّلًا متاحًا على الشبكة المحلية، عادةً الموجّه على 192.168.1.1 أو برنامج النظام الوسيط على 127.0.0.53، على أساس أن تحليل الأسماء لا ينبغي أن يموت مع النفق. هذا مريح في شبكة منزلية حيث يقوم الموجّه بالتحليل لكل المنزل. أما على شبكة Wi-Fi في فندق أو مطار، فإن الاستثناء نفسه يشير إلى خادم شخص آخر، ويُكشف كل اسم تكتبه رغم بقاء حركة الويب محجوبة.
الحد الفاصل هو مَن يملك المحلّل. إن كنت تثق بالمحلّل المحلي، فالاستثناء ثغرة صغيرة وصادقة. وإن لم تثق به، فتصميم النفق فقط هو الوحيد الذي يصمد، والثمن أن النفق الساقط يأخذ معه كل الأسماء.
لماذا لا يزال بحث عميل VPN نفسه يعمل
على العميل أن يحلّل اسم مضيف البوابة قبل وجود النفق، لذلك يجب ألا يغطي الحجب الصارم مسار الإقلاع الخاص بالعميل. معظم العملاء إما يخزّنون عنوان نقطة النهاية مؤقتًا أو يوفّرون استثناء إقلاعًا موثّقًا لذلك المضيف وحده. وإذا حجبت مجموعة قواعدك ذلك البحث، فلن يعود النفق أبدًا وستُظهر السجلات عميلًا لا يستطيع الوصول إلى خادمه، وهذا عيب في السياسة لا في DNS.
تحليل DNS المنقسم هو الموضع الآخر الذي يظهر فيه ذلك. يدفع العميل نطاقًا داخليًا إلى محلّل خاص ويترك كل شيء آخر للمحلّل النظامي. بعد السقوط، قد تُحلَّل الأسماء العامة بينما تنتهي مدة الأسماء الداخلية، لأن النطاق الخاص لم يبقَ له مسار. بالنسبة للمستخدم هذا "الـ VPN كسر الإنترنت"، وبالنسبة لسجل المحلّل هو استعلام لم يصل قط.
في ظل systemd-resolved يمكنك رؤية الانقسام مباشرة.resolvectl statusيعرض خوادم DNS لكل وصلة ونطاقات التوجيه، وبعد سقوط النفق يظل النطاق الداخلي يشير إلى خادم على وصلة لم تعد موجودة. لا يزال الوسيط على 127.0.0.53 يقبل الاستعلام، ثم ينتظر مصدرًا أعلى لن يجيب، ولهذا يستغرق الفشل ثوانٍ بدلًا من العودة فورًا.
DNS المشفّر لا يتجاوز مرشّح الحزم
ينتقل DNS عبر HTTPS وDNS عبر TLS على 443 و853، لذا فالقاعدة التي تحجب المنفذ 53 لم تقل شيئًا عنهما. حجب "DNS" حسب المنفذ سياسة تتعلق بمنفذ، لا بتحليل الأسماء. إذا كان مفتاح الإيقاف يحجب كل حركة المرور خارج النفق، فإن DoH مشمول بالخطأ. وإذا استثنيت سماحًا لبوابة أسيرة أو محلّل عام، فهو غير مشمول.
عناصر التحكم في جهة العميل هي الرافعة الأرخص. يتخلى Firefox عن محلّل DoH الخاص به عندما لا يُحلَّل الاسم الكناريuse-application-dns.net، ولهذا تنشر الشبكات المُدارة ذلك النطاق كـ NXDOMAIN؛ ويمكن لسياسة المؤسسة تثبيته معطّلًا أيضًا. يمتلك Android Private DNS وDNS الآمن في Chrome مفاتيحهما وافتراضاتهما. إيقاف تلك العناصر أكثر موثوقية من ملاحقة عناوين المحلّلات، لأن قائمة العناوين تتغير ومجموعة قواعدك لا تتغير.
هناك نسخة من هذا لا علاقة لها بالتسريبات على الإطلاق. التطبيق الذي يثبّت محلّلًا ما يزال يحتاج إلى مسار شبكة للوصول إليه. التشفير يغيّر مَن يمكنه قراءة الاستعلام، لا ما إذا كانت الحزمة تستطيع مغادرة الجهاز، لذا فإن حجبًا للجهاز بأكمله يُبطل الإعداد دون أن يمسّه.
طابِق العَرَض مع الطبقة
معظم التقارير تصلك جملة واحدة، وعادةً ما تسمّي تلك الجملة الطبقة بالفعل. الجدول أدناه هو ما أستعرضه قبل لمس أي قاعدة؛ والهدف هو تحديد ما إذا كان الاستعلام قد حُجب أو وُجّه خطأً أو لم يُرسل أصلًا.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
الصفان الأولان هما ما يسيء الناس تشخيصه. السقوط الصامت والرفض يبدوان في المتصفح كـ"DNS معطل"، لكن واحدًا منهما فقط يعني أن مفتاح الإيقاف يؤدي عمله. الرفض يعني أن شيئًا قد أجاب، لذا فالحجب ليس حيث تظن.
استعد سياسة المحلّل ثم أثبتها
أصلح التصميم لا العَرَض. للتحليل داخل النفق فقط، اسمح بالمنفذ 53 على واجهة النفق، وادفع المحلّل الداخلي مع إعداد النفق، واترك الوصلة الفيزيائية بلا أي سماح لـ DNS. مع wg-quick، سطرDNS =هو ما يكتب المحلّل في إعداد الواجهة، لذا فالنفق الذي يحذفه يترك المحلّل القديم في مكانه وكل استعلام على المسار الخطأ. ويوثّقدليل wg-quickهذا السلوك لكل منصة.
ثم تحقّق بهذا الترتيب. على Linux يعرضresolvectl statusالوصلة النشطة، ويختبرdig +short example.comاسمًا عامًا، ويختبرdig @10.8.0.1 internal.example.comالاسم الخاص، ويعرضsudo tcpdump -ni any port 53أي واجهة تستخدمها الحزم أثناء تشغيل كليهما. على Windows يعطي كلٌّ منGet-DnsClientServerAddress -AddressFamily IPv4وResolve-DnsName example.comالحقيقتين نفسيهما: مَن المهيّأ، ومَن يجيب.
اختم بالاختبار السلبي. افصل النفق، وتأكد من فشل اسم عام جديد، وتأكد من فشل الاسم الخاص، وتأكد من عدم خروج أي حزمة على المنفذ 53 من المحوّل الفيزيائي. الحجب الذي يصمد للردود المخزّنة فقط لا يصمد إطلاقًا.
قائمة تحقق قبل إغلاق التذكرة:
- المحلّل المستخدم أثناء العطل هو الذي تقصده السياسة.
- بحث العميل عن نقطة النهاية لا يزال مسموحًا، عبر ذاكرة مؤقتة أو استثناء.
- DoH وDoT إما مشمولان بالحجب أو معطّلان بالسياسة.
- النطاقات الخاصة تفشل مغلقة، لا مفتوحة، بمجرد زوال النفق.