AWS Client VPN متصل لكن EC2 ما زال لا يستجيب

قال حاسوبي المحمول إنه متصل. أظهر عميل AWS Client VPN حالته الخضراء، وسجّلت نقطة النهاية جلسة، ومع ذلك لم أستطع فتح منفذ MongoDB على نسخة EC2 في شبكة فرعية خاصة. لم يكن هناك عطل ظاهر: كانت الشهادة صالحة، والملف الشخصي جاء من وحدة التحكم، والنفق كان يحمل حركة البيانات. كان الخطأ خطئي، لأنني كنت أقرأ كلمة متصل بمعنى مصرح له.

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

الفحوص التالية هي الترتيب الذي أستخدمه الآن.

ما الذي تثبته الجلسة المتصلة فعليًا

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

التفويض لوجهة ما كائن منفصل على نقطة النهاية. تُطابَق كل حزمة بيانات مع قواعد التفويض، وكل قاعدة تقرن CIDR وجهة بالمجمموعة التي تُمنح لها القاعدة. عندما لا تغطي أي قاعدة الوجهة، تقبل نقطة النهاية الجلسة وتُسقط الحركة. لا توجد لافتة ولا حلقة إعادة اتصال ولا شيء في واجهة العميل يقول مرفوض.

قارن قاعدة التفويض بالمورد، لا بـ VPC

اسرد القواعد وضعها بجوار العنوان الذي تملكه النسخة فعليًا:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

يعرض الناتج CIDR وجهة ومعرّف مجموعة لكل قاعدة. يوجد فيه فشلان مخفيان. قد تُجيز القاعدة 10.0.0.0/16 بينما تقع النسخة في VPC مقترنة على 10.1.0.0/16؛ مسار الاقتران موجود، لكن أحدًا لم يكتب قاعدة تفويض للنطاق الثاني. أو قد تشير القاعدة إلى مجموعة دليل ينضم إليها المستخدم في الدليل لكن ليس في المجموعة التي تقيّمها نقطة النهاية.

اكتب أضيق قاعدة تغطي الوجهة، ولا تضف قاعدة ثانية إلا عندما يكون CIDR ثانٍ مطلوبًا فعلًا. القاعدة العريضة 0.0.0.0/0 القادمة من بداية سريعة تعمل، ولهذا تبقى حتى الإنتاج وتخفي النموذج.

جدولا مسارات يقرران ما إذا كانت الحزمة تتحرك

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

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

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

إعداد واحد في جانب العميل يكسر التوجيه دون أن يكسر النفق: ملف شخصي يحتوي على route-nopull. يطلب هذا التوجيه من عميل قائم على OpenVPN أن يتجاهل المسارات التي يدفعها الخادم، فتنهض الواجهة بعنوان نقطة النهاية وحده وتصبح الوجهة بلا مسار ببساطة. تحقق بواسطة ip route show على Linux أو netstat -rn على macOS من وجود مسار عبر واجهة tun. إن لم يوجد، أزل route-nopull من الملف المُصدَّر وأعد الاتصال كي تُطبَّق المسارات المدفوعة.

مجموعات الأمان لا ترى عنوان عميلك

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

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

اتصل أيضًا بالعنوان الخاص للنسخة. عنوان IP العام يُخرج الحزمة من VPC ويعيدها عبر مسار آخر بقواعد أخرى، لذا لا يقول أي اختبار عبر العنوان العام شيئًا عن المسار الخاص.

ترتيب عزل يتوقف عند أول فشل

اعمل عليها بالترتيب وتوقف حيث يفشل أحدها. كل خطوة تستبعد طبقة واحدة بدلًا من استبعادها كلها.

1. تأكد من الهوية التي استخدمتها الجلسة ومن المجموعة التي تقيّمها نقطة النهاية. الشهادة من مخزن ثقة ليست نفس الكيان الذي يمثله تأكيد SAML من الدليل.
2. تأكد من أن قاعدة تفويض تغطي CIDR المورد لتلك المجموعة.
3. تأكد من وجود مسار نقطة نهاية يستهدف شبكة فرعية مرتبطة، ثم تأكد من أن جدول مسارات الشبكة الفرعية يستطيع التمرير إلى ما بعدها.
4. تأكد من أن مجموعة الأمان تسمح بالمنفذ من واجهة نقطة النهاية لا من تجمّع العملاء.
5. اختبر من داخل VPC بجلسة SSM على نسخة أخرى في الشبكة الفرعية نفسها، للفصل بين مشكلة تطبيق ومشكلة في مسار العميل.

حين لا تحسم الخطوات الأمر، أستند إلى هذا الجدول:

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

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