مركزة وصول الشركاء عبر VPN دون دمج الشركاء

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

ابدأ من العقد الذي وقّعه كل شريك بالفعل

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

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

وجّه حسب السياق، لا حسب الوجهة وحدها

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

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

حيث يكون الجواب نعم، يصبح سياق التوجيه هو ما توثقه وتختبره، لأنه غير مرئي في traceroute.

قرّر ما يكتبه الموظف وما يسجله الشريك

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

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

ارفض العبور بين الشركاء صراحةً

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

اكتب الرفض في سجل الشريك بجوار التصاريح، حتى يبقى القصد بعد تغيّر الموظفين.

شغّله كخدمة مشتركة، لا كحاسوب محمول أكبر

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

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

احتفظ بجدول صغير للشريك والسياق والنطاقات المسموحة والمالك. سيكون أول ما يطلبه أي شخص أثناء حادث.