زیرساخت مسیریابی جهانی اینترنت بر پروتکل دروازه مرزی BGP استوار است. در هر ثانیه، بیش از یکصد هزار سیستم خودگردان (Autonomous System - AS) پیام‌های اعلام مسیر را مبادله می‌کنند تا نحوه عبور بسته‌های IP از شبکه‌های واسطه را برای رسیدن به مقصد تعیین نمایند. برای چندین دهه، این ساختار توزیع‌شده بر پایه اعتماد ضمنی فعالیت می‌کرد؛ به طوری که هر اپراتور شبکه می‌توانست بدون ارائه اثبات ریاضی، پیشوندهای IP یا مسیرهای انتقال را اعلام کند.

استقرار زیرساخت کلید عمومی منابع (RPKI) و سازوکار اعتبارسنجی مبدا مسیر (ROV بر اساس RFC 6811)، نقطه عطف مهمی در ایمن‌سازی مسیریابی اینترنت بود. سازوکار ROV به مسیریاب‌ها اجازه می‌دهد بررسی کنند که آیا سیستم خودگردان ارائه‌دهنده یک پیشوند IP، مجوز معتبر صدور آن را از طریق شناسه ROA دارد یا خیر.

با این وجود، سازوکار ROV دارای یک نقطه کور ساختاری است: این روش صرفاً سیستم خودگردان مبدا (راست‌ترین شماره AS در ویژگی AS_PATH) را بررسی می‌کند. ROV توانایی تشخیص صحت توالی سیستم‌های خودگردان میانی را که بسته‌ها را جابه‌جا می‌کنند ندارد. در نتیجه، شبکه‌های دارای اختلال پیکربندی یا عوامل مخرب می‌توانند گام‌های غیرمجاز را در مسیر درج کنند یا باعث پدیده خطرناک «نشت مسیر BGP» شوند که بدون هشدار، ترافیک جهانی را از مسیرهای فرعی نامناسب عبور می‌دهد.

برای برطرف ساختن این آسیب‌پذیری بنیادین، کارگروه مهندسی اینترنت (IETF) استاندارد ASPA (مجوزدهی به ارائه‌دهنده سیستم خودگردان) را ذیل سند RFC 9319 و مشخصات فنی کارگروه SIDROPS تدوین کرد. استاندارد ASPA اعتبارسنجی رمزنگاری‌شده را برای گام‌های میانی مسیر BGP معرفی می‌کند و پدیده نشت مسیر و جعل مسیرهای ترانزیت را به طور کامل مهار می‌سازد.

+-------------------------------------------------------------------------+
|                  شکاف امنیت زنجیره مسیر BGP: مقایسه ROV و ASPA          |
+-------------------------------------------------------------------------+
|                                                                         |
|  پیشوند شبکه: 198.51.100.0/24   سیستم مبدا: AS65001                     |
|                                                                         |
|  مسیر اعلام‌شده در شبکه BGP AS_PATH:                                   |
|  [اپراتور رده‌اول AS100] -> [شبکه نشت‌کننده AS200] -> [مشتری AS65001]   |
|                                                                         |
|  ۱. اعتبارسنجی مبدا RPKI ROV:                                           |
|     - تنها سیستم خودگردان انتهایی AS65001 را بررسی می‌کند.              |
|     - تطابق پیشوند با گواهی ROA تایید می‌شود -> وضعیت: معتبر (VALID)!   |
|     - نتیجه: ROV نسبت به صلاحیت ترانزیت AS200 کاملاً نابیناست!          |
|                                                                         |
|  ۲. اعتبارسنجی زنجیره تامین RPKI ASPA:                                  |
|     - روابط مشتری و ارائه‌دهنده را گام‌به‌گام بررسی می‌کند.             |
|     - بررسی: آیا AS65001 شبکه AS200 را مجاز دانسته است؟                 |
|     - کشف ترانزیت غیرمجاز و نقض قاعده دره-ممنوع (Valley-Free)!          |
|     - وضعیت: INVALID -> اعلامیه مشکوک پیش از ورود به جدول حذف می‌شود!   |
+-------------------------------------------------------------------------+

محدودیت‌های اعتبارسنجی مبدا مسیر (ROV)

برای درک ضرورت پیاده‌سازی ASPA، باید مرزهای کارکرد ROV را تحلیل کرد. هنگامی که یک سازمان یک رکورد ROA را در پایگاه RPKI ثبت می‌کند، این موجودیت رمزنگاری‌شده یک بلوک IP (مثلاً 203.0.113.0/24) و حداکثر طول پیشوند مجاز را به شماره AS مبدا مورد نظر (مانند AS64496) مقید می‌سازد.

هنگامی که یک مسیریاب مرزی اطلاعیه مسیر BGP را دریافت می‌کند، فرایند ROV دو شرط را بررسی می‌نماید: ۱. آیا پیشوند دریافتی در محدوده رکورد امضاشده ROA قرار دارد؟ ۲. آیا شماره AS موجود در انتهای سمت راست ویژگی AS_PATH با شماره AS ثبت‌شده در ROA مطابقت دارد؟

در صورت برقراری شرایط، مسیر به عنوان Valid علامت‌گذاری می‌شود و در غیر این صورت به عنوان Invalid رد می‌گردد.

اما ROV هیچ‌گونه نظارتی بر شماره‌های AS قبل از مبدا ندارد. یک شبکه سازمانی با چند اتصال بالادستی (multihomed) که دچار خطای پیکربندی شده، یا یک عامل نفوذی، می‌توانند آگهی مسیری تولید کنند که در آن مبدا کاملاً درست است اما زنجیره ترانزیت دستکاری شده است. بدین ترتیب مسیرهای یک شریک همتا به اشتباه برای شریکی دیگر بازپخش می‌شود و بدون آنکه هشداری در سیستم ROV ایجاد شود، ترافیک تغییر جهت می‌دهد.

کالبدشکافی نشت مسیر در پروتکل BGP (استاندارد RFC 7908)

سند RFC 7908 نشت مسیر BGP را انتشار اعلامیه‌های مسیریابی فراتر از دامنه توافق‌شده تعریف می‌کند. در تعاملات میان‌دامنه‌ای اینترنت، مناسبات تجاری بر پایه مدل مشهور گائو-رکسفورد (Gao-Rexford) تعریف می‌شوند:

  • مشتری به ارائه‌دهنده (Customer-to-Provider): مشتری برای دریافت ترانزیت جهانی اینترنت به ارائه‌دهنده بالادست هزینه می‌پردازد.
  • ارائه‌دهنده به مشتری (Provider-to-Customer): ارائه‌دهنده ترافیک را به مشتریان پرداخت‌کننده خود منتقل می‌سازد.
  • همترازی متقابل (Peer-to-Peer): دو شبکه برای تبادل مستقیم ترافیک مشتریان خود بدون پرداخت هزینه ترانزیت همکاری می‌کنند.

بر اساس منطق اقتصادی، الگوهای مسیریابی باید تابع اصل دره-ممنوع (valley-free) باشند. یک شبکه هرگز نباید نقش ترانزیت رایگان را بین دو ارائه‌دهنده بالادست خود، یا بین دو همتراز رایگان ایفا کند. وقتی یک آگهی مسیر به سمت پایین حرکت کرد (از ارائه‌دهنده به مشتری، یا بین دو همتراز)، نباید هرگز دوباره به سمت یک ارائه‌دهنده دیگر یا همتراز دیگر بالا برود.

+-----------------------------------------------------------------------+
|                    نقض قاعده مسیریابی دره-ممنوع (VALLEY-FREE)          |
+-----------------------------------------------------------------------+
|        [ارائه‌دهنده ترانزیت A]              [ارائه‌دهنده ترانزیت B]   |
|                 │                                   ▲                 |
|                 │ (مسیر از بالا به مشتری)           │ (مسیر نشت‌کرده!)|
|                 ▼                                   │                 |
|      +---------------------------------------------------------+      |
|      |               سازمان چنداتصاله AS300                    |      |
|      |    به اشتباه مسیرهای دریافتی از اپراتور A را            |      |
|      |    مستقیماً برای اپراتور بالادست B آگهی می‌کند!         |      |
|      +---------------------------------------------------------+      |
+-----------------------------------------------------------------------+

نشت مسیر معمولاً به دلیل اشتباهات انسانی در پیکربندی رخ می‌دهد؛ مانند اشتباه در فیلترهای خروجی (export route-map) مسیریاب مرزی. با نشت مسیر از شرکت AS300، شبکه‌های مجاور تصور می‌کنند این شبکه اتصالی بهینه و مستقیم ارائه می‌دهد.

در پی این اشتباه، ترافیک عظیمی که باید از فیبرهای پرظرفیت اقیانوسی عبور می‌کرد، به خطوط کم‌ظرفیت شرکت AS300 سرازیر می‌شود. نتیجه این رویداد، تراکم شدید، افزایش تاخیر به چند ثانیه و ریزش انبوه بسته‌هاست.

در موارد واقعی متعددی در تاریخچه اینترنت، مانند نشت ترافیک کاربران موبایل اروپا از طریق شبکه یک کارخانه ذوب‌آهن در سال ۲۰۱۹، میلیاردها بسته رمزشده دچار اختلال جدی شدند در حالی که مکانیزم‌های ROA سنتی هرگز تخلفی را ثبت نکردند.

سازوکار فنی ASPA: تاییدیه رمزنگاری‌شده ارائه‌دهندگان

استاندارد ASPA این مشکل را با تعریف یک زنجیره تایید مبتنی بر رمزنگاری برطرف می‌کند. طبق سند RFC 9319، هر سیستم خودگردان یک رکورد ASPA را در بستر RPKI امضا و ثبت می‌نماید.

یک رکورد ASPA دارای بیانی شفاف و تضمین‌شده است:

  • سیستم مشتری (Customer AS - CAS): سیستم خودگردانی که مجوز را صادر می‌کند.
  • مجموعه ارائه‌دهندگان (Provider AS Set - PAS): لیست سیستم‌های خودگردان بالادستی مجازی که مشتری انتقال ترافیک خود را رسماً به آن‌ها واگذار کرده است.

این ساختار از پروتکل‌های IPv4 و IPv6 پشتیبانی می‌کند. از آنجا که اشیای ASPA درون سلسله‌مراتب گواهی‌های X.509 موجود در RPKI جای دارند، از همان سازوکارهای امنیتی اعتبارسنجی ROA بهره می‌برند. مسیریاب‌های مرزی با اجرای نرم‌افزارهای اعتبارسنج (نظیر Routinator، StayRtr یا rpki-client)، رکوردهای ASPA را در کنار پیشوندها دانلود و اعمال می‌کنند.

الگوریتم اعتبارسنجی ASPA: اعمال قاعده دره-ممنوع

هنگامی که یک مسیریاب مرزی مجهز به ASPA آگهی مسیر BGP را دریافت می‌کند، دنباله شماره‌های AS در ویژگی AS_PATH را با پایگاه داده محلی خود تطبیق می‌دهد.

الگوریتم صحت پیوند جفت‌های مجاور (AS(i), AS(i+1)) را در طول مسیر می‌آزماید: ۱. فاز صعودی (مشتری به سمت بالادست): هنگام حرکت از مبدا به سمت شبکه‌های میانی، هر گام AS(i) -> AS(i+1) باید رابطه معتبر مشتری به ارائه‌دهنده باشد؛ به این معنا که AS(i+1) در رکورد ASPA متعلق به AS(i) ثبت شده باشد. ۲. نقطه اوج (Apex): مسیر به بالاترین سطح معماری ترانزیت (اپراتور رده‌اول جهانی یا اتصال همترازی مستقیم) می‌رسد. ۳. فاز نزولی (ارائه‌دهنده به مشتری): هنگام بازپخش به سمت مقصد نهایی، هر گام AS(i) -> AS(i+1) باید تایید کند که AS(i) به عنوان ارائه‌دهنده در سند ASPA متعلق به AS(i+1) درج شده است.

اگر الگوریتم تغییر جهت از فاز نزولی به فاز صعودی را تشخیص دهد (نقض قاعده دره-ممنوع بر اثر نشت مسیر) یا با رابطه‌ای غیرمجاز برخورد کند، مسیر فوراً وضعیت Invalid دریافت می‌نماید.

مسیریاب‌ها مسیرهای با وضعیت Invalid را کاملاً نادیده می‌گیرند و اجازه نمی‌دهند جداول مسیریابی آلوده شوند.

تفاوت اعتبارسنجی در مسیرهای بالادستی و پایین‌دستی

نوع رابط ورودی مسیریاب، جهت و منطق تحلیل الگوریتم ASPA را تعیین می‌کند:

نوع رابط ورودی الگوی مورد انتظار AS_PATH جهت اعتبارسنجی ASPA هدف امنیتی اصلی
از سمت مشتری توالی کاملاً صعودی (مشتری -> ارائه‌دهنده...) ارزیابی صعودی از مشتری به بالادست جلوگیری از نشت مسیرهای ارائه‌دهندگان دیگر مشتری
از سمت همتراز (Peer) صعودی، یک گام همتراز، سپس نزولی بررسی دوسویه قاعده دره-ممنوع مهار نشت افقی و دستکاری‌های کاذب طول مسیر
از سمت ارائه‌دهنده صعود به نقطه اوج و سپس فرود به مبدا ارزیابی نزولی به سوی مبدا اعلان جلوگیری از انتقال مسیرهای نشت‌کرده مشتریان بالادست

با تکیه بر این اعتبارسنجی‌های ریاضی، نیازی به توافق‌های جداگانه میان شبکه‌های دوردست نخواهد بود و مسیرهای نامعتبر در بدو ورود با سرعت سخت‌افزاری حذف می‌شوند.

خطرات نشت مسیرهای ارتباطی برای تونل‌های VPN

شبکه‌های اختصاصی مجازی تونل‌های امن خود را بر بسترهای فیزیکی عمومی برقرار می‌سازند. با وجود اینکه پروتکل‌هایی نظیر WireGuard و IPsec داده‌ها را با استانداردهای نوین رمزگذاری می‌کنند، اما بسته‌های آن‌ها در لایه فیزیکی تابع تصمیمات مسیریابی پروتکل BGP باقی می‌مانند.

در صورت وقوع نشت مسیر یا جعل دنباله AS در مسیر میان کاربر و کارگزار VPN، سه چالش بنیادین بروز می‌کند:

۱. قطعی سرویس ناشی از بار اضافی گره‌های واسط: مسیرهای نشت‌کرده حجم عظیمی از داده را به شبکه‌های محدود منطقه‌ای روانه می‌کنند. تراکم حافظه موقت (bufferbloat) و افت شدید بسته‌ها، ارسال پیام‌های زنده نگه‌دارنده UDP را مختل کرده و اتصالات تونل را قطع می‌سازد. ۲. ردیابی آماری و تحلیل رفتار زمانی ترافیک: حتی بدون توانایی رمزگشایی، ناظری که ترافیک VPN را به سمت شبکه تحت اختیار خود کشانده، می‌تواند با بررسی الگوهای زمانی و حجم داده‌ها، فعالیت‌های کاربر را با مقاصد اینترنتی مطابقت دهد. ۳. هدایت به سیاه‌چاله شبکه: شبکه‌های نشت‌کننده معمولاً توان ارسال ترافیک به نقطه نهایی را ندارند و بسته‌های VPN تا زمان همگرایی مجدد اینترنت، بدون هیچ پاسخی مفقود می‌گردند.

تدابیر پروتکل RiceGuard و Anycast در مقابله با اختلالات

معماری زیرساختی VPNRice بر پایه حفاظت فعال در برابر تکانه‌های مسیریابی بنا شده است. تلفیق پروتکل اختصاصی RiceGuard و شبکه سراسری BGP Anycast، ارتباط کاربران را در برابر نوسانات جهانی ایمن می‌سازد.

+-----------------------------------------------------------------------+
|                    سپر حفاظتی مسیریابی فعال RICEGUARD                 |
+-----------------------------------------------------------------------+
|  [ ترافیک ارسالی از دستگاه کاربر ]                                   |
|         │                                                             |
|         ▼                                                             |
|  [ آدرس‌های سراسری Anycast ]   -> استقرار در برترین ستون‌های Tier-1   |
|         │                                                             |
|         ▼                                                             |
|  [ فیلتر RPKI ROV + ASPA ]     -> بررسی صحت AS_PATH پیش از پذیرش بسته |
|         │                                                             |
|         ▼                                                             |
|  [ موتور ارتباطی RiceGuard ]   -> رمزنگاری مستقیم ChaCha20-Poly1305   |
|         │                                                             |
|         ▼                                                             |
|  [ ترانزیت در مسیرهای امن ]    -> بدون تاخیرهای ناشی از انحراف مسیر   |
+-----------------------------------------------------------------------+

RiceGuard پایداری شبکه را از طریق تمهیدات زیر حفظ می‌کند:

  • پایش سخت‌گیرانه در اتصالات بالادست: کارگزارهای لبه‌ای VPNRice منحصراً با اپراتورهایی همکاری می‌کنند که فیلترهای ROV و اعتبارسنجی ASPA را در تمامی درگاه‌های خود فعال کرده‌اند.
  • توزیع Anycast چندنقطه‌ای: با انتشار پیشوندهای یکسان در مراکز داده متعدد بین‌المللی، هرگونه نشت محلی ترافیک به طور خودکار با تغییر مسیر به پایگاه‌های مجاور بی‌اثر می‌گردد.
  • بازیابی سریع ارتباط: به دلیل ساختار بهینه‌سازی‌شده بر پایه UDP، در صورت تثبیت مجدد زیرساخت BGP، نرم‌افزار RiceGuard در چند میلی‌ثانیه ارتباط رمزگذاری‌شده را مجدداً پایدار می‌سازد.

کاربران گرامی برای دریافت برنامه‌های کاربردی رایانه و تلفن‌های هوشمند می‌توانند به صفحه دانلود وی‌پی‌ان مراجعه فرمایند.

راهنمای عملیاتی: نحوه انتشار رکوردهای ASPA

برای بهره‌گیری از محافظت ASPA، مدیران سیستم‌های خودگردان باید اطلاعات ارتباطی خود را نزد مراجع ثبت منطقه‌ای اینترنت (RIR) نظیر APNIC، RIPE NCC و ARIN ثبت نمایند.

ثبت اسناد از طریق پرتال اینترنتی RPKI یا سرورهای محلی اختصاصی بر اساس ضوابط RFC 8181 صورت می‌پذیرد.

ساختار داده‌ای یک رکورد ASPA

ساختار استاندارد JSON برای تعریف ارائه‌دهندگان مجاز یک سیستم خودگردان سازمانی (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 ثبت می‌کند.

پس از ثبت، هر آگهی BGP که مدعی انتقال ترافیک این سیستم از طریق واسطه‌ای خارج از این لیست باشد، به عنوان Invalid ارزیابی خواهد شد.

راهنمای پیکربندی مسیریاب: فعال‌سازی ASPA در BIRD و FRR

نرم‌افزارهای مدرن مسیریابی مانند BIRD (نسخه ۲.۱۵ به بالا) و FRRouting قابلیت ارزیابی رکوردهای ASPA را در خود گنجانده‌اند.

نمونه تنظیمات برای نرم‌افزار BIRD 2

در فایل پیکربندی BIRD، پروتکل RPKI به سرویس اعتبارسنج محلی از طریق درگاه RTR (پورت ۸۲۸۲) متصل می‌شود:

# اتصال به اعتبارسنج محلی 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) به عنوان راهکار نهایی امنیت BGP شناخته می‌شد که نیازمند امضای دیجیتال گام‌به‌گام در تمامی هاپ‌ها بود.

با این وجود، BGPSec با موانع جدی روبه‌رو شد:

  • فشار پردازشی بیش از حد: امضای دیجیتال بسته‌ها در ترافیک‌های چندصد گیگابیتی فراتر از توان پردازنده‌های سخت‌افزاری شبکه‌ها بود.
  • رشد غیرعادی حجم داده‌ها: الصاق امضاها باعث قطعه‌قطعه شدن بسته‌های TCP و پر شدن بافرها می‌شد.
  • وابستگی به ارتقای همگانی: در صورتی که یک اپراتور در زنجیره مسیر از این روش پشتیبانی نمی‌کرد، کل اعتبار از بین می‌رفت.

در مقابل، ASPA راهکاری عمل‌گرایانه ارائه می‌دهد: ۱. عدم تغییر در ساختار BGP: فرمت پیام‌های BGP UPDATE در شبکه تغییر نمی‌کند. ۲. بار محاسباتی نامحسوس: بررسی مسیر از طریق مراجعه به جداول حافظه محلی در کسری از ثانیه انجام می‌گیرد. ۳. امنیت یک‌طرفه آنی: به محض آنکه ارائه‌دهنده بالادست شما ASPA را فعال سازد، ترافیک بدون نیاز به ارتقای سراسری جهان ایمن می‌گردد.

اقدامات پیشنهادی برای مدیران و مهندسان شبکه

متخصصان زیرساخت شبکه می‌توانند با اجرای گام‌های زیر سطح ایمنی مسیرهای ارتباطی را ارتقا دهند:

۱. ثبت رسمی مجوزهای ROA: پیشوندهای سازمانی IPv4 و IPv6 را در پایگاه‌های داده معتبر اینترنتی ثبت نمایید. ۲. انتشار تاییدیه‌های ASPA: لیست ارائه‌دهندگان مجاز بالادستی خود را رسماً در سامانه RPKI اظهار کنید. ۳. اعمال فیلتر ROV در مرز شبکه: تنظیمات را به گونه‌ای قرار دهید که هشدارهای ROA_INVALID نادیده گرفته نشوند و بسته‌ها حذف گردند. ۴. به‌روزرسانی سرویس‌های اعتبارسنج: از نسخه‌های جدید برنامه‌های اعتبارسنج RPKI که از جداول ASPA پشتیبانی می‌کنند استفاده نمایید. ۵. پایش مداوم جریان BGP: با تکیه بر سامانه‌های تحلیل مسیر، عبور ترافیک سازمان از مسیرهای پیش‌بینی‌نشده را زیر نظر بگیرید.

ایمن‌سازی شبکه جهانی اینترنت نیازمند فراتر رفتن از اعتبارسنجی مبدا و نظارت بر کل زنجیره مسیر است. پیاده‌سازی ASPA به عنوان پایه‌ای برای مهار نشت مسیر، زیرساختی پایدار و غیرقابل جعل را برای تبادل داده‌های رمزگذاری‌شده در سراسر جهان به ارمغان می‌آورد.