يعتمد نسيج التوجيه العالمي للإنترنت على بروتوكول البوابة الحدودية BGP (Border Gateway Protocol). في كل ثانية، يتبادل أكثر من مئة ألف نظام مستقل (Autonomous System - AS) إعلانات التوجيه لتحديد كيفية انتقال حزم بيانات IP عبر شبكات النقل الوسيطة للوصول إلى وجهاتها. لعقود طويلة، عمل هذا النموذج اللامركزي على مبدأ الثقة الضمنية: كان بإمكان أي مشغل شبكة الإعلان عن بادئات IP أو مسارات عبور دون تقديم براهين رياضية تشفيرية تثبت تفويضه بذلك.

شكل نشر البنية التحتية للمفتاح العام للموارد (RPKI) وآلية التحقق من أصل المسار (Route Origin Validation - ROV، المحددة في المعيار RFC 6811) نقلة نوعية في حماية توجيه الإنترنت. تتيح آلية ROV لأجهزة التوجيه التأكد مما إذا كان النظام المستقل الذي يعلن عن بادئة IP مفوضاً بذلك بالفعل من خلال كائن تفويض أصل المسار (ROA).

ومع ذلك، تعاني آلية ROV من نقطة عمياء هيكلية: فهي تتحقق فقط من النظام المستقل الأصلي (النظام الواقع في أقصى اليمين ضمن سمة AS_PATH). تعجز ROV تماماً عن التحقق مما إذا كانت سلسلة الأنظمة المستقلة الوسيطة التي تنقل البيانات تمثل مسار عبور شرعياً ومفوضاً. يستطيع المهاجمون أو الشبكات التي تعاني من أخطاء في الإعدادات إدخال قفزات وهمية أو التسبب في حدوث تسريبات كارثية لمسارات BGP، مما يؤدي إلى تحويل مسار البيانات الدولية بصمت عبر شبكات غير متوقعة.

ولسد هذه الثغرة، قامت هيئة هندسة الإنترنت (IETF) بتوحيد معيار ASPA (تفويض مزود النظام المستقل) ضمن الوثيقة RFC 9319 وأعمال مجموعة SIDROPS. يقدم معيار ASPA تحققاً تشفيرياً للقفزات الوسيطة في مسار BGP، مما يقضي على تسريب المسارات وتزييفها عبر شبكات العبور الدولية.

+-------------------------------------------------------------------------+
|                فجوة سلامة مسار BGP: المقارنة بين ROV و ASPA             |
+-------------------------------------------------------------------------+
|                                                                         |
|  بادئة IP: 198.51.100.0/24   النظام المستقل المصدر: AS65001             |
|                                                                         |
|  مسار BGP AS_PATH المعلن في الشبكة:                                    |
|  [مزود الفئة الأولى AS100] -> [شبكة تسريب AS200] -> [العميل AS65001]   |
|                                                                         |
|  1. التحقق من المصدر عبر RPKI ROV:                                      |
|     - يفحص فقط AS65001 في نهاية المسار.                                 |
|     - يطابق البادئة مع كائن ROA -> الحالة: صالح (VALID)!                |
|     - النتيجة: ROV عاجز تماماً عن اكتشاف ما إذا كان AS200 مفوضاً!       |
|                                                                         |
|  2. تفويض المزود عبر RPKI ASPA:                                         |
|     - يدقق في علاقات العميل والمزود قفزة تلو الأخرى.                    |
|     - يتحقق: هل فوض AS65001 الشبكة AS200 كمزود عبور صاعد؟              |
|     - يكشف العبور غير المصرح به وانتهاك قاعدة المسار الخالي من الوديان! |
|     - الحالة: INVALID -> يتم إسقاط المسار المسرب فوراً قبل جدول التوجيه!|
+-------------------------------------------------------------------------+

حدود التحقق من أصل المسار (ROV)

لفهم أهمية ASPA، يجب تحديد ما تحميه آلية ROV وما تعجز عن حمايته. عندما تنشئ مؤسسة كائن ROA في مستودع RPKI، يربط هذا الكائن المشفر نطاق عناوين IP (مثلاً 203.0.113.0/24) مع أقصى طول مسموح به برقم النظام المستقل الأصلي المصرح له (AS64496).

عندما يستقبل موجه الحدود إعلاناً لمسار BGP، تدقق آلية ROV في شرطين:

  1. هل تقع البادئة المعلنة ضمن حدود كائن ROA الموقع رقمياً؟
  2. هل يطابق رقم النظام المستقل في أقصى يمين AS_PATH الرقم المحدد في ROA؟

إذا تحقق الشرطان، يُمنح المسار حالة Valid. وإذا أعلن نظام غير مصرح به عن البادئة، يُصنف كـ Invalid ويتم استبعاده.

لكن ROV لا تجري أي فحص على أرقام الأنظمة المستقلة السابقة للمصدر. يمكن لشبكة متصلة بعدة مزودين (multihomed) وتعاني من خطأ فني، أو لجهة مخترقة، توليد إعلان يكون فيه النظام المصدر صحيحاً تماماً بينما تم التلاعب بمسار النقل الوسيط. تستطيع شبكة وسيطة حشر نفسها في المسار أو إعادة توجيه مسارات تعلمتها من نظير إلى نظير آخر، منتهكة السياسات التجارية ومعترضة تدفق البيانات دون إطلاق أي تنبيه من نظام ROV.

تشريح ظاهرة تسريب مسارات BGP (المعيار RFC 7908)

يعرف المعيار RFC 7908 تسريب مسار BGP بأنه انتشار إعلانات التوجيه إلى ما وراء نطاقها المتفق عليه. في توجيه البيانات بين النطاقات، تتبع العلاقات التجارية بين الأنظمة المستقلة نموذج جاو-ريكسفورد (Gao-Rexford):

  • العميل إلى المزود (Customer-to-Provider): يدفع العميل للمزود رسوماً للحصول على عبور شامل للإنترنت.
  • المزود إلى العميل (Provider-to-Customer): ينقل المزود البيانات من وإلى عملائه المشتركين.
  • التناظر المتبادل (Peer-to-Peer): تتبادل شبكتان البيانات الخاصة بعملائهما دون تبادل رسوم عبور.

وفقاً للأعراف الهندسية، يجب أن يظل التوجيه خالياً من الوديان (valley-free). لا يجوز لأي شبكة تقديم عبور مجاني بين اثنين من مزودي الخدمة بالاتصال الصاعد، أو بين اثنين من النظراء المتكافئين. بمجرد أن ينحدر إعلان المسار لأسفل (من مزود إلى عميل، أو بين نظيرين)، لا يمكنه الصعود مرة أخرى إلى مزود أو نظير آخر.

+-----------------------------------------------------------------------+
|                    انتهاك قاعدة التوجيه الخالي من الوديان             |
+-----------------------------------------------------------------------+
|        [مزود العبور الدولي A]              [مزود العبور الدولي B]     |
|                 │                                   ▲                 |
|                 │ (من المزود إلى العميل)            │ (مسار مسرب!)    |
|                 ▼                                   │                 |
|      +---------------------------------------------------------+      |
|      |               مؤسسة AS300 متعددة المزودين               |      |
|      |    أعادت عن غير قصد بث مسارات تعلمتها من المزود A       |      |
|      |    مباشرة إلى روابط المزود B!                           |      |
|      +---------------------------------------------------------+      |
+-----------------------------------------------------------------------+

تحدث تسريبات المسارات عادة نتيجة أخطاء بشرية: كأن يخطئ مهندس في إعداد خرائط التصدير (export route-map) على موجه الحدود، أو يتعطل مرشح تلقائي أثناء صيانة روتينية. عندما تسرب المؤسسة AS300 مسارات المزود A إلى المزود B، تعتقد الشبكات المجاورة أن AS300 توفر مساراً مباشراً وممتازاً.

تتدفق حينها بيانات ضخمة كانت مخصصة للكابلات البحرية العابرة للقارات نحو البنية التحتية المتواضعة للمؤسسة AS300، مما يؤدي فوراً إلى اختناق الحزم، وارتفاع زمن الاستجابة إلى عدة ثوانٍ، وفقدان كارثي للبيانات.

في حوادث شهيرة مسجلة عالمياً — مثل تسريب حركة اتصالات المحمول في أوروبا عبر شبكة مصنع للصلب في عام 2019، وحوادث تغيير مسارات الحوسبة السحابية — سلكت مليارات الحزم المشفرة مسارات خاطئة دون أن تنتهك شروط التحقق المعتادة لـ ROA.

آلية عمل ASPA: التفويض التشفيري للمزودين

يعالج معيار ASPA هذه المشكلة من خلال إنشاء سلسلة ثقة موثقة رقمياً للعلاقات بين الأنظمة المستقلة. بموجب المعيار RFC 9319، يقوم النظام المستقل بإنشاء وتوقيع سجل ASPA وإيداعه في مستودع RPKI.

يتضمن سجل ASPA تفويضاً مدعوماً بتوقيع رقمي موثوق:

  • نظام العميل المستقل (Customer AS - CAS): النظام الذي يصدر التفويض.
  • مجموعة الأنظمة المزودة (Provider AS Set - PAS): القائمة الكاملة للأنظمة المستقلة بالاتصال الصاعد التي يخولها العميل لنقل بياناته وبث إعلانات توجيهه.

يدعم سجل ASPA كلاً من بروتوكولي IPv4 وIPv6. ونظراً لأن كائنات ASPA ترتكز على منظومة شهادات X.509 المعمول بها في RPKI، فإنها ترث نفس خصائص التحقق والأمان التي تتمتع بها سجلات ROA. وتستطيع برمجيات التحقق المحلية (مثل Routinator وStayRtr وrpki-client) تنزيل جداول ASPA ومطابقتها بالتوازي مع فحص البادئات.

خوارزمية التحقق في ASPA: فرض قاعدة المسار الخالي من الوديان

عندما يتلقى موجه حدودي يدعم ASPA إعلاناً لمسار BGP، فإنه يقارن تسلسل قفزات الأنظمة المستقلة في سمة AS_PATH مع قاعدة بيانات ASPA المخزنة محلياً.

تفحص الخوارزمية كل زوج من الأنظمة المستقلة المتجاورة (AS(i), AS(i+1)) على طول المسار:

  1. المسار الصاعد (من العميل إلى المزود): أثناء انتقال البيانات من المصدر نحو المزودين الدوليين، يجب أن تمثل كل قفزة AS(i) -> AS(i+1) علاقة عميل ومزود موثقة؛ أي أن AS(i+1) مذكور صراحة في سجل ASPA الخاص بالنظام AS(i).
  2. القمة (Apex): يبلغ المسار أعلى مستويات شبكات النقل (مزود فئة أولى Tier-1 أو نقطة تناظر مباشر).
  3. المسار الهابط (من المزود إلى العميل): عند توجه المسار نحو المستلم، يجب أن تثبت كل قفزة AS(i) -> AS(i+1) أن AS(i) مسجل كمزود معتمد في سجل ASPA الخاص بالنظام AS(i+1).

إذا رصدت الخوارزمية تحولاً من مرحلة هابطة إلى مرحلة صاعدة من جديد (انتهاك لقاعدة المسار الخالي من الوديان جراء تسريب بين نظراء أو مزودين)، أو إذا احتوى المسار على قفزة غير معتمدة، تُمنح الرسالة حالة Invalid.

تقوم محركات BGP بإلغاء وإسقاط المسارات ذات الحالة Invalid فوراً، مما يمنع المسارات المسربة من التأثير على حركة البيانات في المسارات الرسمية.

التحقق في الاتجاهين الصاعد والهابط

تعتمد طريقة تطبيق خوارزمية ASPA على طبيعة المنفذ الشبكي الذي استقبل إعلان BGP:

نوع المنفذ الوارد بنية AS_PATH المتوقعة اتجاه التحقق في ASPA الهدف الوقائي الأساسي
من عميل تسلسل صاعد بالكامل (عميل -> مزود...) التحقق في الاتجاه الصاعد من العميل للمزود منع العميل من تسريب مسارات مزوديه الآخرين
من نظير (Peer) صعود، قفزة تناظر واحدة، ثم هبوط فحص ثنائي الاتجاه لقاعدة المسار الخالي من الوديان منع التسريبات الجانبية والتلاعب بطول المسار
من مزود صعود للقمة يعقبه هبوط نحو المصدر التحقق في الاتجاه الهابط نحو نظام المصدر منع المزود من تمرير مسارات العملاء المسربة

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

المخاطر المترتبة على تسريب المسارات لأنفاق VPN

تنشئ الشبكات الخاصة الافتراضية أنفاقاً مشفرة عبر مسارات فيزيائية عامة. ومع أن بروتوكولات مثل WireGuard وIPsec تشفر حمولة البيانات بأعلى المعايير، فإن الحزم تظل خاضعة فيزيائياً لقرارات توجيه BGP على مستوى البنية التحتية.

عند حدوث تسريب في مسار BGP أو تغيير غير مصرح به للمسار بين المستخدم وخادم VPN، يتعرض النفق لثلاثة تهديدات:

  1. انقطاع الخدمة بفعل الاختناق: تقود المسارات المسربة تدفقات البيانات الهائلة إلى شبكات محلية محدودة السعة. يؤدي تضخم الذاكرة المؤقتة (bufferbloat) وضياع الحزم إلى تعطل رسائل المحافظة على الاتصال UDP keepalive، وانهيار إنتاجية اتصالات TCP، وانقطاع النفق بشكل متكرر.
  2. تحليل التدفق والبصمة الزمنية: حتى مع تعذر فك تشفير البيانات، يمكن للمتنصت الذي استدرج ترافيك VPN نحو مساره تحليل التباين في أزمنة الوصول وأحجام الحزم لربط نشاط المستخدم بالوجهات النهائية.
  3. سقوط البيانات في فجوات مجهولة (Blackholing): تعلن الشبكات المسببة للتسريب عن مسارات دون امتلاك خطوط ربط فعلية نحو الوجهة، مما يبتلع حزم VPN ويقطع الاتصال حتى يستقر جدول BGP العالمي.

الصمود أمام تذبذب المسارات عبر RiceGuard وتقنية Anycast

تعتمد بنية شبكة VPNRice على التحصين الاستباقي ضد تقلبات مسارات الإنترنت العامة. ومن خلال الجمع بين بروتوكول RiceGuard وتقنية التوجيه الموزع BGP Anycast، يتم عزل ترافيك المستخدمين عن اضطرابات الشبكات العامة.

+-----------------------------------------------------------------------+
|                    درع التوجيه الاستباقي في RICEGUARD                 |
+-----------------------------------------------------------------------+
|  [ ترافيك المستخدم عبر الجهاز ]                                       |
|         │                                                             |
|         ▼                                                             |
|  [ عناوين Anycast الحدودية ]    -> موزعة عبر كبرى شبكات الفئة الأولى   |
|         │                                                             |
|         ▼                                                             |
|  [ تصفية RPKI ROV + ASPA ]     -> فحص AS_PATH بدقة قبل استقبال الحزم  |
|         │                                                             |
|         ▼                                                             |
|  [ نواة نفق RiceGuard ]        -> تشفير مباشر ChaCha20-Poly1305       |
|         │                                                             |
|         ▼                                                             |
|  [ نقل مباشر عبر مسارات نقية ] -> تجنب الانحرافات وتقليل اضطراب النبض|
+-----------------------------------------------------------------------+

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

  • تصفية مشددة مع شبكات الفئة الأولى: ترتبط خوادم VPNRice فقط مع مزودين يطبقون بصرامة فحص RPKI ROV وتصفية ASPA على كافة منافذ الاتصال والتناظر.
  • المرونة الجغرافية مع Anycast: عند الإعلان عن نفس نطاق عناوين IP من مراكز بيانات متعددة حول العالم، يؤدي أي تسريب إقليمي للمسارات إلى تحويل الترافيك تلقائياً وسلساً نحو أقرب نقطة اتصال سليمة.
  • التعافي الفوري للاتصال: بفضل بساطة إرسال الحزم عبر UDP، يعيد بروتوكول RiceGuard استقرار الجلسة المشفرة في أجزاء من الثانية بمجرد استقرار مسار BGP الفيزيائي.

يمكن للمستخدمين تنزيل التطبيقات الآمنة للأجهزة المكتبية والهواتف المحمولة من خلال صفحة تنزيل VPN.

الخطوات التطبيقية: إنشاء ونشر سجلات ASPA

لتفعيل حماية ASPA، يتعين على مسؤولي الأنظمة المستقلة تسجيل وتوثيق علاقات المزودين عبر سجلات الإنترنت الإقليمية (RIR) مثل RIPE NCC أو ARIN أو APNIC.

يمكن تسجيل كائنات ASPA عبر البوابة الإلكترونية لمنظومة RPKI التابعة للسجل أو برمجياً عبر خوادم محلية موثوقة استناداً للمعيار RFC 8181.

هيكل سجل ASPA المعياري

فيما يلي تمثيل قياسي لهيكل بيانات JSON الخاص بسجل ASPA لمؤسسة تمتلك النظام المستقل (AS65100) وتحدد مزودي العبور المعتمدين لديها:

{
  "customer_asid": 65100,
  "providers": [
    {
      "provider_asid": 174,
      "afi": "both"
    },
    {
      "provider_asid": 2914,
      "afi": "both"
    },
    {
      "provider_asid": 3356,
      "afi": "both"
    }
  ]
}

في هذا الإعداد:

  • يحدد customer_asid هوية النظام المستقل المالك للمسار.
  • تسرد مصفوفة providers كبرى شركات النقل المعتمدة (Cogent AS174 وNTT AS2914 وLumen AS3356).
  • يشير afi إلى سريان التفويض على حزم IPv4 وIPv6 في آن واحد.

سيتم اعتبار أي إعلان شبكي يزعم أن AS65100 يعبر عبر شبكة وسيطة غير مذكورة كمسار Invalid ويتم نبذه فورياً.

إعداد الموجهات: تفعيل فحص ASPA على برمجيات BIRD وFRR

توفر برمجيات التوجيه مفتوحة المصدر واسعة الانتشار، مثل BIRD (الإصدار 2.15 فما فوق) وFRRouting، دعماً برمجياً مدمجاً لعمليات التحقق من سجلات ASPA.

نموذج إعداد لبرنامج BIRD 2

في ملف إعداد BIRD، يتصل البروتوكول RPKI ببرنامج التحقق المحلي عبر بروتوكول RTR على المنفذ 8282:

# الاتصال ببرنامج التحقق المحلي RPKI RTR
protocol rpki rpki_validator {
    rtr 127.0.0.1 port 8282;
    retry 300;
    refresh 600;
    aspa 4; # تفعيل ASPA لبروتوكول IPv4
    aspa 6; # تفعيل ASPA لبروتوكول IPv6
}

# تعريف مرشح BGP يطبق فحص ASPA
filter ebgp_in_filter {
    # التحقق أولاً من صحة أصل المسار ROV
    if roa_check(rpki_validator, net, bgp_path.last) = ROA_INVALID then {
        reject "Drop: ROV origin invalid";
    }

    # التحقق من صحة سلسلة المسار عبر ASPA
    if aspa_check(rpki_validator, bgp_path, 0) = ASPA_INVALID then {
        reject "Drop: ASPA verification failed (Route Leak detected)";
    }

    accept;
}

يضمن وضع دالة aspa_check عند مرشح الدخول إيقاف المسارات التالفة قبل استهلاكها لموارد جدول معلومات التوجيه (RIB).

المقارنة بين ASPA وBGPSec: الجدوى الهندسية العملية

ظل معيار BGPSec (المنصوص عليه في RFC 8205) لسنوات الحل النظري المكتمل لحماية المسار عبر فرض التوقيع الرقمي على كل قفزة في الشبكة.

لكن التطبيق العملي لـ BGPSec واجه عوائق هندسية حاسمة:

  • استهلاك هائل للقدرة الحاسوبية: توقيع وفحص كل تحديث BGP في مسارات بمئات الجيجابت يتجاوز طاقة المعالجات العتادية في الموجهات.
  • تضخم حجم الحزم: إضافة التوقيعات المتتالية يسبب انقسام حزم TCP وتجاوز سعة الذاكرة التخزينية.
  • اشتراط التبني الشامل: تعطل طرف واحد وسيط في المسار الدولي يؤدي لانهيار سلسلة التحقق بالكامل.

يقدم معيار ASPA بديلاً واقعياً وقابلاً للتطبيق الفوري:

  1. عدم المساس بحزم BGP: لا يتطلب أي تعديل على بنية رسائل BGP UPDATE على الكابلات.
  2. استهلاك معدوم للمعالج: تعتمد المقارنة على عمليات بحث سريعة داخل الذاكرة المحلية المؤقتة.
  3. أمان فوري أحادي الجانب: بمجرد أن يفعل مزودك الصاعد مرشحات ASPA، تصبح شبكتك محمية دون انتظار ترقية كامل شبكات الإنترنت حول العالم.

إرشادات أمن التوجيه لمهندسي الشبكات

يتعين على مهندسي الشبكات ومسؤولي الأنظمة المستقلة تطبيق خطة تأمين متدرجة للبنية التحتية:

  1. إصدار سجلات ROA الرسمية: تسجيل كائنات التحقق من الأصل لكافة نطاقات IPv4 وIPv6 لدى السجلات القارية.
  2. تسجيل بيانات ASPA بدقة: إدراج جميع مزودي العبور المعتمدين رسمياً في منظومة RPKI بما يشمل خطوط الطوارئ الاحتياطية.
  3. تطبيق إسقاط ROV الصارم: ضبط الموجهات لإسقاط أي إعلان يحمل الحالة ROA_INVALID بصورة قاطعة.
  4. تحديث برمجيات الفحص: الترقية إلى إصدارات برمجية تدعم جداول ASPA (مثل Routinator 0.13+ وStayRtr).
  5. مراقبة مسارات BGP: استخدام أدوات المراقبة المستمرة للتأكد من عدم مرور بادئات عناوينكم عبر شبكات وسيطة غير متوقعة.

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