تحويل مقابس لينكس عبر eBPF Sockmap و sk_msg لوكلاء VPN

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

يقدم نواة لينكس حلا تقنيا عبر مرشح حزم بيركلي الموسع (eBPF) من خلال دمج جدول BPF_MAP_TYPE_SOCKMAP (أو SOCKHASH) مع برنامج BPF_PROG_TYPE_SK_MSG. ومن خلال العمل مباشرة على مستوى واجهة المقابس بدلا من معالجة حزم الشبكة في الطبقات السفلية، تقوم هذه التقنية بتمرير البيانات مباشرة من مخزن المقبس المرسل إلى طابور استقبال المقبس المستهدف، مما يلغي تماما متطلبات تجزئة TCP وحسابات مسارات التوجيه والمقاطعات البرمجية لواجهة الاسترجاع الداخلي (loopback).

تكلفة المعالجة المزدوجة في معمارية الوكلاء المحليين

لفهم القيمة المضافة لتقنية sockmap، نتتبع مسار تدفق البيانات غير المسرعة عبر وكيل شبكة محلي:

[ تطبيق المستخدم ]
       | write() / sendmsg()
[ طبقة المقابس: طابور الإرسال ]
       v
[ آلة حالات TCP (التحكم بالازدحام، إشعارات الوصول، الموقتات) ]
       v
[ طبقة بروتوكول الإنترنت IP (البحث في جدول التوجيه) ]
       v
[ جدار الحماية Netfilter / iptables (جداول المعالجة) ]
       v
[ واجهة الاسترجاع الداخلي Loopback (معالجة ksoftirqd) ]
       v
[ جدار الحماية Netfilter / iptables (جداول الإدخال) ]
       v
[ طبقة بروتوكول الإنترنت IP (توجيه التسليم المحلي) ]
       v
[ آلة حالات TCP (التحقق من التسلسل وإعادة التجميع) ]
       v
[ طبقة المقابس: طابور الاستقبال لوكيل VPN ]
[ عملية وكيل VPN ]

عندما يرسل تطبيق بيانات بحجم 64 كيلوبايت إلى منفذ محلي لوكيل VPN، تخصص النواة هياكل الذاكرة sk_buff، وتحسب المجموع الدوري، وتمرر البيانات عبر قواعد جدار الحماية وتولد مقاطعات تشغيل المعالج. وعندما تقرأ عملية الوكيل هذه البيانات لتوجيهها إلى نفق التشفير (مثل بروتوكول RiceGuard)، تتكرر هذه المراحل بالكامل مرة ثانية.

ومع وجود آلاف الاتصالات النشطة، تستهلك هذه العمليات التكرارية أكثر من 25% من قدرة المعالج، مما يؤدي إلى تراجع كفاءة الذاكرة المخبأة وارتفاع زمن الاستجابة في لحظات الذروة.

البنية التقنية: تكامل BPF Sockmap مع برامج sk_msg

تعتمد آلية التوصيل المباشر بين المقابس على برنامجي eBPF يعملان بتنسيق مع جدول تجزئة مركزي داخل النواة:

1. تسجيل المقابس عبر BPF_PROG_TYPE_SOCK_OPS

يرتبط هذا البرنامج بهيكل مجموعات التحكم cgroup، ويستدعى تلقائيا مع كل تغير في حالة المقبس مدعوما بسياق bpf_sock_ops.

وعند اكتمال إنشاء الاتصال في حدثي BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB و BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB، يستخرج البرنامج بيانات المقبس الرباعية:

struct sock_key {
    __u32 sip4;
    __u32 dip4;
    __u32 sport;
    __u32 dport;
};

struct {
    __uint(type, BPF_MAP_TYPE_SOCKHASH);
    __uint(max_entries, 65536);
    __type(key, struct sock_key);
    __type(value, __u64);
} proxy_sock_map SEC(".maps");

SEC("sockops")
int bpf_sockmap_ops(struct bpf_sock_ops *skops) {
    if (skops->family != AF_INET)
        return 1;

    switch (skops->op) {
    case BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB:
    case BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB: {
        struct sock_key key = {
            .sip4  = skops->local_ip4,
            .dip4  = skops->remote_ip4,
            .sport = bpf_ntohl(skops->local_port),
            .dport = skops->remote_port,
        };
        /* تسجيل مؤشر المقبس في جدول تجزئة النواة */
        bpf_sock_hash_update(skops, &proxy_sock_map, &key, BPF_ANY);
        break;
    }
    default:
        break;
    }
    return 1;
}

يؤدي استدعاء bpf_sock_hash_update إلى حفظ هيكل المقبس (struct sock *) في جدول proxy_sock_map، مع استمرار التطبيقات في استخدام واجهات المقابس الاعتيادية دون أي تعديل في شفراتها البرمجية.

2. التوصيل المباشر للرسائل عبر BPF_PROG_TYPE_SK_MSG

يرتبط المكون الثاني بنقطة التدقيق BPF_SK_MSG_VERDICT في الجدول. وعند تنفيذ التطبيق لأمر إرسال، يباشر البرنامج مهمته قبل تحويل البيانات إلى حزم شبكية:

SEC("sk_msg")
int bpf_sk_msg_redirect(struct sk_msg_md *msg) {
    struct sock_key lookup_key = {
        .sip4  = msg->remote_ip4,
        .dip4  = msg->local_ip4,
        .sport = msg->remote_port,
        .dport = bpf_ntohl(msg->local_port),
    };

    /* نقل البيانات مباشرة إلى طابور المقبس النظير */
    int ret = bpf_msg_redirect_hash(msg, &proxy_sock_map, &lookup_key, BPF_F_INGRESS);
    if (ret == SK_PASS)
        return SK_PASS;

    return SK_PASS;
}

تحدد الدالة bpf_msg_redirect_hash المقبس المطلوب في الجدول وتحول سلسلة البيانات فورا إلى طابور الاستقبال (sk_receive_queue) للمقبس الآخر:

• عدم الحاجة إلى إنشاء هياكل حزم sk_buff.
• الحفاظ على تسلسل حزم طبقة النقل على مستوى المقبس دون توليد حزم مادية.
• تجنب معالجة قواعد جدار الحماية Netfilter مرة أخرى.
• القضاء على مقاطعات التشغيل البرمجية المرتبطة بواجهة الاسترجاع.

قياسات الأداء الميداني والمقارنة المعيارية

أظهرت الاختبارات العملية لآلية تحويل sockmap على بوابات خوادم لينكس فروقا جوهرية في الإنتاجية وسرعة المعالجة:

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

الاستخدام في منظومة VPNRice وبروتوكول RiceGuard

وظفت شبكة VPNRice تقنية تحويل المقابس eBPF sockmap في بواباتها ومحطات عمل لينكس لتعزيز أداء النقل الداخلي:

[ متصفح المستخدم ]
       |
       | (توصيل مباشر للمقابس عبر eBPF sk_msg)
       v
[ وسيط النقل المحلي لبروتوكول RiceGuard ]
       |
       | تشفير آمن عبر ChaCha20-Poly1305 AEAD
       v
[ خادم الاستقبال العالمي Anycast لشبكة VPNRice ]

1. وسطاء RiceGuard المحليون: يتم تبادل البيانات بين التطبيقات والوسيط المحلي بسرعات تضاهي الذاكرة المشتركة، مما يساعد محرك التشفير على استغلال النطاق الترددي للاتصال دون استنزاف المعالج.
2. منع تسرب استعلامات DNS: يتم استقبال استعلامات المنافذ المحلية وتوجيهها مشفرة عبر بروتوكولات DoH/DoT دون إضافة أي تأخير ملحوظ أثناء عبور نطاقات الشبكة المعزولة (network namespaces).
3. التكامل مع الحاويات: في بيئات الاستضافة متعددة الأقسام، توفر هذه التقنية اتصالا سريعا وآمنا بين الحاويات المستقلة دون الحاجة لجسور الشبكات الافتراضية الثقيلة.

المتطلبات الأساسية والتدقيق في لينكس

لتشغيل آلية sockmap، يجب التأكد من توافر دعم معالجة التدفقات في نواة نظام لينكس (الإصدار 5.10 فما فوق):

# فحص إعدادات النواة النشطة
zcat /proc/config.gz | grep -E "CONFIG_BPF_STREAM_PARSER|CONFIG_NET_SOCK_MSG"
# المخرجات المتوقعة:
# CONFIG_BPF_STREAM_PARSER = y
# CONFIG_NET_SOCK_MSG = y

يمكن للمسؤولين مراقبة الجداول وتتبع سجلات التوجيه المباشر في النواة:

# عرض جداول المقابس النشطة
sudo bpftool map list type sockhash

# متابعة سجلات التتبع الفوري
sudo bpftool prog tracelog

يمثل الدمج بين برمجة المقابس على مستوى النواة والبروتوكولات الخفيفة نمطا هندسيا متقدما يضمن أعلى مستويات الكفاءة للشبكات الآمنة.