OpenVPN على المنفذ 53: ثلاث محادثات يخلط الناس بينها
البحث عن اسم نقطة النهاية، والنقل المشفّر، وDNS بعد النفق: ثلاث محادثات. حدّد المرحلة التي فشلت قبل تغيير منفذ أو خادم تحليل أسماء.
التقارير التي تقول إن VPN محجوب على المنفذ 53 تخلط بين ثلاث ملاحظات تفشل لأسباب مختلفة. فتحليل اسم نقطة النهاية يحدث قبل وجود أي نفق، والنقل المشفّر محادثة منفصلة، واستعلامات DNS التي تُجرى بعد ذلك محادثة ثالثة. ولكل واحدة منها بصمتها الخاصة في الفشل، وواحدة فقط منها تتعلق فعلاً بـ DNS.
رتّب الحزم حسب الغرض قبل أن تغيّر أي شيء، لأن الإصلاح يتبع المرحلة.
ثلاث محادثات، ورقم منفذ واحد
المحادثة الأولى هي تحليل اسم لنقطة النهاية: يسأل جهازك خادم التحليل المضبوط عنده عن مكان vpn.example.com، ويصل هذا الجواب عبر DNS عادي قبل أن يرسل العميل أي حزمة نفق واحدة. والثانية هي نقل OpenVPN نفسه، الذي يتصل بالعنوان الذي أنتجه التحليل، على أي بروتوكول ومنفذ يسمّيهما الملف الشخصي. والثالثة تحدث بعد أن يصبح النفق جاهزاً، حين تطلب التطبيقات أسماءً وتقرّر إعدادات التحليل المدفوعة من يجيب.
هذه الثلاث يمكن أن تنجح أو تفشل بشكل مستقل. فالعميل قد يحلّل نقطة نهايته تحليلاً مثالياً ومع ذلك يفشل في الوصول إلى المستمع، وقد ينشئ نفقاً بينما يفشل كل تحليل اسم داخلي لأن إعدادات DNS لم تصل قط.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
اقرأ الجدول كقائمة تحقق لا كوصف. فإذا لم يُحلّل اسم نقطة النهاية، فلا شيء لاحق يمكن أن يعمل، ولا يبدأ النفق أبداً.
رقم المنفذ لا يسمّي التطبيق
المنفذ 53 يحمل DNS بحكم العرف، ويمكن لمشغّل OpenVPN أن ينشر مستمعاً هناك أيضاً، وهذا بالضبط سبب كون الرقم معرّفاً ضعيفاً. جلسة OpenVPN على UDP 53 تبقى جلسة OpenVPN، واستعلام DNS إلى خادم على المنفذ 53 لا يقول شيئاً عن مدى السماح بنفق. سطرا proto و remote في الملف الشخصي يحدّدان نقطة النهاية الخارجية؛ ورقم المنفذ لا يحدّد شيئاً بذاته.
وهذا يقطع في الاتجاهين عند التشخيص: فمسبار UDP عام إلى المنفذ 53 يثبت أن منفذاً يجيب، لا أن خدمة VPN تجيب. اختبر بالعميل الحقيقي والملف الشخصي الحقيقي، لأن ذلك وحده يمارس المصافحة التي تتوقعها الخدمة.
أثبت وجود المستمع قبل لوم الشبكة
على الخادم، تحقّق مما هو مرتبط باستخدام ss -lunp | grep 53 وقارنه ببروتوكول الملف الشخصي ومنفذه. ومن شبكة العميل، شغّل العميل بدرجة إسهاب أعلى ليُظهر السجل أي عنوان ونقل حاول. فإن كان الخادم يستمع وحزم العميل لا تصل، فالمسار أو السياسة يرفضها، وذلك محادثة لمالك الشبكة وليس سبباً لتغيير المنافذ.
المنفذ المختلف يفيد فقط عندما تستمع الخدمة هناك فعلاً ويسمح النشر بذلك. ونقل مستمع للتهرّب من تصفية شبكة مُدارة قرار سياسة، لا خطوة استكشاف أخطاء. اسأل مالك الشبكة عمّا هو مسموح قبل تغيير الخدمة، لأن الحل الالتفافي الذي يخالف السياسة يُغلق لاحقاً على أي حال. سجّل ذلك الجواب بجانب الملف الشخصي حتى لا يكرّر الشخص التالي الطلب.
افحص DNS بعد النفق، بشكل منفصل
بعد أن يصبح النفق جاهزاً، افحص حالة خادم التحليل على واجهة VPN واسأل عن اسم داخلي واحد واسم عام واحد. فإن فشلت الأسماء الداخلية بينما يحمل النفق حركة، فإعدادات DNS المدفوعة لم تُطبَّق، وهذه مسألة تكامل عميل لا مسألة نقل. وإن فشلت الأسماء العامة ونجحت الداخلية، فسياسة النفق المنقسم تفعل ما ضُبطت على فعله.
أبقِ تغييرات DNS عند مالك خادم التحليل. فكتابة إعداد تحليل مُدار لتنجح تجربة واحدة يمكن أن تكسر الأسماء الخاصة لكل شيء آخر على الجهاز. وإن دفع النفق خادم تحليل وتجاهله العميل، فأصلح تكامل العميل بدلاً من إضافة إدخال ثابت في مكان آخر. الإدخالات الثابتة تخفي الفشل حتى يغيّر أحد الشبكات. اكتب أي خادم تحليل يُتوقع أن يجيب عن كل نطاق أسماء.