تطبيق مرتبط بعنوان VPN لا يزال يستخدم المسار الخاطئ

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

بقية هذا الدليل هي ترتيب الفحص الذي أستخدمه، مع الأمر الذي ينتج كل ملاحظة.

ما يقرره الربط فعليًا

يربط bind عنوانًا محليًا بالمقبس. ثم يجري النواة نفس بحث المسار الذي كان سيجريه لولا ذلك، إلا إذا غيّرت قاعدة سياسة الجدول الذي يقرأه ذلك البحث.

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

توثّق مرجع مقابس IP في Linux دلالات bind. أما نصف التوجيه فيسكن في ip-rule وip-route، وهما دليلان منفصلان لسبب.

تأكد من أن العنوان ينتمي إلى هذه المساحة الاسمية

العنوان الذي يمكنك الربط به يجب أن يوجد على واجهة داخل مساحة أسماء الشبكة التي يعمل فيها التطبيق. عنوان النظير أو عنوان البوابة أو عنوان موجود فقط في مساحة أسماء أخرى لا يمكن الربط به، ويفشل الاستدعاء بـ EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

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

اقرأ البحث الخاص بذلك المصدر والوجهة

أمر واحد يجيب عن السؤال الذي لم يجبه bind:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

ثم يخبرك ip rule show هل كانت أي قاعدة ستختار جدولًا آخر. الأولويات مهمة هنا، لأن أول قاعدة مطابقة تفوز، وقاعدة شاملة أعلى قاعدتك تجعل قاعدتك غير مرئية.

ثبّت قاعدة سياسة فقط إذا كان ذلك هو التصميم

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

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

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

تراجع باستخدام ip rule del وip route flush table 100. أي شيء يُضاف بهذه الطريقة يختفي عند إعادة التشغيل ما لم يكتبه مدير، وهذا خاصية أمان وسبب لعدم الاحتفاظ بالنسخة الوحيدة في سجل الصدفة.

تحقق بثلاث ملاحظات

سجّل المصدر الذي طلبه التطبيق، والمسار الذي اختاره البحث، والمصدر الذي رآه الخادم فعليًا.

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

إذا كان التطبيق يقدم خيار الربط بجهاز أو وضع توجيه لكل تطبيق، فتعامل معه كآلية مختلفة بقيود مختلفة. الإعدادات المتشابهة في المظهر لا تنتهي كلها إلى قرار النواة نفسه.