كيف تُقفل مسار الخروج في لينكس كي لا يتسرّب شيء عند انقطاع VPN

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

الخرج المحلي خطاف مختلف عن التمرير

الحزمة التي تغادر تطبيقاً على الصندوق تعبر خطاف الخرج؛ أما الحزمة التي يوجّهها الصندوق لمضيف آخر فتعبر خطاف التمرير. السياسة التي تذكر forward وحده تقيّد الثانية وتترك الأولى مفتوحة على مصراعيها، ولهذا تبدو كثير من أقفال الخروج صحيحة ولا تفعل شيئاً. مطابقة الواجهة تنتمي إلى القاعدة نفسها: oifname "tun0" accept يمرّر حركة سبق توجيهها عبر النفق. ويبقى التوجيه والتصفية قرارين منفصلين أيضاً، فيمكن أن يوجد مسار للوصلة بينما ترفض التصفية الحزمة. هذا الفصل هو الآلية التي تعتمد عليها.

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

اكتب قائمة الاستثناءات من نقطة النهاية إلى الخارج

ابدأ من نقطة نهاية النفق: عنوان وجهة واحد أو مجموعة صغيرة معتمدة، وبروتوكول النقل، ومنفذ الوجهة، مثل udp dport 1194 ip daddr 203.0.113.7 accept. وإذا كان العميل يحلّل اسم مضيف، فإن تبادل DNS الأولي يحتاج قاعدة خاصة به محصورة في المُحلِّل وفي المنفذ 53، لا تصريحاً شاملاً لعنوان ذلك المُحلِّل. وينبغي لكل استثناء أن يسمّي السبب الذي وُجد من أجله. والسماح لكل حركة UDP إلى منفذ VPN يغطي أكثر بكثير من الخدمة الموثّقة الواحدة التي كنت تقصدها.

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

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

مطابقة الواجهة ليست دليلاً على نفق سليم

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

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

ما يبقى بعد انهيار الخدمة

التصفية التي يثبّتها سكربت يعمل بعد صعود النفق تختفي مع النفق، في اللحظة التي كانت مطلوبة فيها بالضبط. حمّل القفل عند الإقلاع ودع الخدمة تدير استثناءاتها فقط.

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

مسار الاسترداد قبل النشر

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

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