لماذا تعيد نقطة الاتصال توجيه DNS قبل اتصال VPN؟
تعيد نقطة الاتصال كتابة الاستعلامات على شبكتها، ويُحلّ اسم المضيف قبل وجود أي نفق. تتبّع أي أداة حل أجابت عن كل استعلام.
يضع الانضمام إلى شبكة فندق قرارين متعلقين بـ DNS أمامك في لحظتين مختلفتين: الاستعلامات التي يجريها الجهاز أثناء تسجيل الدخول، والاستعلامات التي تُجرى بعد أن يصبح النفق جاهزًا. يمكن لنقطة الاتصال أن تؤثر في الأول عبر الشبكة التي تتحكم بها. أما الثاني فيعتمد على سياسة العميل نفسه، وهي أمر منفصل يستحق الفحص.
تتبّع الاتصال بالترتيب، من أول تأجير DHCP إلى الاستعلام الذي حلّ اسمًا خاصًا. عندئذ ينفصل بشكل واضح فشلان يبدوان متطابقين في تذكرة الدعم: أحدهما وقع قبل وجود النفق، والآخر وقع داخله.
ما يمكن لنقطة الاتصال أن تمسّه وما لا يمكنها
تمنح شبكة الوصول عنوان أداة حل عبر DHCP، ويمكنها اعتراض المنفذ 53 نحو ذلك العنوان. وهذا يكفي للإجابة عن كل استعلام غير محمي بعنوان بوابة أو صفحة حجب. ويكفي أيضًا لكسر عميل VPN كُتب عنوان نهايته على شكل اسم مضيف.
ما لا تستطيع نقطة الاتصال فعله هو قراءة استعلام أو إعادة كتابته بمجرد أن يسير داخل نفق قائم، بافتراض أن النفق يحمله فعلًا. فالاعتراض يعتمد على رؤية السؤال بنصه الصريح.
تغادر الاستعلامات النفق على أي حال لأسباب لا علاقة لها بنقطة الاتصال: إعداد DNS الآمن في المتصفح، أو قاعدة split-DNS تُبقي لاحقة مؤسسية على أداة الحل المحلية، أو عميل مُهيّأ لاستبعاد DNS من النفق. كل واحد منها خيار من جهة العميل، وكل واحد يبدو كتدخل من نقطة الاتصال عند النظر من الخارج.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
البحث الأولي يحدث قبل وجود النفق
العميل الذي يُعطى اسم مضيف يجب أن يحلّه أولًا، وفي تلك اللحظة لا يحمي أي نفق الاستعلام. إن أجابت نقطة الاتصال بعنوان بوابة، فشل التفاوض أو تعطّل. وإن أجابت بلا شيء، يبلّغ العميل عن خطأ اسم ولا يبدأ النفق أبدًا. وأي من النتيجتين يفسّر سجل نفق فارغ يبدو بريئًا في غير موضعه.
تشغّل أنظمة التشغيل فحوصات الاتصال واكتشاف البوابة الخاصة بها أيضًا، كما ورد في RFC 8910 وRFC 8952، وتلك الطلبات تخرج قبل أن يكون أي VPN جاهزًا. ورؤيتها في سجل وكيل سلوك متوقع لا دليل على تسريب.
الإصلاح العملي هو منح العميل عنوان نهاية لا يحتاج إلى بحث. وعندما يكون ذلك مستحيلًا، أكمل تسجيل الدخول أولًا ثم اتصل بعد ذلك.
اكتشف أي أداة حل أجابت
اسأل النظام لا المتصفح، ونفّذ الاستعلام مرتين: مرة عبر أداة الحل التي يستخدمها الجهاز حاليًا، ومرة ضد عنوان ثابت.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
الإجابة من الأمر الأول التي تختلف عن الثالثة تخبرك أن أداة الحل المحلية تعيد شيئًا آخر، وهذا ما تفعله نقطة اتصال تعيد التوجيه. وفشل من الثالثة مع نجاح من الأولى يشير إلى البوابة: أداة الحل المحلية قدّمت عنوان تسجيل دخول بينما أُسقط المنفذ 53 الصادر. أما انتهاء المهلة في الاثنين فيعني أن الشبكة تتجاهل DNS حتى يكتمل التحقق.
أعد بعد الاتصال وقارن. الإجابة المخزّنة مؤقتًا تبقى بعد الانتقال، لذا امسح ذاكرة التخزين المؤقت أو استعلم عن اسم جديد للملاحظة الثانية.
أبقِ الاستعلامات اللاحقة على المسار الذي أردته
ملف النفق الكامل الذي يلتقط DNS أيضًا هو أبسط ترتيب: كل استعلام من كل تطبيق يذهب إلى أداة الحل التي يدفعها النفق، ولا ترى الشبكة المحلية سوى حركة مشفّرة. أثبت ذلك بحل اسم داخلي واسم عام بعد الاتصال، ثم قارن الإجابتين بما تعيده أداة حل النفق وحدها.
يحتاج split-DNS إلى قائمة نطاقات مكتوبة بقصد: اللواحق المؤسسية عبر النفق، وكل شيء آخر محليًا، ولا تداخل بين الاثنين.
يقف DNS الآمن في المتصفح خارج تلك السياسة، فإن كان لا بد من إيقافه ليسلك الملف بانتظام، فأوقفه لذلك الملف لا للجهاز كله. افعل ذلك في إعدادات المتصفح، لا بتحرير أداة حل النظام، ليكون التغيير ظاهرًا في المرة القادمة. سجّل الإجابة وأداة الحل ومرحلة الاتصال في سطر واحد لكل اختبار. التقرير الذي يقول إن DNS فشل على Wi-Fi الفندق يصف عرضًا له ثلاثة أسباب مختلفة على الأقل.