DNS لنقطة نهاية AWS Client VPN: لماذا يفشل تثبيت عنوان IP الذي تم تحليله

في الأسبوع الماضي أعطاك dig +short عنوانًا واحدًا لاسم نقطة النهاية في ملف تعريف AWS Client VPN، واتصل النفق. هذا الأسبوع يبقى الملف نفسه عند 'Connecting' على حاسوبك المحمول بينما نسخة زميلك التي لم تُمَس ما زالت تعمل. لم يُحجب شيء ولم تنته صلاحية الشهادة. استبدل أحدهم اسم مضيف نقطة النهاية بذلك العنوان المُحلَّل، ولم تعد الخدمة تستجيب هناك. الاسم المُصدَّر هو الجزء المصمم ليصمد أمام هذا التغيير.

قد لا يكون الاسم في ملفك هو الاسم الذي يجري الاستعلام عنه

كثيرًا ما تحمل الملفات المُصدَّرة من Client VPN الخيار remote-random-hostname. وعند تفعيل هذا الخيار يبني العميل تسمية عابرة، ويصلها باسم نقطة النهاية بنقطة، ثم يحل الاسم المركب. سجل حرف البدل في منطقة نقطة النهاية يستجيب لأي تسمية، ولهذا يظل بادئة مُختلَقة قابلة للحل، ولهذا تبقى هذه الحيلة غير مرئية عندما تحاول إعادة إنتاج الاستعلام يدويًا.

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

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

لماذا لا يمكن لإجابة محفوظة أن تبقى صحيحة

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

الإجابة نفسها في /etc/hosts ترث التاريخ نفسه مع مشكلة إضافية. فسجل hosts يبقى بعد إعادة التشغيل وإعادة التصدير وإصلاحات 'أعد تثبيت العميل'، لذا يعود الفشل كلما انتقل العنوان. رأيت سجلًا منها يبقى غير مؤذٍ لأسابيع، ثم يعطّل كل جهاز يحمله بينما تتصل التثبيتات الجديدة طبيعيًا. هذا الانقسام، مجموعة تفشل وأخرى تعمل على الحساب نفسه، أرخص دليل ستحصل عليه.

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

ما تتحقق منه الخدمة عند قيام النفق

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

وهو ليس قاعدة عامة عن بروتوكولات VPN أيضًا. فـ remote الرقمي صالح تمامًا في نشر OpenVPN عادي، وكثير منها يعمل بهذه الطريقة. القيد يأتي من الترتيب المُدار، لا من البروتوكول تحته.

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

قوائم السماح والخروج وDNS الخاص ثلاث مشكلات منفصلة

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

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

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

عائلة العناوين تنتمي إلى القائمة نفسها. إجابة IPv4 لا تقول شيئًا عن المسار المسموح لنقطة نهاية IPv6 أو مزدوجة الحزمة، لذا فلالتقاط في عائلة واحدة ليس دليلًا على الأخرى.

افحص اتصالًا دون تثبيت أي شيء

ابدأ من الملف كما صُدِّر واقرأ ما يطلبه فعليًا:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

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

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

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

قبل أن تغلق الأمر: الملف ما زال يحمل اسم نقطة النهاية المُصدَّر، ولا ملف hosts يثبّت العنوان، وremote في سجل العميل يطابق حلًا حاليًا، وقاعدة جدار الحماية تسمي نقطة النهاية لا عنوانًا. هذه أيضًا الحالة التي تسلّمها للشخص التالي.