هل يفشل DNS الخاص في Pritunl؟ أضف مسارًا ضيّقًا للمُحلِّل

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

تأكد من أن المُحلِّل يرفض مجموعة عملائك

ابدأ بإثبات أن الفشل يتعلق بالمصدر لا بإمكانية الوصول. من عميل متصل، استعلم من المُحلِّل الخاص مباشرة وراقب ما إذا كانت المهلة تنتهي أو يعود الرفض. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 وهو ينتهي بمهلة بينما ينجح الاستعلام نفسه من البوابة يشير إلى سياسة وصول على المُحلِّل. رد SERVFAIL يشير إلى مكان آخر تمامًا، عادةً إلى المنطقة أو المُمرِّر الأعلى.

دوّن عنوان العميل قبل الاختبار. ip -4 addr show tun0 على العميل، أو الإيجار المعروض في وحدة التحكم، يخبرك أي مجموعة يراها المُحلِّل.

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

أضف مسار مضيف واحد بدلًا من ترجمة كل شيء

تصف إرشادات DNS الخاص في Pritunl العلاج الضيّق: مسار /32 مُمكَّن بـ NAT لعنوان المُحلِّل، مع اختيار ذلك العنوان كخادم DNS للعملاء. يغيّر المسار المصدر الذي يراه المُحلِّل لحركة DNS فقط. تحتفظ حركة التطبيقات بتصميم الحفاظ على المصدر الذي اخترته لها.

اضبطه عبر مالك المسار المدعوم في الخادم بعد مراجعة المسارات الحالية بحثًا عن التداخل. في المثال أعلاه الوجهة هي 10.40.0.53/32 مع تمكين NAT، وتبقى مجموعة العملاء 10.90.0.0/24. لا تُترجم النطاق الخاص بأكمله لإصلاح خدمة واحدة، لأن كل سياسة لاحقة تعتمد على العنوان الحقيقي للعميل ستبدأ برؤية البوابة بدلًا من ذلك. تأكد من العنوان الذي يستقبله المُحلِّل فعليًا بمراقبة سجل استعلاماته أثناء بحث تجريبي. مسار المضيف وحده لا يثبت شيئًا عن الترجمة أو الإذن.

لا يزال على المُحلِّل أن يسمح بالمصدر المُترجَم على UDP وTCP، ويجب أن تتمكن ردوده من العودة. تغيير المصدر لا يمكن أن ينشئ منطقة أو سجلًا مفقودًا.

قرّر ما إذا كان الخادم أو العميل يرسل الاستعلام

يوثّق Pritunl أيضًا ترتيب وكيل DNS مرتبطًا بـ VPN Client DNS Mapping، حيث يعيد الخادم توجيه استعلامات المنبع نيابة عن العملاء. في هذا النموذج ينتمي مصدر المنبع إلى سياق شبكة الخادم نفسه، والاستثناء على جانب العميل هو الحل الخاطئ.

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

اختبر بحثًا خاصًا لا صفحة ويب عامة

بعد تطبيق التغيير وإعادة الاتصال، افحص إعدادات المُحلِّل الفعلية للعميل، ثم حُلّ اسمًا تعرف أنه موجود فقط في المنطقة الخاصة. dig intranet.example.net دون خادم صريح يوضح ما يستخدمه العميل فعليًا. اتبعه بطلب إلى العنوان الذي أرجعه ذلك البحث، لأن الحل والوصول إلى الخدمة خطوتان منفصلتان. المتصفح الذي يحمّل مواقع عامة عبر DNS-over-HTTPS لا يثبت شيئًا عن مسار المُحلِّل الخاص في نظام التشغيل. كما أن المُحلِّل الثانوي العام ليس مرجعًا لنطاق داخلي.

سجّل عنوان المُحلِّل ومسار /32 وإعداد DNS للعميل معًا في ملاحظات الخادم. نصف هذا الإعداد إذا استُعيد وحده يعيد إنتاج الفشل الأصلي.

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