كعكات وايرجارد بدون حالة: تدقيق ماك ثنائي الطبقات في النواة

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

تتعثر المعماريات التقليدية مثل OpenVPN وIPsec IKEv2 أمام هذا النوع من الاستهداف؛ فهي تنشئ كتل تحكم بالنقل أو مخازن للارتباط الأمني (SA) بمجرد استلام أول حزمة استكشافية، مما يؤدي إلى نفاد طوابير الذاكرة سريعا. ينهي بروتوكول وايرجارد (WireGuard) هذا الخطر تماما؛ فمن خلال الالتزام الصارم بمبدأ انعدام الحالة (Stateless) قبل إتمام المصافحة، وتطبيق نظام تدقيق رسائل ثنائي الطبقات (mac1 وmac2) مدعوم بكعكات تشفير دورية، يحمي الخادم موارده من الاستنزاف.

في نواة لينكس، تتجسد آلية الدفاع هذه ضمن الملف drivers/net/wireguard/cookie.c. ويكشف فحص تصميمها التعموي كيف تحافظ الأنفاق الحديثة على مرونتها دون منح أي مساحة تخزينية لمرسلين غير موثوقين.

تحدي المصافحة غير المتناظرة والمرونة بدون حالة

يعتمد نمط Noise IK المستخدم في وايرجارد على المصادقة المتبادلة عبر عمليات الضرب السلمي على المنحنى الإهليلجي Curve25519 (X25519). تتطلب هذه العملية الحسابية عددا كبيرا من دورات المعالج مقارنة بالتوجيه الاعتيادي للحزم. فلو استجاب خادم VPN لكل حزمة واردة من النوع الأول (Type 1: Handshake Initiation) بحساب المفتاح المشترك فورا، لاستطاع أي تدفق وهمي من العناوين المزورة احتكار كافة أنوية المعالج وحرمان الاتصالات الحقيقية من الموارد.

يتفادى وايرجارد هذه الثغرة بتقسيم مسار التحقق إلى مستويات حماية مستقلة:

[ استلام حزمة مصافحة أولية ]
              │
              ▼
    التحقق من MAC1 (مفتاح ثابت)
      ├─ غير مطابق ──► إسقاط صامت (Zero Response)
      └─ صالح
              │
              ▼
    هل الخادم تحت حمل مرتفع؟ (ratelimiter.c)
      ├─ لا  ──► تنفيذ الضرب السلمي Curve25519
      └─ نعم
              │
              ▼
    التحقق من MAC2 (كعكة دورية)
      ├─ صالح      ──► تنفيذ الضرب السلمي Curve25519
      └─ غير مطابق ──► إرسال رد Type 3: Cookie Reply (بدون حالة)

في الحالات الاعتيادية وعندما يكون عبء النظام دون الحد المعين في ratelimiter.c، يتحقق الخادم من mac1 ويكمل المصافحة. وعندما يتصاعد الضغط بما يهدد استقرار النواة، يُفعّل الخادم خط دفاعه الثانوي، مشترطا وجود رمز mac2 صالح مشتق من كعكة أمنية صادرة عنه حصرا.

تشريح تدقيق ماك ثنائي الطبقات (`mac1` مقابل `mac2`)

تتضمن كل حزمة مصافحة افتتاحية في وايرجارد حقلين مخصصين بطول 16 بايت في نهايتها: mac1 (البايتات 116 إلى 131) وmac2 (البايتات 132 إلى 147). ويعمل هذان الحقلان كبوابتين متكاملتين:

بوابة mac1: تُحسب وفق الصيغة BLAKE2s-128(key = Hash(Label-Mac1 || Responder_PublicKey), message = packet[0..115]). ونظرا لأن المفتاح مشتق من المفتاح العام للخادم، فلا يستطيع تكوين وسم صالح إلا العميل المهيأ بعنوان الخادم الصحيح. تفشل حزم المسح العشوائي في هذا الفحص ويتم إسقاطها بهدوء تام دون إرجاع أية رسائل تعذر وصول عبر ICMP.
بوابة mac2: تُحسب وفق الصيغة BLAKE2s-128(key = Cookie, message = packet[0..131]). ويغطي نطاق حساب mac2 كامل الحزمة بما في ذلك حقل mac1 الذي تم التحقق منه. والمفتاح المستخدم هو كعكة تشفير مؤقتة يمنحها الخادم فقط للعناوين التي ثبتت ملكيتها.

في الظروف الطبيعية، يرسل العميل حقل mac2 مملوءا بستة عشر بايتا صفريا (0x00). وعندما يدخل الخادم وضع الحماية من الضغط الزائد، تُحرم الحزم التي تحتوي أصفارا أو قيما غير متطابقة من المعالجة المعقدة. وبدلا من تسجيل الجلسة، يبدأ الخادم إجراء التحدي والاستجابة بدون الاحتفاظ بأي حالة.

المعمارية البرمجية لملف `cookie.c`: التحدي والاستجابة بدون حالة

عندما يطلق ratelimiter.c إشارة التحذير من فرط التحميل، تتولى الدالة wg_cookie_checker_create_payload() في cookie.c زمام المعالجة. تركب النواة حزمة بحجم 64 بايت من نوع Type 3: Handshake Cookie Reply بالهيكل التالي:

┌────────────────────────────────────────────────────────┐
│ نوع الحزمة: 3 (1 بايت) │ حقل محجوز: 0 (3 بايت)         │
├────────────────────────────────────────────────────────┤
│ مؤشر المستلم: قيمة sender_index للعميل (4 بايت)        │
├────────────────────────────────────────────────────────┤
│ قيمة Nonce لـ XChaCha20: رقم عشوائي من CSPRNG (24 بايت) │
├────────────────────────────────────────────────────────┤
│ رمز الكعكة المشفر: XChaCha20-Poly1305 (32 بايت)        │
│ - 16 بايت كعكة نص صريح                                 │
│ - 16 بايت وسم مصادقة Poly1305                          │
└────────────────────────────────────────────────────────┘

لا يستهلك بناء هذه الحزمة سوى جزء يسير جدا من دورات المعالج. والأهم من ذلك أن الخادم لا يخصص أي بايت في الذاكرة الديناميكية (kmalloc = 0). يعيد الرد مؤشر العميل sender_index لربطه بالمحاولة القائمة، في حين تُشفر بيانات الكعكة بخوارزمية XChaCha20-Poly1305.

ويشتق مفتاح التشفير المتناظر للكعكة بطريقة حتمية:

Cookie_Encryption_Key = BLAKE2s-256(
    key = Hash(Label-Cookie || Responder_PublicKey),
    message = Initiator_MAC1
)

بما أن قيمة Initiator_MAC1 تم فحصها مسبقا وثبتت صحتها، فإنها تعمل كملح تشفيري فريد لتلك المحاولة، مما يمنع المتنصتين من الحساب المسبق لمفاتيح فك التشفير.

تدوير الإنتروبيا السرية وإثبات ملكية العنوان

الركيزة الأمنية الجوهرية في وايرجارد هي إثبات ملكية المرسل لعنوان IP الخاص به دون الاحتفاظ ببيانات الجلسة. يشتق الخادم الكعكة بالاعتماد على سر داخلي بطول 32 بايت (cookie_checker->secret) مولد عبر مولد الأرقام العشوائية الآمن في النواة (get_random_bytes).

وتربط العملية الحسابية العنوان الفيزيائي للمرسل مباشرة برمز الكعكة:

Cookie = BLAKE2s-128(
    key = cookie_checker->secret,
    message = Initiator_IP_Address || Initiator_Port
)

ولمنع المهاجمين من تجميع الكعكات الصالحة لاستخدامها في هجمات ممتدة، يغير الخادم هذا المفتاح السري كل 120 ثانية تلقائيا (COOKIE_SECRET_MAX_AGE = 120).

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

secret[0]: السر النشط لتوليد الكعكات الجديدة وفحص الحزم المستلمة حديثا.
secret[1]: السر السابق العائد للفترة الزمنية المنصرمة، مما يتيح قبول الحزم عند نقاط التحول الزمني.

عندما يشن المهاجمون طوفانا بالاعتماد على عناوين IP منتحلة، يوجه الخادم حزم الرد Type 3: Cookie Reply نحو تلك العناوين المنتحلة عبر بروتوكول UDP. وبما أن المهاجم لا يتحكم في مسارات تلك العناوين، فإنه لن يتسلم الكعكة المشفرة أبدا.

أما العميل الشرعي فيستلم الرد ويستدعي الدالة wg_cookie_message_consume(). يفك العميل تشفير الرمز، ويسجله في ذاكرته المحلية المؤقتة (peer->latest_cookie)، ويثبت الطابع الزمني cookie_birthdate = jiffies، ثم يعيد فورا إرسال حزمة بدء المصافحة متضمنة حقل mac2 بصورة كاملة. يدقق الخادم في mac2 خلال زمن ثابت O(1)، ويتأكد من حيازة العميل لعنوانه، لينتقل مطمئنا إلى عمليات Curve25519.

التزامن بدون أقفال ومعمارية RiceGuard

تتحقق الكفاءة العالية في cookie.c بفضل هندسته الخالية من الأقفال الإقصائية (Lockless). تجري قراءة المفاتيح المتغيرة واحتساب وسوم ماك ضمن المقطع الحرج المحمي بـ rcu_read_lock(). يؤدي غياب الأقفال الدورانية التنافسية في مسار الاستقبال إلى تمكين كافة أنوية المعالج من تقييم mac1 وmac2 بالتوازي دون إبطاء لناقل الذاكرة.

الحزمة الواردة ──► [طابور Rx ببطاقة الشبكة] ──► قراءة RCU ──► تدقيق BLAKE2s ──► مسار معالجة النواة

في البيئات التشغيلية الضخمة، تواجه البوابات هجمات عاتية تتجاوز ملايين الحزم في الثانية. وفي VPNRice، يرتقي محرك RiceGuard بهذه المنظومة من خلال ربط cookie.c بتقنيات eBPF وXDP (مسار البيانات فائق السرعة).

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