عملاء OpenVPN المُجسَّرون بلا إنترنت؟ تحقق من قاعدة NAT

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

العداد هو الدليل، لا السطر في الجدول

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

iptables -t nat -L POSTROUTING -v -n

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

اعرف الاسم الذي تسجّله النواة فعليًا

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

ip -brief link

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

أعد كتابة القاعدة مقابل جهاز النفق

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

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

قراءة سلسلة forward مع العدادات تستغرق أمرًا واحدًا وتستبعد نصف الاحتمالات المتبقية قبل أن تلمس قاعدة أخرى.

لماذا لا تطابق البطاقة الفيزيائية أبدًا

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

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

أثبته من الطرف إلى الطرف ثم اجعله دائمًا

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

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

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