عنوان IP واحد للخدمة على كل عقدة OpenVPN: ما لا يفعله

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

لماذا يعمل العنوان نفسه على كل عقدة

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

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

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

أسنده إلى الواجهة المحلية، لا إلى النفق

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

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

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

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

ادفع مسارًا واحدًا واقصد وجهة واحدة

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

تحقق مما ثبته العميل قبل أن تلوم الخدمة.

ip route get 10.250.0.1

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

ما لا يستطيعه العنوان المشترك

إنه لا يوفر تجاوز الفشل. إذا مات العقدة المختارة، مات العنوان معها، وعلي العميل أن يتصل من مكان آخر.

إنه لا ينقل جلسة TCP حية، لأن الاتصال الجديد ينتهي على مضيف مختلف بلا أي معرفة بالقديم.

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

احتفظ بهوية الخدمة مع الاسم

اكتب ما يعنيه العنوان: أنه يصل إلى الخدمة على العقدة التي يتصل بها العميل الآن. تلك الجملة الواحدة تمنع معظم سوء الفهم الذي يجذبه هذا النمط.

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

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

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

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