عميل VPN يحذف المسار الذي أضفته؟ استخدم جدول سياسات

يختفي /24 واحد مخصص لطابعة مخبرية بين استدعاءين لـ ip route show، ولا يقول سجل العميل سوى إن الشبكة تغيّرت. لم يكن هناك خطأ في الأمر أو البادئة أو صلاحياتك. عميل المؤسسة الذي يملك نموذج التوجيه الخاص بالمضيف يعيد فرض ذلك النموذج كلما عدّله شخص آخر، لذلك يُحذف الإدخال الذي أضفته باعتباره دخيلًا. محاربته في الجدول نفسه موقف خاسر. الحل هو التوقف تمامًا عن التنافس على ذلك الجدول ووضع الاستثناء في مكان لا ينظر إليه المراقب أبدًا.

المراقب يفسر المسار المفقود

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

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

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

الجدول الثاني غير مرئي للمراقب

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

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

ابنِ الاستثناء ثم اجعله يفوز

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

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

يحل ip route get المسار الذي ستستخدمه النواة، بما في ذلك الجهاز وعنوان المصدر. لا يطبع معرّف الجدول، لذا اقرنه بـ ip rule show عندما تحتاج إلى تأكيد الجدول الذي فاز. معًا يجيبان عن السؤال الوحيد المهم: هل تغادر حركة المرور إلى ذلك العنوان حيث كنت تنوي؟

أشكال أخرى للفكرة نفسها

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

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

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

اعتبر القاعدة قابلة للاستبدال

تعيش القواعد ومسارات الجداول في الذاكرة. بعد إعادة الاتصال يمكن تغيير اسم جهاز النفق، ويمكن أن ينتقل العنوان المخصص، وتتوقف قاعدة تحمل القيمة القديمة عن المطابقة بصمت. أعد تطبيق التغيير كله من سكربت واحد يملكه، ثم أعد فحص ip rule show واسم الجهاز الحالي و ip route get جديدًا مقابل وجهة حقيقية قبل الوثوق بالاستثناء.

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

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