قواعد AWS Client VPN مكانها المورد، لا الشبكة الفرعية

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

وضع الشبكة الفرعية توجيه، لا تخويل

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

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

مجموعة ارتباط Client VPN هي المقبض

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

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

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

ما لا تستطيع مجموعة ارتباط واحدة تمييزه

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

التمييزات الأدق تعود إلى التطبيق. مستمع قاعدة بيانات يجب أن يبقى مغلقًا أمام معظم الموظفين يُحمى أفضل بأن لا يكون قابلًا للوصول على البادئة المسموحة إطلاقًا بدلًا من الأمل في بقاء عضوية المجموعة منظّمة.

إعادة تسمية المجموعة لا تُنشئ هوية، وتكرارها لكل فريق يضاعف فقط الارتباطات التي يجب تدقيقها.

لا تنسخ تلك القاعدة إلى كل تصميم VPN

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

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

قفزة NAT على المسار تكفي لكسر الافتراض، ويبدو العطل كقاعدة موجودة لكنها لا تطابق أبدًا.

راجع الحدود الفعلية

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

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

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