عند إعداد شبكة افتراضية خاصة لتوجيه كامل حركة البيانات الصادرة من الجهاز (0.0.0.0/0 و ::/0)، يجب أن تعبر جميع الحزم عبر النفق المشفر. يفرض هذا التصميم معضلة بنيوية تُعرف باسم التوجيه التكراري (routing recursion). البيانات المشفرة الصادرة من تطبيق العميل تحتاج بدورها إلى الإرسال عبر الشبكة المادية باستخدام مقبس UDP خارجي. وإذا قام نظام التشغيل بتوجيه كافة حزم بروتوكول الإنترنت نحو واجهة النفق الافتراضية، فإن حزمة UDP الخارجية ستعود أدراجها إلى مشغل النفق نفسه، مما يتسبب في حلقة تغليف لا نهائية.

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

يتعامل بروتوكول WireGuard في نظام لينكس مع مشكلة الحلقات التكرارية من خلال دمج علامات الجدار الناري (fwmark)، وخيار المقبس البرمجي SO_MARK، وقاعدة بيانات سياسات التوجيه (RPDB).

معضلة التوجيه التكراري في أنفاق الشبكات

لفهم أهمية التوجيه القائم على السياسات، نتتبع مسار حزمة بيانات على جهاز لينكس يشغل واجهة WireGuard تسمى wg0.

عندما يرسل تطبيق حزمة بيانات TCP نحو خادم ويب خارجي بالرقم 203.0.113.50، تختار نواة النظام مسار الخروج. فإذا اعتمد المسؤول أمراً تقليدياً مثل ip route add default dev wg0، ستعتبر النواة واجهة wg0 هي الوجهة التالية. يستقبل مشغل WireGuard الحزمة، ويفحص جدول التوجيه المشفر (Cryptokey Routing)، ويشفر المحتوى بخوارزمية ChaCha20-Poly1305، ثم يغلفه داخل حزمة UDP موجهة إلى الخادم عند 198.51.100.10:51820.

حزمة التطبيق (الوجهة: 203.0.113.50)
        │
        ▼
   جدول النواة: default dev wg0
        │
        ▼
مشغل WireGuard (wg0): التغليف في UDP خارجي (الوجهة: 198.51.100.10:51820)
        │
        ▼
   جدول النواة: تطابق مجدداً مع default dev wg0! ──> حلقة تكرار توجيه

في اللحظة التي يسلم فيها مقبس WireGuard هذه الحزمة الجديدة إلى حزمة بروتوكولات الشبكة، تستشير النواة قاعدة بيانات إعادة التوجيه (FIB) مرة ثانية. ولأن المسار الافتراضي لا يزال يشير إلى wg0، فإن حزمة UDP الخارجية تعود لتدخل wg0 من جديد. تحاول الواجهة إعادة تشفير الحزمة المشفرة بالفعل، فتمتلئ سعة ذاكرة المقبس، وتتجاوز الحزمة الحد الأقصى للنقل (MTU)، وتُسقط النواة الحزم، مما يوقف الاتصال في الحال.

قاعدة بيانات سياسات التوجيه RPDB وهندسة الجدول المزدوج

يدير نظام لينكس المسارات المعقدة والمتعددة عبر قاعدة بيانات سياسات التوجيه (RPDB)، والتي يتم التحكم بها عبر أداة ip rule. بدلاً من الاقتصار على جدول توجيه ثابت واحد، تتيح RPDB توجيه الحزم إلى جداول مستقلة بناءً على عنوان المصدر أو نوع الخدمة أو بيانات الحزمة الوصفية.

يتضمن التكوين القياسي في لينكس ثلاثة جداول نظام:

  1. local (الجدول 255): يتعامل مع عناوين الحلقة المحلية والبث العام.
  2. main (الجدول 254): يحتوي على مسارات الشبكات المادية واشتراكات بروتوكول DHCP.
  3. default (الجدول 253): جدول احتياطي مخصص للسياسات الإضافية.

أدوات إدارة WireGuard (مثل wg-quick) لا تعدل البوابة الافتراضية في الجدول main. بل تنشئ جدول توجيه مخصص — يحمل عادة الرقم 51820 — وتضيف فيه المسار الافتراضي نحو الواجهة wg0:

# إضافة مسار افتراضي داخل جدول التوجيه المخصص
ip route add default dev wg0 table 51820
ip -6 route add default dev wg0 table 51820

من خلال فصل مسار النفق عن البوابة المادية في الجدول main، يحتفظ نظام التشغيل بمسارين متوازيين. ويكمن التحدي الفني في توجيه حركة بيانات التطبيقات إلى الجدول 51820 مع السماح لمقبس نقل WireGuard بالوصول إلى الجدول main (254).

تمييز المقابس عبر SO_MARK وتطبيق علامة fwmark

حلقة الوصل التي تمكن مقبس النفق من الوصول إلى واجهة الشبكة المادية هي علامة الجدار الناري (fwmark). تحتوي بنية ذاكرة التخزين المؤقت للحزم في نواة لينكس (struct sk_buff) على حقل رقمي 32 بت يُدعى skb->mark. تبقى هذه العلامة داخل ذاكرة النواة فقط، ولا تنتقل عبر الأسلاك المادية ولا تعدل ترويسات حزم بروتوكول الإنترنت.

عندما ينشئ مشغل WireGuard مقبس النقل الخارجي عبر UDP، يُفعل خيار SO_MARK عبر واجهة برمجة المقابس القياسية:

int fwmark = 51820;
setsockopt(sock_fd, SOL_SOCKET, SO_MARK, &fwmark, sizeof(fwmark));

تحمل كل حزمة صادرة من هذا المقبس العلامة الرقمية 51820. وللتحكم في حركة المرور، يتم إعداد قواعد سياسات متطابقة في RPDB:

# قواعد السياسات لفرز الحزم الموسومة وغير الموسومة
ip rule add not fwmark 51820 table 51820
ip rule add table main suppress_prefixlength 0

تجري عملية تقييم الحزم بدقة ووضوح:

  1. حركة بيانات التطبيقات: يرسل المتصفح حزمة نحو 203.0.113.50. مقبس المتصفح لا يحمل أي علامة، وبالتالي فإن قيمة skb->mark تساوي 0. تفحص النواة القاعدة not fwmark 51820. وبما أن 0 != 51820، فإن الشرط يتحقق. تُوجه الحزمة نحو الجدول 51820 وتدخل واجهة wg0.
  2. حركة بيانات نقل WireGuard: يقوم مشغل WireGuard بتشفير البيانات وإرسال حزمة UDP الخارجية من المقبس الموسوم (skb->mark = 51820). تفحص النواة القاعدة not fwmark 51820. وبما أن الحزمة تحمل العلامة 51820، فإن الشرط المنفي يسقط. تتجاهل النواة الجدول 51820 وتنتقل إلى الأولوية التالية في RPDB وهي الجدول main (254). في هذا الجدول، تتولى البوابة المادية عبر eth0 أو wlan0 إرسال الحزمة مباشرة إلى الموجه المحلي.

تضمن هذه الآلية المزدوجة خروج الحزم المشفرة إلى الوسط المادي دون أن ترتد ثانية إلى واجهة wg0.

تصفية المسار العكسي وفخ rp_filter

على الرغم من تنظيم حركة البيانات الصادرة، يمكن أن يفشل النفق إذا قامت آليات الأمان الواردة برفض حزم الاستجابة المشروعة. العقبة الأساسية هنا هي تصفية المسار العكسي (Reverse Path Filtering - RPF)، المحددة في معيار RFC 3704 وتدار عبر المتغير rp_filter.

تحمي آلية RPF النظام من هجمات انتحال العناوين. عند وصول حزمة إلى واجهة معينة، تتحقق النواة مما إذا كانت ستستخدم نفس تلك الواجهة لإرسال رد إلى عنوان المصدر.

يدعم نظام لينكس ثلاثة أوضاع لآلية RPF:

  • 0 (معطل): لا يتم التحقق من عنوان المصدر.
  • 1 (الوضع الصارم): يجب أن تصل الحزمة الواردة من نفس الواجهة التي يختارها جدول التوجيه للمسار العكسي.
  • 2 (الوضع المرن): يكفي أن يكون لعنوان المصدر مسار صالح في أي جدول توجيه دون اشتراط تطابق الواجهة.

في الوضع الصارم (rp_filter = 1)، يؤدي اختلاف مسارات الذهاب والإياب إلى إسقاط الحزم. عندما تصل حزمة الاستجابة من الإنترنت عبر الواجهة المادية eth0، تجري النواة فحصاً للمسار العكسي. ولأن هذا الاستعلام لا يحمل علامة fwmark، فإن RPDB تحيله إلى الجدول 51820، الذي يعتبر جميع العناوين الخارجية تابعة لـ wg0. هذا التناقض يدفع النواة إلى اعتبار الحزمة منتحلة وإسقاطها فوراً.

لتفادي هذا الإسقاط، تقوم تهيئة WireGuard بتفعيل الوضع المرن على الواجهات المعنية:

sysctl -w net.ipv4.conf.all.rp_filter=2
sysctl -w net.ipv4.conf.eth0.rp_filter=2
sysctl -w net.ipv4.conf.wg0.rp_filter=2

كذلك، تضمن تعليمات suppress_prefixlength 0 الملحقة بالقواعد بقاء الأولوية لشبكات الاتصال المحلية في الجدول الرئيسي وعدم حجبها بمسار النفق العام.

بيئات الأجهزة المحمولة مقارنة بالحواسيب: Android VpnService ومساحات أسماء الشبكة

يتطلب استخدام SO_MARK امتلاك صلاحيات المسؤول CAP_NET_ADMIN. في حواسيب لينكس وخوادم التوجيه، يملك المستخدم كامل الصلاحيات لتطبيق العلامات وإدارة قواعد RPDB. ولكن في أنظمة الأجهزة المحمولة، تمنع البيئات المعزولة التطبيقات من تعديل جداول توجيه النواة.

في نظام أندرويد، لا تستطيع تطبيقات WireGuard استدعاء setsockopt(SO_MARK). ولمعالجة ذلك، يوفر النظام بنية android.net.VpnService. عندما ينشئ التطبيق مقبس UDP الناقل، يسلم واصف الملف للنظام عبر الدالة VpnService.protect(int socketFd). تتولى خدمة الشبكات في أندرويد ربط هذا المقبس مباشرة بالشبكة المادية، مستثنية إياه تماماً من المرور عبر واجهة النفق الافتراضية.

حواسيب لينكس:       مقبس -> SO_MARK (51820) -> قاعدة RPDB (not fwmark) -> الجدول main
هواتف أندرويد:       مقبس -> VpnService.protect() -> ربط مباشر بالشبكة المادية
مساحات أسماء الشبكة: الواجهة eth0 في netns0 <-> الواجهة wg0 في init_net (عزل تام)

وفي الخوادم المتقدمة، تتيح مساحات أسماء الشبكة (ip netns) حلاً هيكلياً لمنع الحلقات. فنقل الواجهة المادية eth0 إلى مساحة أسماء مستقلة مع إبقاء wg0 في المساحة الرئيسية يمنع حدوث أي تكرار مسارات بصورة فيزيائية دون الحاجة إلى وضع علامات على الحزم.

بنية سياسات RiceGuard وحماية استعلامات DNS من التسريب

في التطبيقات الفعلية، تواجه الشبكات تحديات تبديل الاتصال بين شبكات الواي فاي العامة، وتجديد إعدادات DHCP، وتواجد خدمات التحليل المحلية مثل systemd-resolved النشطة على 127.0.0.53.

تدمج تقنية RiceGuard محرك توجيه متطور لحماية البيانات:

  1. سلاسل قواعد RPDB متعددة الأولويات: فرز حزم الاتصال المحلي وعناوين الشبكة الداخلية قبل توجيه البيانات نحو النفق المشفر.
  2. حماية الجدار الناري التلقائية: مزامنة قواعد التوجيه مع جداول nftables لمنع خروج أي حزم غير موسومة عبر الواجهة المادية عند تقلب الاتصال.
  3. عزل استعلامات أسماء النطاقات: توجيه كافة استفسارات DNS المحلية عبر النفق المحمي لمنع كشف العناوين الرقمية عبر القنوات المادية.

يوفر التنسيق المحكم بين علامات الحزم وقواعد التوجيه المتعددة اتصالات مشفرة قوية وفعالة وخالية من حلقات التوجيه المفرغة.

تحميل VPNRice