AWS Client VPN مع النفق المنقسم: أي المسارات ينبغي أن تنشر

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

مفتاح النفق المنقسم ليس قائمة وجهات

تشرح AWS النفق المنقسم بأنه إضافة مسارات نقطة النهاية إلى جدول مسارات العميل عند إنشاء الاتصال. مسار الشبكة الخاصة VPC يحصر النفق في تلك الوجهة، وكل ما عداها يتبع المسار العادي للعميل. المسار الافتراضي تعليمة مختلفة بأثر مختلف، ولهذا يحذّر توثيق النفق المنقسم من نشر 0.0.0.0/0 على نقطة نهاية مهيأة لهذا الوضع: فهو يقطع الاتصال عادة بدل أن يوسّعه. جدول مسارات نقطة النهاية هو السياسة، وجدول مسارات العميل هو النتيجة التي يمكنك فحصها.

اقرأ جدول مسارات نقطة النهاية والمسارات المثبتة على العميل معًا. التسمية تصف نية، والمسارات تصف ما يحدث فعلًا.

القرار الأول: هل تبقى حركة الإنترنت العامة محلية؟

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

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

القرار الثاني: أي البادئات الخاصة، وبإذن مَن؟

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

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

عندما يجب أن تكون الوجهة قابلة للوصول بالاسم، انتبه إلى أن سؤال تحليل الأسماء هو التالي، لا سؤال المسار.

القرار الثالث: أي خادم تحليل أسماء يتبع النفق؟

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

ينبغي أن تُحل الأسماء العامة كما كانت قبل الاتصال، وهذا سبب آخر للدقة فيما تنشره.

غيّر مجموعة المسارات ثم تحقق من العالمين

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

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

اكتب قائمة المسارات في دليل التشغيل بجوار التعليل، حتى يستطيع الشخص التالي التمييز بين استثناء مقصود واستثناء منسي.