سكربت الإيقاف أم قاعدة الجدار الناري: أيهما يوقف التسريب؟
إسقاط الواجهات عند قطع الاتصال أسلوب فظ وغالبًا يعمل دون صلاحيات. قارنه بقاعدة جدار ناري تصمد بعد الانقطاع وتسد الفجوة.
تصميمان يعدان بالشيء نفسه: عندما يسقط النفق، لا يخرج شيء إلى الشبكة مكشوفًا. أحدهما يشغّل سكربتًا عند الإيقاف ويقطع الواجهات. والآخر يترك قاعدة جدار ناري سارية ولا يطلب من عميل VPN شيئًا. وهما يختلفان في من يملك صلاحية التصرف، وفي ما يجري أثناء الفجوة، وفي كيفية عودة الجهاز إلى الشبكة بعد ذلك. ومقارنتهما على هذه النقاط الثلاث أنفع من الجدال حول أيهما أكثر صرامة.
المهمة نفسها عبر آليتين
يستطيع العميل تشغيل خطافات عند صعود النفق وعند إسقاطه، بشرط أن يسمح الملف الشخصي بتنفيذ السكربتات. ويعمل ذلك الخطاف داخل دورة حياة العميل، في لحظة إغلاق الاتصال. أما قاعدة الجدار الناري فيملكها النظام ولا يهمه إن كان العميل يعمل أو انهار أو قُتل.
| Property | Teardown script | Firewall unit |
|---|---|---|
| Runs when the client is killed | No | Yes |
| Needs privilege at teardown time | Usually yes | Configured once, at boot |
| Acts on the whole machine | Often, including recovery paths | Only on the flows it matches |
هذا الجدول هو الحجة كلها. سكربت لا يعمل إلا عند إغلاق سليم يغطي الحالة التي كنت أقل قلقًا منها؛ والحالة المهمة هي الانهيار أو اختفاء الشبكة، وكلتاهما لا تنتج إيقافًا نظيفًا.
ما يستطيعه خطاف الإيقاف وما لا يستطيعه
النمط الموثق يمر على واجهات الشبكة ويخفض كل شيء عدا loopback. وبخفض الجهاز الفيزيائي لا يستطيع شيء الهروب خارج النفق، وهذا هو المقصود بالضبط.
#!/bin/sh
for dev in /sys/class/net/*; do
name=$(basename "$dev")
[ "$name" = lo ] || ip link set dev "$name" down
doneكما يخفض الشبكة المحلية، وأي خدمة يستضيفها الجهاز، والمسار الذي كنت ستستخدمه لإصلاح المشكلة. وعلى الحاسوب المحمول يحتاج الجهاز اللاسلكي أحيانًا إلى تبديل يدوي بعد ذلك، فيتحول انقطاع قصير إلى جلسة إصلاح. والأسوأ أن الخطاف قد لا يُسمح له بفعل أي من ذلك: فعندما يتخلى العميل عن صلاحياته، يعمل سكربت الإيقاف بحساب غير مميز، ويفشل كل تغيير في الواجهة بخطأ صلاحيات يُكتب في اللحظة التي لا يقرأ فيها أحد السجل.
تحقق من طريقة بدء العميل قبل الثقة بالخطاف. سكربت يعمل عند تشغيله يدويًا بصلاحيات الجذر لا يثبت شيئًا عن الخدمة التي تبدأ عند الإقلاع.
ما تفعله قاعدة الجدار الناري على نحو مختلف
القاعدة التي تسمح فقط بحركة النفق تبقى عاملة عندما تختفي عملية العميل، لأن النواة لا تعتمد على تلك العملية. والقاعدة أضيق أيضًا: فهي تحجب بالضبط التدفقات التي تطابقها وتترك loopback والشبكة الفرعية المحلية ومسار الاستعادة وحدها، ولهذا لا تترك الجهاز معزولًا.
المقابل هو أن القاعدة يجب أن يكتبها ويحتفظ بها من يملك جدار ناري المضيف، وأن تسمي جهاز النفق الذي ينشئه العميل فعليًا. وهذا يعني أن القاعدة والملف الشخصي يجب صيانتهما معًا؛ فواجهة أُعيدت تسميتها تترك جدارًا ناريًا يحجب كل شيء ولا يفسر شيئًا.
لا تجعل أي من الآليتين الأخرى زائدة. فقاعدة جدار ناري لا تُعاد تحميلها أبدًا بعد تعديل هي خيالية مثل سكربت لا يعمل أبدًا.
persist-tun يحدد ما إذا كانت هناك فجوة
عندما يبقى جهاز النفق بعد قطع الاتصال، تبقى أيضًا المسارات التي تشير إليه. فتُسقط الحركة حينها بدلًا من إعادة توجيهها، فلا يرتد المسار الافتراضي إلى البوابة الفيزيائية. هذا هو السلوك الذي يجعل التسريب غير مرجح حتى قبل أن تدخل أي قاعدة جدار ناري في الأمر.
بدون ذلك الإعداد يُزال الجهاز وتُزال المسارات معه، ويمكن للمسار الافتراضي أن يعود إلى البوابة الفيزيائية. وهل يفعل ذلك يعتمد على المنصة والعميل، ولهذا بالضبط يجب رصد الحالة لا افتراضها. اعتبر الإعداد جزءًا من مفتاح الإيقاف، لا خيار أداء.
أبقِ مسار إعادة الاتصال حيًا ثم اختبر أربع حالات
الحجب الصارم قد يمنع العميل من إعادة الاتصال أيضًا، لأن العميل ما زال يحتاج مسارًا إلى الخادم عبر البوابة الفيزيائية بينما يُرفض كل شيء آخر. ثبّت مسار مضيف لذلك العنوان الواحد قبل صعود النفق، وحلّل الاسم أولًا، لأن DNS قد يكون محجوبًا في الوقت الذي تحتاجه فيه.
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0ثم تحقق من الحالات لا من التسمية. جرّب أربع لحظات عن قصد: بدء بارد بلا نفق، وجلسة سليمة، وانقطاع لم يطلبه أحد، والجلسة بعد تعافيها. اقرأ في كل لحظة المسار الافتراضي ونفّذ طلبًا واحدًا يظهر عنوان خروجه. تطبيق يستسلم والنفق منخفض لا يقول شيئًا عن عميل بريد أو محدّث، فكرر الفحص الأخير مع تطبيق خلفي واحد. اكتب القاعدة وأسماء الواجهات وخطوات الاستعادة، لأن مفتاح إيقاف لا يستطيع أحد التحقق منه مجرد إشاعة.