لماذا تفشل أسماء DNS الخاصة على عملاء VPN وأين يجب التحقق

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

قبل تحرير أي ملف تعريف، تحقق مما يفعله العميل بالاسم. في Linux يعرض resolvectl query files.corp.example أي وصلة وأي محلّل أنتجا الجواب. في Windows يعرض Resolve-DnsName files.corp.example الخادم الذي أجاب والعنوان الذي أعاده.

اقرأ الجواب قبل أن تغيّر أي شيء

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

هذا التقسيم الثلاثي يوفر ساعة من التخمين. ويخبرك أيضًا هل تحتاج إلى لمس الـ VPN أصلًا: الاسم الذي يُحلّ إلى العنوان الخاص الصحيح أثبت مسار المحلّل بالفعل، لذا يبقى العمل على مسار البيانات.

وزّع المحلّل من داخل النفق

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

OpenVPN ضمن المجموعة الأولى. على الخادم ينتقل push "dhcp-option DNS 10.8.0.53" ثم push "dhcp-option DOMAIN corp.example" عبر قناة التحكم، لكن فقط إذا كان pull ما زال ممكّنًا في إعداد العميل. العميل المحرَّر يدويًا والذي يحمل pull-filter ignore "dhcp-option" لن يراها أبدًا، وهذا السطر الواحد يفسّر عددًا مفاجئًا من حالات «الخادم يدفعها لكن حاسوبي لا يوافق».

أما WireGuard ففي المجموعة الثانية، لأن البروتوكول لا يتضمن أي تفاوض على الخيارات. يدخل المحلّل ونطاق البحث في كتلة [Interface] الخاصة بالعميل بصيغة DNS = 10.8.0.53, corp.example. ويطبّق wg-quick ذلك عبر resolvconf أو systemd-resolved، وعلى Windows يثبّت العميل الرسمي قواعد NRPT لا وجود لها إلا ما دام النفق قائمًا: يسردها Get-DnsClientNrptPolicy، وهذا يجعله طريقة سريعة لمعرفة هل طبّق العميل ملفك يومًا ما.

أما IPsec/IKEv2 فيقع في الوسط. تستطيع إضافة attr في strongSwan أن تعيد خادم DNS مأخوذًا من مجموعة، ويقبله عميل Windows عادة، لكن الملف التعريفي الذي يثبّت خادم الأسماء الخاص به يتغلب على كل ما تقدّمه البوابة. على عميل Linux فإن الخطوة اليدوية المكافئة هي resolvectl dns wg0 10.8.0.53 ثم resolvectl domain wg0 '~corp.example'؛ كلتاهما تختفي مع الواجهة، وهذا بالضبط ما تريده لإعداد محصور في النفق.

حدّد اللاحقة بدلًا من ابتلاع كل استعلام

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

أرسل إلى الداخل اللاحقة الخاصة وحدها. في systemd-resolved يكون النطاق الذي يبدأ بـ ~ للتوجيه فقط، لذا فإن ~corp.example يعني أن الاستعلامات تحت تلك اللاحقة تذهب إلى خوادم تلك الوصلة بينما يبقى كل شيء آخر مستخدمًا الشبكة الفعلية. ويفعل Windows الأمر نفسه بقواعد NRPT محدودة بنطاق أسماء، كما يفعل macOS بملف محلّل إضافي ضمن /etc/resolver/.

تستحق أسماء الإرسال المتعدد جوابًا خاصًا بها. أسماء .local محلية للوصلة بحكم التصميم (RFC 6762)، وواجهة tun من نقطة إلى نقطة لا تحمل مجموعة الإرسال المتعدد تلك، لذا فإن إضافة محلّل عام لن تنشرها، وسؤال محلّل داخلي أحادي الإرسال عنها يعيد NXDOMAIN. يستطيع عاكس مثل avahi في وضع العكس أن يجسر مقطعين، لكن ذلك قرار من جهة الخادم لا يستطيع أي عميل طلبه. وإن كان لا بد من الوصول إلى طابعة أو NAS بالاسم، فأعطه سجل A في منطقتك بدلًا من ذلك.

أثبت أن الجواب يستطيع العودة

الجواب الصحيح الذي يشير إلى عنوان لا يمكن الوصول إليه يبدو تمامًا كمشكلة محلّل حتى تتحقق من المسار. اسأل النواة إلى أين سيذهب الجواب: يسمّي ip route get 10.20.5.20 الواجهة، والأكثر فائدة، عنوان المصدر الذي سيستخدمه.

راقب عنوان المحلّل نفسه. العميل الذي لديه DNS = 10.8.0.53 إلى جانب AllowedIPs = 10.20.0.0/16 يرسل استعلاماته عبر بطاقة الشبكة الفعلية، حيث تموت بصمت، لأن المحلّل ليس داخل أي بادئة يدّعيها النفق. هذا التعارض هو أكثر الأعطال ذات السبب الواحد شيوعًا في هذا المجال كله، ويبقى غير مرئي ما لم تقارن إعداد DNS بالبادئات المسموح بها سطرًا بسطر.

تسبب النطاقات المتراكبة العطل المعاكس. الجواب صحيح، والمسار موجود، وهو يشير إلى مضيف خاطئ، لأن 192.168.0.0/24 في المنزل أكثر تحديدًا من مسار النفق إلى النطاق نفسه. أعد ترقيم جانب واحد أو ادفع مسارًا أضيق، ثم تحقق من جدار الحماية ومسار العودة لمضيف الخدمة؛ وتغطي ملاحظات strongSwan عن إعادة التوجيه جانب sysctl من ذلك المسار.

الشهادات تحقق هوية منفصل يلقي الناس اللوم فيه على DNS. إذا أبلغ المتصفح عن عدم تطابق في الاسم بدلًا من خطأ في الحلّ، فقد نجح البحث بالفعل والمطلوب إصلاحه هو SAN في الشهادة. اختبر HTTPS بالاسم، ولا تختبره أبدًا بالعنوان IP المجرد.

أعد الاختبار من العميل، لا من البوابة

اختبر داخل التطبيق الذي يشكو منه المستخدم، لأن البحث من سطر الأوامر لا يثبت أن المتصفح يسلك المسار نفسه. يمكن لـ DNS الآمن في Chrome ولـ network.trr.mode في Firefox أن يتجاوزا محلّل النظام كليًا، وحين يحدث ذلك فإن الاسم الخاص إما يفشل أو يتسرب إلى محلّل عام. ومقارنة resolvectl query بـ dig @10.8.0.53 files.corp.example مُشغَّل يدويًا تخبرك أي الحالتين حدثت.

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

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