یکی از مشکلات بر سر راه Mobile Provider ها فراهم کردن شرایطی است که هاست های IPv6-only بتوانند با سرورهای IPv4-only ارتباط برقرار نمایند. NAT64 مکانیزمی است بر پایه ی Network Address Translation (NAT) که با نگاشت آدرس IPv6 هاست متصل به پروایدر به یک آدرس IPv4، این مشکل را برطرف می سازد. ادامه خواندن “مکانیزم های مهاجرت به IPv6: راهکار NAT64”
دسته: شبکه
تغییر رفتار پیش‌فرض eBGP با RFC8212
پیرو Route Leakageهای مختلفی که در دنیای اینترنت رخ داده‌است، و همینطور نیاز مبرم Service Providerها، از اواسط سال 2015، در IETF گروه GROW بحثی شروع شد مبنی بر طراحی یک رفتار پیش‌فرض BGP در رابطه با تبادل روت‌ها با همسایگان خارجی (eBGP).
همانطور که می‌دانید در RFCهای مرتبط با BGP، علی‌الخصوص RFC4271، تابحال توضیحی در رابطه با رفتار پیش‌فرض همسایه‌های eBGP در تبادل روت‌ها زمانی که Policy خاصی اعمال نشده، ارائه نشده است، و این امر باعث شده که هر وِندوری رفتار سلیقه‌ای داشته باشد.
فارغ از جزئیات، بعنوان نمونه می‌توان به مدل‌های پیاده‌سازی زیر اشاره کرد:
- بطور پیش‌فرض دو همسایه eBGP، زمانی که Policy خاصی روی ارتباطات eBGP تنظیم نشده باشد، روت‌های انتخاب‌شده در BGP Table خود را به یکدیگر ارسال می‌کنند و از یکدیگر قبول می‌کنند.
- هیچ روتی ارسال نمی‌شود و هیچ روتی قبول نمی‌شود (discard) مگر اینکه Policy متناسبی تنظیم شده باشد.
- برخی پیاده‌سازی‌ها هیچ روتی قبول نمی‌کنند و فقط روت‌های مربوط به AS خود را advertise می‌کنند.
مثلاً در حالت مثال اول، یکی از مخاطرات ممکن زمانی است که یک AS ناخواسته ترانزیت ارتباط بین ASهای دیگر می‌شود (در RFC7908 توضیح خوبی درباره‌ی Lateral ISP-ISP-ISP Leak همراه با دو بررسی دقیق در قسمت منابع، ارائه شده) ادامه خواندن “تغییر رفتار پیش‌فرض eBGP با RFC8212”
MPLS و MPLS-TE مقدمه‌ای برای Segment Routing
از زمانی که احساس شد مسیریابی صرفا بر اساس مقصد همیشه خوب و دلخواه نیست، ایده ی تعیین شرایط مسیریابی در مبدا متولد گشت و برای تحقق این ایده، مدام راهکارهای مختلفی مطرح شد: از PBR تا رفتن به سمت MPLS و سپس پیشرفت آن به MPLS-TE و نهایتا معرفی روشی با نام Segment Routing.
به این ترتیب تعیین شرایط مسیریابی در مبدا یا به عبارت بهتر، انجام Source Routing که روزی تنها در حد یک ایده بود، روز به روز به یک واقعیت و منطق جدید در مسیریابی نزدیکتر شد. آنچه سبب شده تا ایده ی Source Routing بیشتر به واقعیت نزدیک شود، راهکار Segment Routing می باشد. برای درک بهتر عملکرد Segment Routing ابتدا بهتر است مروری بر عملکرد MPLS و MPLS-TE داشته باشیم.
MPLS و ارسال پکت ها
تکنولوژی MPLS، تکنولوژی با قدمتی تقریبا 20 ساله و آشنا برای مهندسین اینترنت می باشد. مبنا و اساس کار MPLS بر پایه ی دو مفهوم Control Plane و Forwarding Plane بوده و به صورت خلاصه نحوه ی عملکرد آن به این صورت است که:
به مجموعه ای از روترها که توانایی پردازش و تشخیص Label ها را داشته باشند اصطلاحا Label Switch Router یا به اختصار LSR گفته می شود. در دامنه ی MPLS که شامل مجموعه ای از LSR هاست، به هر کدام از LSR ها نقشی داده می شود. اولین LSR ای که در لبه ی دامنه ی MPLS قرار دارد و پکتی را از خارج این ساختار به داخل دامنه ی MPLS فوروارد می کند اصطلاحا Ingress LSR نامیده می شود و به روتری که در لبه ی انتهایی دامنه ی MPLS قرار دارد و پکتی را از داخل دامنه ی MPLS به خارج این ساختار ارسال می کند، اصطلاحا Egress LSR گفته می شود.
به مسیری که یک پکت از یک Ingress LSR تا یک Egress LSR طی می کند اصطلاحا LSP یا Label Switched Path گفته می شود که این مسیر یا بر اساس کوتاهترین مسیر محاسبه شده توسط IGP ها مشخص می گردد و یا بر اساس پارامترهای Traffic Engineering یا به اختصار TE. ادامه خواندن “MPLS و MPLS-TE مقدمه‌ای برای Segment Routing”
زوایای پنهان عملکرد IPv6؛ مزایا و تصورات اشتباه
در نوشته ها و گفته های متعدد در رابطه با IPv6 با این عبارت روبه رو می شویم که:
IPv6 عملکرد بهتری نسبت به IPv4 دارد.
و گاهی در پی این عبارت دلایلی نیز آورده می شود. اما چه میزان این مطلب و دلایلی که در پی آن به عنوان مواردی برای بهبود عملکرد IPv6 مطرح می شوند، صحت دارند؟ بیان بسیاری از این دلایل شاید تنها در وجهه‌ی عمومی و همراه ساختن عموم جامعه در حرکت به سمت استفاده از IPv6 قانع‌کننده و مقبول باشند اما از لحاظ فنی این انتظار وجود دارد که یک کارشناس حوزه‌ی اینترنت، توانایی استدلال در رد یا قبول هر یک از دلایلی که در پی این عبارت مطرح می شوند را داشته باشد. در این مقاله قصد داریم تا نگاهی فنی تر به این دلایل داشته باشیم.
***
در IPv6 انجام تغییراتی در ساختار و قالب این پروتکل سبب ایجاد بهبود کارایی آن در برخی موارد گشته که عبارتند از:
1- فضای آدرس دهی بسیار بزرگتر
اولین مزیتی که برای IPv6 بیان می شود آن است که IPv6 فضای آدرس دهی بزرگتری نسبت به IPv4 داشته و به همین دلیل می تواند تعداد آدرس های بیشتری را فراهم آورد. بله این عبارت درست است! IPv6 به دلیل 128 بیتی بودن قادر است تقریبا 3.4*10^38 آدرس ممکن را فراهم کند که با گسترش شبکه ها و افزایش دستگاه هایی که توانایی اتصال به اینترنت را دارند، این مقدار آدرس IP تا مدت های زیادی جوابگوی نیازها خواهد بود. اما این موضوع چه ارتباطی با بهبود عملکرد IPv6 دارد؟
تصور کنید آنقدر آدرس IP وجود دارد که هر دستگاه می تواند Public IP (آدرس عمومی اینترنی) متعلق به خود را داشته باشد. دقت کنید که گفته شد آدرس Public IP. بله دقیقا منظور آدرس های IP ای هستند که در دنیای اینترنت قابل مسیریابی می باشند. به نظر شما زمانی که هر دستگاه بتواند یک آدرس Public IP مخصوص به خود داشته باشد و خود به صورت مستقیم به اینترنت متصل گردد، چه مزیتی وجود خواهد داشت؟
برای رسیدن به جواب این سوال، به چندین سال قبل، زمانی که برای اولین بار احساس شد که آدرس های عمومیِ IPv4 رو به اتمام هستند، باز می گردیم. در آن زمان اولین راهکاری که برای نجات IPv4 از این اوضاع مطرح شد، راهکاری به اسم Network Address Translation یا همان NAT بود.
عملی که این راهکار انجام می داد آن بود که دستگاه‌هایی که در داخل یک ساختار (مثلا دستگاه های داخل یک سازمان یا دستگاه های داخل خانه و یا …) قرار داشتند، برای آن که بتوانند با هم ارتباط برقرار نمایند، از آدرس هایی استفاده می کردند معروف به Private IPv4 (RFC1918) که این آدرس ها در اینترنت قابل مسیریابی نبودند و اگر قرار بود این دستگاه ها به اینترنت متصل شوند و با سایر دستگاه ها در دنیای اینترنت ارتباط داشته باشند، Private IP آن ها توسط gateway آن ساختار (مثلا مودم یا روتر) به یک Public IP ترجمه می شد. به این ترتیب دیگر نیازی نبود که همه‌ی دستگاه های درون یک ساختار یک IP آدرس Public مجزا و مخصوص به خود داشته باشند، بلکه کافی بود به کل ساختاری که دستگاه ها در آن قرار داشتند تنها یک آدرس عمومی IPv4 تعلق گیرد و هر دستگاهی که قصد برقراری ارتباط با اینترنت را داشت، آدرس Private آن به آدرس Public اختصاص یافته به ساختار ترجمه می گشت. ادامه خواندن “زوایای پنهان عملکرد IPv6؛ مزایا و تصورات اشتباه”
DOTS، روشی جدید در مواجهه با حملات DDoS؟
این روزها حملات DDoS به بخش لاینفکی از دنیای اینترنت مبدل شده‌اند و روز به روز نیز در حال پیچیده‌تر و قوی‌تر شدن می باشند.
طبعاً شرکت‌های مختلفی وجود دارند که سرویس‌های DDoS Protection/Mitigation ارائه کرده و هر یک از آن‌ها نیز راهکارها و روش های خاص خود را دارند (گاهی نیز شبیه به هم).
جدای از بحث استفاده از تجهیزات مقابله با DDoS در شبکه‌ها، زمانی که از یک سرویس‌دهنده‌ی بیرونی استفاده می‌شود، بطور خیلی کلی، معمولا دو حالت پیاده‌سازی (با استفاده از BGP و Tunnel) وجود دارد (معروف به Diversion/Reinjection یا Offramping/Onramping):
- کل ترافیک دائماً از طریق آن سرویس‌دهنده عبور داده شود و اگر حمله‌ای وجود داشته باشد، همانجا مانده و تنها (به اصطلاح) ترافیک پاک به شبکه برسد (Scrubbing).
- فقط زمانی که شبکه تحت حمله قرار می‌گیرد، طی یکسری عملیات و تغییر routing، ترافیک ورودی به شبکه بجای آن که مستقیم از اینترنت به شبکه وارد شود، مانند مدل قبل به سمت یک سرویس‌دهنده هدایت شده و توسط آن بررسی شده و تنها ترافیک پاک به شبکه می‌رسد. این روش، به نوعی On-demand محسوب می شود و کل عملیات و تغییر روتینگ می تواند به صورت خودکار و یا بصورت دستی توسط یک اپراتور رخ دهد.
