تطبيق واحد عبر WireGuard: الربط ليس توجيهًا

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

تتكون الآلية من نصفين: جدول توجيه لا ينبغي أن تستخدمه إلا حركة النفق، وقاعدة ترسل المصدر المطابق إليه.

الربط يحدد عنوان المصدر ولا شيء أكثر

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

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

امنح النفق جدوله الخاص

يثبّت wg-quick المسارات أينما يخبره الملف التعريفي. إضافة Table = 40 تحت [Interface] تنقلها إلى الجدول 40 بدلًا من الجدول الرئيسي. أعد رفع الواجهة وتأكد من وصولها: ينبغي أن يعرض ip -4 route ls table 40 مسارات النفق، ويُظهر ip -4 route get 10.66.127.142 كيف يحل النواة أحدها حاليًا. وبوجود المسارات في جدولها الخاص، يستمر الجدول الرئيسي في العمل لكل شيء آخر.

افعل الشيء نفسه مع IPv6 بدلًا من مطابقة بادئة عريضة. ip -6 rule add from fd00::2/128 lookup 40 يثبّت عنوانًا واحدًا؛ fc00::/8 قد يتعارض مع واجهات أخرى على المضيف وينتج قاعدة تطابق أكثر مما هو مقصود.

أضف قاعدة المصدر وراقب العدادات

ثم صل النصفين: ip -4 rule add from 10.66.127.142/32 lookup 40، مع إلحاق العنوان نفسه بواجهة WireGuard. ضع القاعدتين في PostUp حتى يعيد الاتصال استعادتهما. تحقق بطلب حقيقي لا بإعداد: ينبغي أن يذكر ip route get 1.1.1.1 from 10.66.127.142 جهاز النفق، وينبغي أن يبلّغ curl --interface wg0 ifconfig.me عن عنوان النفق بدلًا من عنوان المنزل.

وحين يفشل الأمر رغم ذلك، اقرأ ip -s rule. القاعدة التي توجد لكنها لم تطابق قط تعرض عدادات صفرية، وهذا يميّز القاعدة الخاطئة من غياب القاعدة أصلًا. هذا الأمر الواحد يوفر الكثير من التخمين حول ما إذا كان التطبيق قد تجاهل إعداد واجهته.

الحالة المعاكسة: أبقِ SSH خارج النفق

المشكلة المعاكسة شائعة بالقدر نفسه: wg-quick يملك المسار الافتراضي و جلسة SSH إلى الخادم تموت في منتصف الجلسة. قواعده تقع عند رقم أولوية منخفض، لذا يجب تقييم الاستثناء قبلها. ip rule add dport 22 ipproto tcp table main priority 123 يفعل ذلك على iproute2 حديث؛ وحيث لا يتوفر المحدِّد، علّم التدفق في nftables وطابق العلامة بدلًا من ذلك.

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

سجّل رقم الجدول وقاعدة المصدر والاستثناء في الملف التعريفي نفسه. الثلاثة تنتمي إلى تصميم واحد وستُحرَّر معًا.