تواجه بوابات شبكات VPN متعددة المستأجرين على المستوى المؤسسي تحدياً بنيوياً معقداً: تداخل نطاقات العناوين الخاصة. عند تجميع أنفاق مشفرة متعددة من مؤسسات أو فروع مختلفة نحو خادم لينكس مركزي موحد، يواجه مهندسو الشبكات حتماً شبكات فرعية محلية متطابقة تستند إلى معيار RFC 1918. فمن الشائع جداً أن يعتمد عميلان مستقلان نطاق الشبكة نفسه مثل 10.0.0.0/24 أو 192.168.1.0/24.

عندما تتلاقى حركة المرور القادمة من هذه الأنفاق على بوابة حماية مشتركة، تفشل آليات جدار الحماية التقليدي القائم على تتبع الحالة (stateful firewall). يقوم نظام تتبع الاتصالات في نواة لينكس (nf_conntrack) بتمييز كل جلسة بناءً على خماسية محددة (5-tuple): عنوان IP المصدر، وعنوان IP الوجهة، ومنفذ المصدر، ومنفذ الوجهة، وبروتوكول النقل. إذا أرسل الجهاز A التابع للعميل 1 (10.0.0.5:52140) والجهاز B التابع للعميل 2 (10.0.0.5:52140) حزم بيانات في الوقت نفسه نحو خادم خارجي مثل 1.1.1.1:443، ينتج Netfilter مفتاح تجزئة متطابقاً تماماً. وفي غياب العزل المحكم، ينسب النظام حزم العميل 2 إلى جلسة العميل 1 النشطة، مما يؤدي إلى اختلال تسلسل حزم TCP وإغلاق الاتصال فجأة وحدوث تسريب للبيانات بين العملاء.

تقدم مناطق تتبع الاتصال (ct zone) في نواة لينكس حلاً جذرياً لهذا التعارض مباشرة في مسار معالجة الحزم. من خلال دمج معرف منطقة بحجم 16 بت ضمن مفتاح تجزئة الجلسة، تقسم النواة جدول الحالات العام إلى نطاقات منطقية معزولة بالكامل دون الحاجة إلى تشغيل مساحات أسماء شبكية (network namespaces) تستهلك موارد النظام.

تعارض الحزم بين المستأجرين في مقابل العزل عبر CT Zone:

دون استخدام CT Zone (خطر تعارض مرتفع):
العميل 1: [10.0.0.5:52140 -> 1.1.1.1:443] ──┐
                                            ├──> تطابق مفتاح التجزئة ──> اختلال الجلسة / إسقاط الحزم
العميل 2: [10.0.0.5:52140 -> 1.1.1.1:443] ──┘

مع تفعيل Netfilter CT Zones:
العميل 1: [10.0.0.5:52140 -> 1.1.1.1:443] + المنطقة 100 ──> المسار A [الحالة: ESTABLISHED]
العميل 2: [10.0.0.5:52140 -> 1.1.1.1:443] + المنطقة 200 ──> المسار B [الحالة: ESTABLISHED]

آلية تعارض الخماسيات في نظام Netfilter

لفهم سبب تعطل آليات تتبع الحالة التقليدية عند تشابه الشبكات الفرعية، ينبغي فحص المسار الداخلي ضمن ملف net/netfilter/nf_conntrack_core.c. بمجرد وصول الحزمة إلى خطاف PREROUTING، يستخلص Netfilter البيانات الوصفية ضمن البنية المعيارية التالية:

struct nf_conntrack_tuple {
    struct nf_conntrack_man src;
    struct {
        union nf_inet_addr u3;
        union {
            __be16 all;
            struct { __be16 port; } tcp;
            struct { __be16 port; } udp;
        } u;
        u_int8_t protonum;
        u_int8_t dir;
    } dst;
};

تحسب النواة قيمة التجزئة لهذه البنية باستخدام خوارزميات Jenkins أو SipHash للبحث في جدول التجزئة الشامل nf_conntrack_hash. وعند العثور على سجل مطابق، تربط الدالة resolve_normal_ct() مرجع الجلسة (struct nf_conn) بالمخزن المؤقت للحزمة sk_buff.

عندما تتطابق العناوين الخاصة بين نفقين، يؤدي هذا الإجراء إلى أخطاء فادحة:

  1. تعيد الدالة __nf_conntrack_find_get() جلسة العميل 1 لمعالجة الحزمة الجديدة التابعة للعميل 2.
  2. يقارن مدقق حالات TCP في nf_conntrack_proto_tcp.c أرقام التسلسل. وبما أن مكدس الشبكة المستقل للعميل 2 أنشأ رقم تسلسل أولي (ISN) مختلفاً تماماً، تُصنف الحزمة على أنها خارج نطاق نافذة TCP المقبولة.
  3. يصنف Netfilter الحزمة كحالة TCP_CONNTRACK_SYN_SENT أو INVALID، ويرسل حزمة TCP RST مما يقطع الاتصال على الفور.
  4. تخصص آلية ترجمة عناوين المصدر (SNAT) منافذ خارجية بالاعتماد على السجل الخاطئ، مما يعطل مسار الحزم المرتدة.

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

البنية الداخلية للمناطق: struct nf_conntrack_zone

يتجاوز مفهوم مناطق التتبع هذه العقبات عبر فصل عزل جداول الاتصال عن المحاكاة الافتراضية الشاملة لمكدس الشبكة. المنطقة هي معرف رقمي صحيح يتراوح بين 0 و65535 ملحق بسياق تتبع الحزمة.

في ملف الترويسة include/net/netfilter/nf_conntrack_zones.h، تُعرف بنية المنطقة كالتالي:

struct nf_conntrack_zone {
    u16 id;
    u8 flags;
    u8 dir;
};

#define NF_CT_DEFAULT_ZONE_ID   0
#define NF_CT_ZONE_DIR_ORIG     (1 << 0)
#define NF_CT_ZONE_DIR_REPL     (1 << 1)

عند تفعيل المناطق، يطور Netfilter معادلة التجزئة. فبدلاً من الاقتصار على الخماسية فقط، يدخل المعرف ذو الـ 16 بت zone->id مباشرة في الحساب:

$$\text{مفتاح التجزئة} = \text{hash_tuple}(\text{tuple}) \oplus \text{hash_zone}(\text{zone_id})$$

نظراً لتثبيت معرف المنطقة داخل بنية struct nf_conntrack_tuple_hash، فإن حزمتين متطابقتين في الخماسية تنتميان للمنطقة 100 والمنطقة 200 تستقران في خانتين منفصلتين تماماً في جدول nf_conntrack_hash. وتعمل الجلستان في ذاكرة النظام دون تعارض أو تنافس على الأقفال.

توزيع جدول التجزئة في Netfilter مع عزل المناطق:

جدول nf_conntrack_hash
├── خانة 0x3A4B: [الخماسية: 10.0.0.5:52140 -> 1.1.1.1:443 | المنطقة: 100] (العميل 1)
├── خانة 0x8F12: [الخماسية: 10.0.0.5:52140 -> 1.1.1.1:443 | المنطقة: 200] (العميل 2)
└── خانة 0xC201: [الخماسية: 192.168.1.15:49152 -> 8.8.8.8:53 | المنطقة: 0]   (افتراضي)

يتيح الحقل flags أيضاً إعداد مناطق موجهة بالاستفادة من NF_CT_ZONE_DIR_ORIG وNF_CT_ZONE_DIR_REPL. وبذلك يمكن للمسؤول توجيه حركة المرور الواردة إلى المنطقة 100 في مسار الذهاب، مع إرجاع الردود عبر بوابة تدقيق في المنطقة 0.

تكوين مناطق التتبع باستخدام أداة nftables الحديثة

لتطبيق مناطق التتبع بنجاح، يجب تعيين معرف المنطقة في مرحلة مبكرة جداً من فحص الحزمة، تحديداً ضمن خطاف prerouting بالأولوية raw، قبل بدء آليات التتبع المعتادة.

توفر أداة nftables الحديثة صياغة واضحة لتعيين المناطق بناءً على اسم الواجهة أو نطاق VRF أو علامات الحزم. لنأخذ مثال بوابة تجمع نفقي WireGuard أو IPsec (wg-tenant1 وwg-tenant2) بعناوين متطابقة:

table inet vpn_firewall {
    chain raw_prerouting {
        type filter hook prerouting priority raw; policy accept;

        # تعيين مناطق معزولة وفقاً لواجهة الدخول
        iifname "wg-tenant1" ct zone set 100
        iifname "wg-tenant2" ct zone set 200
    }

    chain forward {
        type filter hook forward priority filter; policy drop;

        # قبول الجلسات المؤكدة والمرتبطة داخل كل منطقة
        ct state established,related accept

        # سياسات التمرير للعميل 1 (المنطقة 100)
        ct zone 100 oifname "eth0" accept

        # سياسات التمرير للعميل 2 (المنطقة 200)
        ct zone 200 oifname "eth0" accept
    }

    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;

        # تطبيق ترجمة العناوين بشكل مستقل لكل منطقة
        ct zone 100 oifname "eth0" masquerade
        ct zone 200 oifname "eth0" masquerade
    }
}

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

للتحقق من الجلسات النشطة ومراقبة عزل المناطق في نظام لينكس، تُستخدم أداة conntrack:

# استعراض جلسات المنطقة 100
conntrack -L -z 100

# استعراض جلسات المنطقة 200
conntrack -L -z 200

تؤكد نتائج الأمر تتبع السجلات باستقلالية كاملة مع عدادات زمنية منفصلة:

tcp 6 431999 ESTABLISHED src=10.0.0.5 dst=1.1.1.1 sport=52140 dport=443 [OFFLOAD] zone: 100
tcp 6 431999 ESTABLISHED src=10.0.0.5 dst=1.1.1.1 sport=52140 dport=443 [OFFLOAD] zone: 200

كفاءة التوجيه وإدارة موارد الذاكرة

من الاعتبارات الأساسية في تصميم الشبكات التأكد من عدم تسبب عزل المناطق في بطء تمرير البيانات. وتثبت الاختبارات العملية أن البحث القائم على المناطق لا يضيف أي تأخير ملحوظ مقارنة بجدول conntrack الموحد التقليدي.

نظراً لدمج قيمة المنطقة مباشرة في مفتاح التجزئة ذي الـ 64 بت، لا تتطلب معالجة الخانة أي وصول إضافي لمؤشرات الذاكرة. وتجري حلقة المقارنة في الدالة nf_conntrack_tuple_equal() مطابقة المعرف zone->id وعناوين IP معاً عبر عمليات معالجة سريعة للغاية على مستوى المسجلات.

مقارنة أداء التمرير وفقاً لنموذج العزل المعتمد:
────────────────────────────────────────────────────────────────
معمارية العزل المستخدمة     سرعة التمرير (Mpps)   الذاكرة لكل عميل
────────────────────────────────────────────────────────────────
مساحات أسماء الشبكة (netns)  1.85 Mpps             نحو 4.2 ميغابايت
مناطق التتبع (ct zone)       3.42 Mpps             0 ميغابايت (ذاكرة مشتركة)
التوجيه غير المحفوظ للحالة   3.55 Mpps             0 ميغابايت (دون جلسات)
────────────────────────────────────────────────────────────────

لتهيئة البوابات الضخمة التي تستقبل مئات الآلاف من الاتصالات المتزامنة عبر مناطق متعددة، ينصح بضبط معلمات النواة التالية:

# زيادة سعة جدول التجزئة لتقليل طول سلاسل التصادم
echo 262144 > /sys/module/nf_conntrack/parameters/hashsize

# رفع الحد الأقصى لعدد الاتصالات المتتبعة في الوقت نفسه
sysctl -w net.netfilter.nf_conntrack_max = 1048576

# تسريع استرداد جلسات TCP الخاملة
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established = 86400
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60

من خلال ضبط hashsize ليلائم ذروة الحركة المتوقعة، يبقى متوسط عمق السلاسل أقل من عنصرين لكل خانة، مما يضمن زمناً ثابتاً للبحث بمستوى $O(1)$ حتى عند خدمة مئات المؤسسات بشبكات فرعية متطابقة.

التطبيق العملي في شبكات VPN المؤسسية

في البيئات الشبكية الحديثة، تعد مناطق التتبع الركيزة الأساسية لمنع تسرب البيانات. وعند دمجها مع جداول التوجيه الافتراضية VRF أو التوجيه القائم على القواعد (ip rule)، تضمن تقنية ct zone فصلاً محكماً في الطبقتين الثالثة والرابعة:

  1. فرز حزم الدخول: تربط البوابة الحزم الواردة بالمنطقة المخصصة بناءً على الواجهة أو معلمات النفق المشفر.
  2. فرض قيود الأمان: تمنع قواعد جدار الحماية أي تواصل غير مصرح به بين المناطق المختلفة.
  3. ترجمة آمنة للعناوين: تطابق آليات NAT في النواة العناوين الداخلية المتشابهة مع منافذ عامة دون اختلاط الجلسات.

تطبق منصة VPNRice هذه الحلول المتقدمة مباشرة في بنية نظام RiceGuard. ومن خلال الجمع بين مناطق تتبع الاتصال في نواة لينكس والتشفير عالي الحماية وتقنيات منع تسرب DNS الآلية، يقدم RiceGuard شبكة موثوقة متعددة المستأجرين تقضي كلياً على تعارض العناوين مع المحافظة على السرعة القصوى للشبكة.

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