اجعل تمرير IPv4 ثابتًا عبر إعادة تشغيل بوابة VPN

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

الوصول إلى البوابة ليس هو التمرير نفسه

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

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

اقرأ القيمة حيث توجد الحزم فعليًا

على بوابة تمرّر في نطاق أسماء المضيف، يجيب أمر واحد عن السؤال: sysctl net.ipv4.ip_forward. عندما يقيم مسار الدخول والمسار التالي في نطاق أسماء مسمّى، اسأل ذلك النطاق بدلًا من ذلك: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. قيمة المضيف ليست بديلًا عن قيمة نطاق الأسماء، ووجود واحد على المضيف ليس دليلًا على أي شيء.

ليست كل سياقات التمرير تملك تسمية يمكنك تمريرها إلى ip netns. تنشئ بيئات تشغيل الحاويات والخدمات نطاقات أسماء لا تُسجَّل أبدًا تحت اسم ودّي، وتلك تستخدم لها أدوات فحص بيئة التشغيل. استبدل الاسم الحقيقي بـ vpn-gw، أو آلية بيئة التشغيل التي تصل إلى السياق نفسه، وتوقف عن التخمين على مستوى المضيف.

امنح الإعداد مالكًا واحدًا

على بوابة مضيف systemd تقليدية، الشكل الدائم هو ملف drop-in باسم يختاره المسؤول مثل /etc/sysctl.d/60-vpn-forwarding.conf يحتوي على net.ipv4.ip_forward = 1. اكتب الملف، ثم حمّل ذلك الملف تحديدًا حتى تتغير الحالة الحية أيضًا: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf، يتبعه قراءة عكسية. اسم الملف مثال وليس مسار VPN محجوزًا، والرقم في البداية مهم لأن الملفات الأبجديّة لاحقًا تفوز.

الأسبقية هي حيث تنكسر الديمومة بهدوء. افحص محمّل التوزيعة بالإضافة إلى ملف drop-in الخاص بك، لأن procps sysctl --system يقرأ أيضًا /etc/sysctl.conf في النهاية، بينما ترتيب sysctl.d في systemd تسلسل مختلف تمامًا. يمكن لإسناد لاحق أن يعيد المفتاح نفسه، تاركًا ملفك صحيحًا والقيمة الفعلية خاطئة. لا تستبدل ملف مسؤول موجود لكسب تلك المعركة؛ اعثر على المالك وغيّره هناك.

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

اعرف تكلفة المفتاح قبل قلبه

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

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

أثبت الديمومة، ثم اختبر بقية المسار

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

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

احتفظ بمسار drop-in ومالك نطاق الأسماء وأمر القراءة العكسية معًا في دليل التشغيل. من يتولى هذا بعد ذلك يجب أن يكون قادرًا على قراءة القيمة، ورؤية من يملكها، وتحديد خلال دقيقة هل المشكلة في الديمومة أم في بقية المسار.