DNS في AWS Client VPN: استخدم محلل VPC لا الشبكة الفرعية

تقع نقطة النهاية في 10.0.8.0/24، لذا يجب أن يكون المحلل 10.0.8.2. هذا هو التفكير الذي أسمعه كثيراً، وهو خطأ من ناحيتين. يجيب Route 53 Resolver على نطاق IPv4 الأساسي لـ VPC زائد اثنين، وهو بالنسبة إلى VPC من 10.0.0.0/16 يساوي 10.0.0.2 أياً كانت الشبكة الفرعية التي تستخدمها نقطة النهاية. الخطأ الثاني أخفى: وضع العنوان الصحيح في نقطة النهاية لا يعني أن نظام تشغيل العميل يسأله عن أي شيء. ينتج الخطآن العَرَض نفسه: تحليل أسماء يعمل لدى بعض العملاء ويفشل لدى آخرين.

الأسطورة تبدأ من ارتباط الشبكة الفرعية

الارتباط يتعلق بمكان وجود واجهات الشبكة المرنة لاتصالات العملاء، لا بأي عنوان محلل موجود. تمنح الشبكات الفرعية لنقطة النهاية العملاء عنواناً داخل VPC، وهي لا تحمل كل واحدة محللاً خاصاً بها.

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

احسب العنوان من نطاق VPC الأساسي

خذ CIDR IPv4 الأساسي لـ VPC وأضف اثنين إلى عنوان الشبكة. يعطي 10.0.0.0/16 العنوان 10.0.0.2، ويعطي 172.31.0.0/16 العنوان 172.31.0.2، ويُبقي VPC ذو نطاق ثانوي المحلل على النطاق الأساسي. الشبكة الفرعية 10.0.8.0/24 داخل ذلك VPC لا تحرّكه. اكتب العنوان بجانب معرّف VPC قبل أن تلمس نقطة النهاية، لأن الرقم خاصية للـ VPC لا للاتصال.

يجيب VPC أيضاً على العنوان المحلي للرابط 169.254.169.253. هذا العنوان يمكن الوصول إليه من داخل VPC، لكنه ليس وجهة مُوجَّهة عامة لحاسوب محمول في الطرف الآخر من نفق.

إذن هناك عنوانان صالحان للمحلل، وليس أحدهما الشبكة الفرعية زائد اثنين.

ما يفعله إعداد نقطة النهاية وما لا يفعله

تحتوي نقطة نهاية Client VPN على حقول لخادم DNS، وحيث تقدم وحدة التحكم خيار محلل VPC فإنها تملأ الفكرة نفسها. تغييرها يغيّر ما تسلّمه الخدمة للعملاء أثناء إعداد الاتصال. لكنه لا يغيّر ما يفعله عميل OpenVPN غير المُدار بهذه القيمة، لأن العميل عليه تطبيقها على نظام التشغيل. من هذه الفجوة يأتي «يعمل على Mac ولا يعمل على جهاز Linux».

على Linux، تكامل المحلل مملوك لمدير الاتصال لا للمستخدم. تحرير /etc/resolv.conf يدوياً يثبت أن العنوان يعمل لجلسة واحدة ثم يختفي عند إعادة الاتصال، ولهذا تعود حالات كثيرة أُصلحت في الصباح التالي.

افحص المحلل النشط على العميل بعد الاتصال، لا صفحة إعداد نقطة النهاية.

قد يُبطل التوجيه المنقسم محللاً صحيحاً

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

تنتج النطاقات المحلية المتداخلة النتيجة نفسها بطريقة أسوأ: يُجاب الاستعلام، لكن من الخادم الخطأ.

لا تفتح مجموعات الأمان لعنوان Amazon DNS

الغريزة عند انتهاء مهلة عمليات البحث هي إضافة قاعدة تسمح بـ UDP 53 إلى عنوان المحلل. توثّق AWS أن مجموعات الأمان وقوائم ACL للشبكة لا تصفي حركة Amazon DNS كما تصفي الحركة إلى نسخة DNS مخصصة. فتح تلك القواعد لا يغيّر شيئاً لمحلل VPC ويوسّع الحدود دون سبب. المحلل الذي تديره بنفسك حالة مختلفة ويحتاج فعلاً قواعده الخاصة.

إذا ظهر الاثنان في تصميمك، فافحص أيّهما الموجّه إليه العميل فعلاً قبل تحرير أي قاعدة.

تحقق من المسار ثم قس شيئاً آخر

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

البحث الناجح لا يقول شيئاً عن سرعة النقل المستمرة، لذا أبقِ المحادثتين منفصلتين عند إعداد تقريرك.