من يملك العنوان والمسار وDNS وجدار الحماية على VPN يعمل بـ Linux؟

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

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

الجهاز وعناوينه

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

سجّل من يزيل الجهاز عند انتهاء الجلسة. الجهاز الذي يعيش أطول من جلسته هو المصدر الأكثر شيوعًا للعناوين القديمة وللارتباك الذي يتبعها.

المسارات وقواعد السياسة

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

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

DNS دائمًا مالك منفصل

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

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

حالة جدار الحماية ومن يعيدها

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

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

دورة الحياة: الإقلاع، إعادة الاتصال، التفكيك

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

للمراقبة، يُظهر ip monitor link address route تغييرات النواة أثناء حدوثها، لكنه يبلّغ عن أحداث لا عن نية: المسار المحذوف لا يقول شيئًا عن العملية التي حذفته. اقرنه بخريطة الملكية، وسيتحول إيقاف مربك إلى قائمة قصيرة من المرشحين.

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