ثلاثة أنواع من تجاوز فشل OpenVPN على pfSense، ثلاث آليات

يغطي «OpenVPN failover» على pfSense ثلاثة تصاميم غير مترابطة على الأقل، وكل واحد منها يحتاج آلية مختلفة. إبقاء نفق حيًّا عبر رابط إنترنت احتياطي، وإعادة الاتصال بخادم آخر، وتوجيه حركة LAN إلى نفق آخر قائم بالفعل ليست تنويعات لميزة واحدة. اختر العطل الذي تدافع ضده قبل أن تبني مجموعة بوابات. المجموعة التي تصلح أحدها لا تفعل شيئًا للآخرين.

سمِّ العطل قبل أن تبني مجموعة

اكتب الجملة التي تريد أن تكون صحيحة أثناء انقطاع. «النفق يعيد الاتصال عبر WAN الاحتياطي» و«الفرع يواصل الوصول إلى التطبيق عبر النفق الآخر» جملتان مختلفتان. الأولى فقط تتعلق بالنقل.

ثم اربطها بآلية. فقدان WAN المحلي مشكلة اختيار واجهة، ونقطة النهاية البعيدة الميتة مشكلة قائمة اتصالات، والمسار غير الصالح داخل نفق قائم مشكلة توجيه وسياسة.

WAN المحلي: انقل النقل

بالنسبة لعميل OpenVPN على pfSense، يختار ترتيب WAN المتعدد المدعوم مجموعة بوابات مناسبة كالواجهة التي يرتبط بها العميل. هذا ما يسمح للاتصال الخارجي بالخروج عبر الرابط الاحتياطي عندما تفشل الأساسي. وهو بذاته لا يغيّر كيفية توجيه الحركة الداخلية.

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

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

نقطة النهاية البعيدة: خادم آخر

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

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

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

مسار النفق: اختر مخرجًا آخر

عندما يكون نفقان قائمين بالفعل وتريد أن تستخدم الحركة الأصح منهما، فالآلية هي واجهة VPN مُخصصة ببوابتها الخاصة، بالإضافة إلى قاعدة سياسة صريحة ترسل الحركة الصحيحة إليها. ويمكن لمجموعة بوابات فوق تلك الواجهات المخصصة أن تعبّر عن الأولوية والمراقبة.

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

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

المراقبات وNAT وقاعدة fail-closed

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

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

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

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