حساب VPN واحد عبر خادمين: ثلاثة دفاتر حالة

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

اعمل على الدفاتر الثلاثة أدناه بالترتيب. كل دفتر يسأل ما هو المرجع، وما هو محلي، وما يحدث عند غياب العقدة الأخرى، والإجابات لا تنبع إحداها من الأخرى.

من يحق له الاتصال: سلطة واحدة وعقد متعددة

ابدأ بدفتر القبول: أي مصدر هوية هو المرجع، وأي جهات إصدار الشهادات موثوقة، وأي الحسابات مؤهلة، وأي عامل ثانٍ ينطبق، وما يمكن لكل حساب الوصول إليه. ثم دوّن كيف تعلم كل عقدة بالتغييرات، وبأي سرعة.

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

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

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

ما تملكه العقدة: العناوين والمسارات

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

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

وجّه العملاء إلى عقدة عن قصد. فاختيار DNS وقوائم نقاط نهاية العميل وخدمة الواجهة الأمامية آليات مختلفة لها سلوك مختلف في الصحة وتجاوز الفشل. اختيار واحدة أمر مقبول؛ أما معاملة “موازنة الحمل” على أنها التصميم فيترك مسار العودة وسلوك الفشل غير معرّفين.

مثال منتج موثق يساعد هنا. توثيق النسخ المتماثل لدى Pritunl يعامل شبكة VPN ككائن لكل نسخة، ويحتاج العملاء على نسخ مختلفة إلى مسارات واتصال إضافي للوصول إلى بعضهم. هذا ترتيب خاص بمنتج، وليس وصفة لـ Community OpenVPN، لكنه يبيّن لماذا يغيّر إضافة نسخة الشبكة وليس مخزن الحسابات فقط.

ما هي الجلسة: حالة حية لا صفّاً

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

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

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

اختبار الدفاتر الثلاثة

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

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

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