امنح مستخدمي VPN الوصول إلى خدمة واحدة، لا إلى الشبكة الفرعية

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

اكتب المتطلب كخدمة، لا كشبكة فرعية

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

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

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

وجّه المسار بضيق، لكن نفّذ الإنفاذ في مكان آخر

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

وعلى العكس، قد يكون مسار واسع مع مرشح صارم مشروعًا، لكن فقط إذا عرف كل المعنيين أي الضابطين ينفذ الإنفاذ.

وثّق نقطة الإنفاذ صراحة، وإلا فسيحركها التغيير التالي عن غير قصد.

تحقق من المصدر الذي تراه الخدمة فعليًا

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

اختر الترجمة بوعي: فهي تبسط التوجيه وتدمر هوية المصدر، وهذا يهم التدقيق وقواعد كل مستخدم.

اكتب أي الاثنين اخترت، بجانب القاعدة التي تعتمد عليه.

تخويل التطبيق ليس اختياريًا

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

هنا يثمر التصميم الضيق مرتين، لأن عددًا أقل من المضيفين القابلين للوصول يعني أماكن أقل يمكن استغلال خطأ على مستوى التطبيق فيها.

أبقِ قاعدة الشبكة ودور التطبيق في نظامين منفصلين، واسحبهما بشكل منفصل.

أثبت المسار المسموح والمسار المرفوض معًا

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

لا تعطّل مرشحات التمرير لتمرير اختبار القبول، لأن ذلك يغيّر الشيء الذي يجري اختباره.

عندما لا يعود المستخدم يحتاج الخدمة، اسحب الهوية البعيدة ودور التطبيق في نظاميهما المعنيين، وسجّل كليهما. دليل strongSwan لإعادة التوجيه يغطي جانب البوابة من المسار.