هل تختفي ردود Linux VPN؟ تحقّق من rp_filter والمسار

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

ما الذي يقرّره التحقق من المصدر

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

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

اقرأ الوضع الفعّال، لا حقلًا واحدًا

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

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

اعثر على التعارض قبل تغيير الفحص

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

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

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

تعديل انتقائي يمكنك الدفاع عنه

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

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

أبقِ IPv4 وIPv6 منفصلين

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

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