اتصالات جديدة عبر مخرج VPN جديد، وتدفقات قديمة تُترك كما هي

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

طريقتان لتبديل المخرج

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

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

الثمن هو التعقيد: جدولا توجيه، ومصنِّف يعمل عند الخطاف الصحيح، وعلامات يجب تنسيقها مع كل ما يستخدمها على الجهاز.

امنح كل مخرج جدوله الخاص

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

ip rule add fwmark 0x10/0x10 table 101
ip rule add fwmark 0x20/0x20 table 102
ip route add default via 192.0.2.1 dev wg-a table 101
ip route add default via 198.51.100.1 dev wg-b table 102

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

اختر مرة واحدة، عند أول حزمة

صنِّف بعد وجود تتبع الاتصالات وقبل بحث التوجيه المهم. بالنسبة لاتصال LAN جديد غير مصنَّف، اختر المخرج واحفظه في حالة الاتصال. في الحزم اللاحقة، استعد القيمة المحفوظة في علامة الحزمة التي تقرأها سياسة التوجيه.

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

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

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

أربع مراحل للتصريف

1. جهِّز B دون لمس A: التوجيه، والتحويل، والتفويض، وNAT، ومسار العودة. ثبِّت جدوله وسياسة اختياره عبر مالك التكوين الحالي للبوابة.

2. بدِّل المصنِّف بحيث تختار الاتصالات الجديدة غير المصنَّفة B، مع الحفاظ على الاختيارات المحفوظة. معاملة nftables الذرية تتجنب نافذة يجب فيها مسح الحالة القديمة.

3. أبقِ A يعمل حتى تنتهي تدفقاته. واجهته وجدوله ومخرجه البعيد وتعيينات NAT لا تزال جزءًا من تلك التدفقات، وتحرير قاعدة NAT لا يعيد بناء الارتباطات الموجودة بالفعل.

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

ما لا يمكن للتصريف أن يَعِد به

طلب المتصفح ليس اتصال نقل جديدًا؛ فالتجميع يواصل إرسال الطلبات عبر الاتصال القديم. وبالعكس، يمكن لتدفق UDP أن يتقادم خارج conntrack فتُصنَّف حزمة لاحقة من جديد. التصريف يتبع التدفقات المتتبَّعة، لا فكرة التطبيق عن الجلسة.

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

تحقق من الشطرين

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

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