وجّه المنفذ 25 فقط إلى النفق، لا إلى المضيف

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

قاعدة المنفذ ليست مساراً افتراضياً

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

إعدادان في wg-quick شرطان مسبقان وليسا جزءاً من السياسة. AllowedIPs = 0.0.0.0/0 يسمح للنظير بحمل وجهات IPv4 عشوائية، كما أن Table = off يمنع wg-quick من تثبيت مساره الافتراضي لتلك البادئة. لا تخلط هذه التعليمات مع مدير يطبّق سياسة توجيه خاصة به، لأن الاثنين سيختلفان حول من يملك الجدول الرئيسي.

اكتب المسار والمحدِّد والحارس

اختر رقم جدول وزوج أولويات لا يستخدمهما شيء آخر، ثم طبّق المسار والمحدِّد والحارس بهذا الترتيب. الأرقام أدناه أمثلة، وليست قيماً محجوزة:

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo يقصر القاعدة على الحركة المنشأة محلياً، بينما يحدد ipproto tcp dport 25 اتجاه الاتصال؛ ويوثّق مرجع ip-rule المحدِّدين معاً. وهما موجودان في الأنوية الحالية وإصدارات iproute2، وفي نظام أقدم تُرفض القاعدة كلياً، وهو فشل أوضح من قاعدة تُحمَّل ولا تطابق شيئاً.

قاعدة unreachable في الأولوية التالية هي الحارس. وبدونها، يسقط مسار مفقود في الجدول 51825 إلى الافتراضي العادي، ويخرج البريد عبر الرابط الفيزيائي أثناء انقطاع النفق، وهي الحالة التي بُنيت السياسة لمنعها.

على عنوان المصدر أن يتفق

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

عند البوابة، يجب أن يأذن نظير العميل بالمصدر الذي يستقبله فعلاً، وهو 10.77.0.2/32 بدلاً من بادئة وجهة عريضة. ونسخ 0.0.0.0/0 الخاصة بالعميل في كل نظير بوابة يخلط بين من يملك أي حركة. وتحتاج البوابة أيضاً إلى التمرير، وسياسة جدار ناري تسمح بالتدفق، ومسار عودة، بما في ذلك ترجمة الخروج عندما لا يستطيع المنبع توجيه عنوان نفق خاص.

افحص مسار العودة، ثم الاستمرارية

اقرأ عمليات البحث قبل أن تثق بأي شيء، لأنها تُظهر أي جدول وأي مصدر تحصل عليه كل جهة. وجهة واحدة على المنفذ 25 والوجهة نفسها على المنفذ 443 تكفيان:

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

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

حيث يُسمح بالتوجيه غير المتماثل، قد يكون النمط المرن المحدد بالواجهة عبر net.ipv4.conf.wg0.rp_filter=2 مناسباً، ويستحق التحقق أولاً من الحد الأقصى الفعلي لقيم all والواجهة. لا تعطّل التحقق عالمياً كاختصار. ثم سلّم الجدول والأولويات والحارس إلى الجهة التي تملك الإعداد، وافتح اتصالات جديدة بعد إعادة الاتصال لتأكيد أن الاختيار لا يزال قائماً. وتذكّر أن الردود من مستمع SMTP محلي تحمل منفذ المصدر 25 لا منفذ الوجهة 25، وهي مسألة سياسة منفصلة.