لماذا يترك net.ipv4.conf.default.forwarding واجهة tun0 دون تغيير

أنت تضبط net.ipv4.conf.default.forwarding=1، ثم تعيد تشغيل VPN، ومع ذلك لا يزال النفق يُسقط حزماً يفترض أن البوابة توجّهها. الإعداد يبدو صحيحاً في الملف، والواجهة ما زالت تُبلّغ أن التمرير معطّل. لا شيء معطوب: لقد غيّرت القيمة التي ترثها الواجهات المستقبلية، لا القيمة التي يستخدمها النفق القائم.

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

اقرأ القيم الثلاث معاً

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

من النتائج الشائعة أن يكون ip_forward = 0، وdefault.forwarding = 1، وtun0.forwarding = 0. تختلف القيمتان الأولى والثانية حول دور المضيف، وتُظهر الثالثة ما تفعله الواجهة فعلاً. هذا المزيج متوافق مع مضيف لم يُضبط قط كموجّه، بل أُعطي قيمة قالب فقط. الأرقام الثلاثة لا تتناقض؛ إنها تجيب عن ثلاثة أسئلة مختلفة. وكتابة قيمة القالب لا تحسم دور المضيف أيضاً.

لماذا يكون المفتاح العام هو الذي يتحرك

net.ipv4.ip_forward هو التحكم العام للبوابة. تغييره يحدّث إعدادات التمرير لكل واجهة كجزء من العملية نفسها، ولهذا يمكن لكتابة واحدة أن تجعل نفَقاً قائماً يبدأ التمرير. default.forwarding يزرع فقط الواجهات التي تُهيَّأ بعده، لذا يحتفظ النفق الموجود أصلاً بالقيمة التي وُلد بها.

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

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

اجعل الإعداد دائماً في المكان الصحيح

نجاح sysctl -w لمرة واحدة يثبت أن النواة تقبل القيمة. لكنه لا يبقى بعد إعادة التشغيل، ولا يبقى بعد أن يعيد مدير الشبكة تطبيق فكرته الخاصة عن إعداد الواجهة عند إعادة الاتصال. ضع دور البوابة في ملف إعداد sysctl أو في مدير الشبكة الذي يملك المضيف، ثم أعد تشغيل الخدمة التي تطبّقه.

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

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

لا تُصلح هذا بالأداة الخاطئة

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

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

افصل حالة IPv6

كل شيء هنا IPv4. لتمرير IPv6 وإعلانات الموجّه وسلوك accept_ra ضوابطها الخاصة، ونسخ مسار ipv4 إلى إعداد ipv6 يُنتج ملفاً يبدو معقولاً ولا يفعل شيئاً مفيداً. البوابة ثنائية المكدّس تحتاج إلى ضبط المجموعتين عن قصد.

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