إخراج منفذ واحد من نفق VPN يتطلب توجيهًا قائمًا على السياسة

الطلب دائمًا صيغة من الجملة نفسها: أبقِ الـVPN للتصفح، لكن دع SSH أو مهمة نسخ احتياطي تستخدم الاتصال العادي. النصيحة المنتشرة لذلك، وهي تمرير المنفذ بقواعد iptables NAT، لا تفعل ذلك. قاعدة NAT تعيد كتابة العناوين والمنافذ داخل التدفق؛ وهي لا تختار أبدًا الواجهة التي تغادر منها الحزمة. ذلك القرار ينتمي إلى البحث في جدول التوجيه، والبحث في جدول التوجيه يحتاج مساعدة ليرى منفذًا.

لماذا لا يستطيع المسار العادي مطابقة منفذ

يختار Linux المسار بالبحث عن عنوان الوجهة في جدول، بعد تصفية الجداول المرشحة عبر قواعد السياسة. تستطيع تلك القواعد مطابقة علامة جدار الحماية أو عنوان مصدر أو واجهة قادمة أو UID. ومدخل جدول التوجيه نفسه لا يحتوي حقل منفذ، لأن المسار يُختار قبل أن تصبح ترويسة النقل ذات أثر.

توسّع iproute2 والنوى الحديثة محدد القاعدة: ipproto، sport وdport مقبولة، لذا ip rule add ipproto tcp dport 22 table 100 يعبّر عن النية في سطر واحد. نفّذ ip rule add help على المضيف الفعلي لترى ما إذا كانت نسختك تُدرج dport. فإن أدرجته فأنت منتهٍ بأمر واحد؛ وإن لم تُدرجه فمسار العلامة أدناه هو المكافئ.

في الحالتين القاعدة مجرد مؤشر. الجدول 100 ما زال يحتاج مسارًا، وهذا هو الجزء الذي ينساه الناس.

ثلاث قطع، أو واحدة

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

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

القطع الثلاث بالترتيب

أولًا، علّم التدفقات التي تريد تحويلها، في سلسلة تعمل مبكرًا بما يكفي لتوجد العلامة قبل قرار المسار:

nft add table inet vpnexempt
nft 'add chain inet vpnexempt out { type route hook output priority mangle; }'
nft add rule inet vpnexempt out tcp dport 22 meta mark set 0x1

ثانيًا، أرسل الحزم المعلّمة إلى جدول منفصل:

ip rule add fwmark 0x1/0x1 table 100

ثالثًا، أعطِ ذلك الجدول مسارًا افتراضيًا عبر الرابط الفيزيائي. العناوين توضيحية؛ استبدلها بعناوينك:

ip route add default via 192.168.1.1 dev wlan0 table 100

تخطَّ الخطوة الثالثة فلن يجد الحزمة المعلّمة مسارًا في الجدول 100، فتفشل. تبدو الأعراض كأن القاعدة كسرت الشبكة، بينما هي في الحقيقة أزالت المسار الوحيد المتبقي للحزمة.

ما يبقيه عاملاً بعد الحزمة الأولى

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

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

لا تعلّم نقل النفق نفسه. فنفق WireGuard أو OpenVPN عبر UDP ليس TCP 22، لذا الوصفة أعلاه آمنة، لكن استثناءً مكتوبًا على أنه كل شيء إلا وجهة النفق قد يلتقط الحزم المشفّرة ويكسر النفق بطريقة تُقرأ كحلقة توجيه.

افحصه بدلًا من افتراضه

اسأل النواة أي طريق ستسلك، من أجل الوجهة والمنفذ، ثم نفّذ النقل الفعلي:

ip route get 203.0.113.10
ip rule show
nft list ruleset

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

متى تكون هذه الأداة خاطئة

الاستثناءات القائمة على المنافذ هشة بطبيعتها. فالخدمات تنقل منافذها، وHTTP/3 يصل عبر UDP 443، وتطبيق واحد قد يفتح عدة تدفقات من أنواع مختلفة. وإذا كان الشرط الحقيقي أن يستخدم هذا البرنامج الرابط العادي، فطبقة التوجيه مكان خاطئ؛ ومساحة أسماء الشبكة أو وكيل لكل تطبيق أنسب.

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

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