AWS Client VPN أم حصن (bastion) للوصول إلى VPC مقترن

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

مساران، نقطة نهاية واحدة، مالكون مختلفون

على المسار الموجّه تصل حركة العميل إلى نقطة النهاية، وتُترجم إلى عنوان واجهة شبكة Client VPN في الشبكة الفرعية للارتباط، ثم تغادر تلك الشبكة الفرعية عبر اتصال الاقتران من A إلى B. لا ينهي VPC B أي جلسة VPN؛ بل يرى حركة عادية من VPC A، ولهذا يشير مساره العكسي إلى VPC A لا إلى مجموعة عناوين العملاء.

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

أربعة مدخلات تجعل المسار الموجّه ينجح

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

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

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

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

مجموعات الأمان وآخر متر من الصلاحية

التوجيه يُدخل الحزم إلى B؛ وB ما زال يقرر. بالنسبة لاتصال اقتران نشط في المنطقة نفسها، يمكن لمجموعة أمان في B أن تشير إلى المجموعة المطبقة على ارتباط Client VPN، ما يبقي القاعدة ضيقة ويصمد أمام تغيّر العناوين. وحيث لا يكون مرجع المجموعة ممكنًا، اسمح بنطاق الشبكة الفرعية للارتباط صراحة بدلًا من التوسيع إلى 0.0.0.0/0، وهو ما يحوّل خطأ توجيه إلى مهلة غير مفسّرة.

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

متى يكون الحصن هو الجواب الصادق

أحتفظ بثلاثة محفزات لاختيار الحصن عن قصد. أن يكون VPC المقترن ملكًا لفريق لن يضيف مسار عودة لنطاقك أو لن يقبل مرجع مجموعة. أو أن يكون الوصول بحاجة إلى موافقة أو تسجيل لكل جلسة وأن يعجز التطبيق عن حمل ذلك بنفسه. أو أن تكون القفزة الأخيرة مضطرة للبقاء داخل B لأن الخدمة لا تُحلّ إلا هناك وهوية TLS الخاصة بها مثبتة على اسم داخلي.

لا شيء من ذلك يلتف على كون الاقتران غير متعدٍّ. عدم التعدي يحد من ما يمكن لموارد B فعله: لا تستطيع استخدام A كعبور إلى VPC ثالث مقترن مع A. لم يعني قط أن مستخدم VPN لا يستطيع الوصول إلى VPC مقترن مباشرة، والحصن المبني للالتفاف على هذا الفهم الخاطئ هو مضيف يُرقَّع بلا سبب.

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

Transit Gateway وارتباطات متعددة تغيّر الحساب

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

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

ترتيب التحقق الذي يجد العطل بسرعة

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

1. حلّ اسم التطبيق من العميل وتأكد أن العنوان داخل النطاق المقترن.
2. اتصل، ثم اقرأ سجل اتصالات نقطة النهاية للارتباط الذي أنهى الجلسة.
3. على شبكة الارتباط تلك، تأكد أن جدول المسارات يوجّه النطاق المقترن إلى اتصال اقتران نشط.
4. على شبكة الموارد في B، تأكد من مدخل عودة لنطاق الواجهة ومن قواعد مجموعة مطابقة.
5. اختبر عملية مسموحًا بها وموردًا يجب أن يبقى غير قابل للوصول؛ الثاني يلتقط بقايا التصحيح.
6. أعد الاتصال بعد أي تغيير في مسار split-tunnel، لأن النفق الجاري لن يلتقط مجموعة مسارات جديدة.

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

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