همانطور که می دونید مخابرات سرویس اینترانت ملی میده و روش آی پی های invalid عمدتا از رنج 10 هستن
حالا چرا و چگونه این آی پی ها از طریق اینترنت ping می شوند؟
چه نوع پیاده سازی و با چه روشی اینکار انجام می شود ؟
این اتفاق در ایران بعلت این هست که شبکه ی اینترانت ملی و بستر لایه 3 ای که ترافیک اینترنت کشور روی اون جریان داره با هم ارتباط دارند. هیچ تکنولوژی خاصی نیست و صرفاً ارتباط روتینگ بین دو شبکه هست.
اگر اشتباه نکنم روی روترهای Core اصلی بستر اینترانت، Default Route به سمت بستر زیرساخت هست که اینترنت در اون جریان داره و نهایتاً یک IP اینترانتی و یک Valid IP در داخل کشور نسبت بهم reachable هستن.
اگر دوستان بحث یا سوال جالبی در گروه های موجود دیدند و علاقه داشتند که در رابطه با اون مطلب یا مقاله ای کوتاه در وبلاگ نوشته بشه، شدیداً استقبال میکنیم.
همچنین اگر فردی با سبکی که تابحال در وبلاگ مطلب نوشته شده (مفهومی و فارغ از بحث configuration یا فقط یک vendor خاص)، علاقه به همکاری دارند، بسیار خوشحال میشیم تا مارو در جریان بگذارند.
سلام.
تصمیم داریم هر از گاهی مسابقهای برگزار کنیم و با طرح سوالات مفهومی (نه بر اساس سناریوی configuration یا تکنولوژی Vendor خاصی)، و به بهترین پاسخها جایزهی ناقابلی تقدیم کنیم. سوالات هم مختلف خواهد بود، گاهی احتمالاً خیلی ساده اما پایهای، گاهی هم ممکنه مربوط به مباحث پیشرفته و جدید، یا حتی از مطالب وبلاگ.
امیدواریم که با پیشبردن این وبلاگ و اینگونه موارد اندک قدمی در راستای تعالی شبکهها! در کشور عزیزمان داشته باشیم.
این مسابقه به اتمام رسیده و پاسخ سوالات با توضیحات زیر هر سوال درج شده است. جهت اطلاع از مسابقات آتی لطفاً عضو خبرنامه وبلاگ و کانال تلگرام شبکهها! شوید.
و اما اولین مسابقه:
آیا بهتر است روت Static به سمت next-hop نوشته شود و یا به سمت Interface؟ چرا؟ عرف پیادهسازی Static Routing به سه صورت است:
استفاده از Interface خروجی: در این حالت، در پیادهسازی اغلب وندورها روتر فرض را بر Connected بودن مقصد گذاشته و در جدول مسیریابی Route را با Administrative Distance صفر درج میکند که در Best Practice های امروز اتفاق جالبی نیست.
مهم تر از همه، استفاده از پورت خروجی، باعث ARP lookup های متعدد شده و در لینکهای Broadcast منجر به پخش شدن بیهودهی ترافیک ARP میشود. فرض کنید برای یک subnet بزرگ مثل 10.0.0.0/8، که احتمالاً شامل host های متعددی خواهد بود، روتر برای هر host یک lookup کند، و یک entry در ARP Table اضافه کند؛ این امر نه تنها باعث استفاده غیربهینه از Memory شده، بلکه تاثیر بسازیی در افزایش CPU Utilization تجهیز خواهد داشت.
استفاده از next-hop: در این حالت نسبت به مورد قبل، صرفاً یک ARP Entry برای یک Subnet بزرگ ثبت میشود اما فرض کنیم که به دلیلی پورتی که next-hop توسط آن reachable بود down شود؛ در این حالت درصورت وجود یک route برای آن next-hop، روت از جدول مسیریابی حذف نمیشود چرا که روتر بصورت recursive عمل مسیریابی به مقصد اصلی را انجام میدهد (که معمولاً اینکار ناخواسته هست، چرا که در این شرایط احتمالاً استفاده از Dynamic Routing Protocol ها استفاده میشد).
این امر حتی ممکن است برخلاف سیاستهای امنیتی باشد چرا که مثلاً ممکن است در مسیر next-hop، یک IPS یا فایروال یا هر تجهیزی که در لایهی Network Interface (لایه 2 OSI) عملی روی packet انجام میداده bypass شود. همچنین در چنین شرایطی، روتر میبایست دائماً برای پیدا کردن next-hop جدول مسیریابی را بررسی کند که امری ناخواسته است. (نکته: فرض کنید در شبکهای که بدرستی طراحی نشده، next-hop پس از down شدن interface، در Routing Table بصورت recursive با یک route دیگر match شود و packet به جایی فرستاده شود، که نباید!)
ترکیبی از هر دو مورد: در این حالت حتی اگر interface مرتبط با next-hop به هردلیلی down شود و next-hop توسط یک مسیر دیگر بصورت recursive قابل دسترسی باشد، Route از Routing Table حذف میشود و هیچکدام از معایب روشهای قبل رخ نمیدهد. ضمناً این نوع تنظیم، در پیادهسازی اغلب وندورها همچون مورد قبل دارای Administrative Distance یک خواهد بود. این مورد نکتهی اصلی سوال و جواب مدنظر ما بود که کمتر به آن اشاره شد.
فرض کنید در شبکهی زیر، روی روتر R0 قصد دارید یک Static Route برای 10.0.0.0/8 تنظیم کنید. بهینهترین حالت تنظیم این روت چگونه خواهد بود؟
در این سوال با توجه به ترسیم ساختار بصورت point-to-point، حتی با اینکه پورت xe یعنی 10GigabitEthernet، اما استفاده از هر سه حالت از لحاظ عملکرد و بار روی تجهیز تفاوتی ایجاد نخواهد کرد (بجز یک ARP Entry درصورت استفاده از interface که در دنیای امروز قابل چشمپوشی است)؛ اما شاید از دیدگاه نگهداری و مدیریت configuration، استثنائاً در این حالت استفاده از Next-hop به تنهایی بهتر باشد؛ شاید در شرایطی Network Engineer مسئول این شبکه، مجبور شد پورت تجهیز را تعویض کند، و لذا با توجه به استفاده از Next-hop، نیازی به پاک کردن و تنظیم روت جدید نخواهد بود. البته هر سه پاسخ قابل قبول است.
برخی دوستان اشاره کرده بودند که استفاده از /31 اشتباه است چرا که در این حالت Net ID و Broadcast Address درنظر گرفته نشده است. این تصور متاسفانه اشتباه هست. اینجا یک مطلب خوب در اینباره نوشته شده است. کلاً استفاده از /31 در این شکل هیچ دلیل خاصی نداشت و صرفاً جهت آشنایی و شاید اضافه کردن نمک به سوال بود 🙂
لطفاً پاسخ خود به هردو سوال را بعنوان نظر درج کنید. نظرات بمدت 48 ساعت از زمان انتشار مطلب منتشر نخواهند شد. به اولین پاسخ کامل جایزهی ناقابلی تعلق خواهد گرفت.
بروزرسانی 30 آبان
فکر میکنم شروع خوبی داشتیم و استقبال مناسبی شد، برای همین اول از همه از 34 عزیزی که در مسابقه شرکت کردند تشکر میکنیم.
برخی از پاسخها طولانی و حقیقتاً فاصلهدار از جوابی بود که مدنظر ما بود. برخی از پاسخها نیز کلاً در رابطه با Static Routing و موارد دیگر توضیح داده اند اما به نکات اصلی سوال و یا جواب سوال دوم اشارهای نشده بود.
پاسخ سوال همراه با توضیحات مناسب با رنگ سبز زیر هر سوال درج شده اند.
سه پاسخ نزدیک بهم و تقریباً درست دریافت کردیم، که باعث سخت شدن انتخاب بود، اما نهایتاً این پاسخ از آقای Mahmood Sebtonabi صحیحتر از دیگران بود و ایشون برندهی اولین مسابقهی شبکهها هستن که با ایشون توسط ایمیل مکاتبه میکنیم.
بروزرسانی 16 آذر
در تصویر زیر آقای محمود سبط النبی برنده این مسابقه رو در کنار یادگاریِ خیلی خیلی ناقابل مسابقه میبینین.
حتماً در جریان هستین که طی ماه های اخیر حملات DDoS نه تنها قوی تر و طولانی تر، بلکه هوشمندتر شدن. یکی از بدترین انواع اون تقریباً زمانی بود که زیرساخت DNS شرکت Dyn رو تحت تاثیر قرار داد.
البته عمده ی این قطعی ها صرفاً در شمال آمریکا حس میشد چون شرکت Dyn در اقصی نقاط دنیا DNS Server داره و خب جوری طراحی شده که مثلا کاربران آسیا از نزدیک ترین DNS Server جواب میگیرن (Anycast).
میدونیم که DNS مثه دفترچه تلفن اینترنت هست و با توجه به اینکه Dyn یکی از بزرگترین DNS Provider ها هست، خیلی از وبسایت های مهم دنیا هم طی این حملات از دسترس خارج شدن.
نکته ی خیلی بد درمورد این وبسایت ها این بود که فقط از یک DNS Provider استفاده می کردن که به نوعی SPoF محسوب میشه. البته عدم استفاده از چند DNS Provider هم دلایل خاص خودش رو داره که مهمترینش بنظرم سخت شدن نگهداری و مدیرت هست چون باید همیشه مطمئن باشید که هردو Provider رکوردهای یکسان دارند. و خب چه بسی با پیشرفته تر شدن حملات، همزمان چند DNS Provider تحت حمله قرار بگیرن.
نکتهی جالب در رابطه با این حمله استفاده از “چیزهای متصل به اینترنت” بود (Internet of Things). شخصاً همیشه از Internet of Things ترس داشتم و هیچوقت بهش مطمئن نبودم و اینبار خودش رو نشون داد. نمیدونم، اما امیدوارم یک روز این اتفاقات جنبهی خطرات انسانی پیدا نکنه. فکر میکنم بهتره اگر خودمون از اینگونه اشیاء استفاده میکنم سعی کنیم از امنیتشون مطمئن بشیم و اگر در توسعه و تولید این اشیاء نقش داریم روی مباحث امنیتیشون بیشتر و دقیق تر کار کنیم.
یک موضوع مرتبط با این قضیه هم قراری هست تحت عنوان MANRS که مخفف Mutually Agreed Norms for Routing Security هست. هدف MANRS این هست که پروایدر در کنار هم روی یکسری مکانیزم های امنیتی در روتینگ تفاهم داشته باشن. پیشنهاد میکنم حتماً در اینباره مطالعه کنین.
سلام به همه ی همراهان عزیز. در دو قسمت قبلی سعی کردیم تا در رابطه با این که در پروتکل های link state روترها چطور همسایه هاشون رو پیدا می کنن و با اونها ارتباط همسایگی تشکیل میدن و این که چطور خودشون رو به همسایه هاشون معرفی می کنن، توضیح بدیم. در این قست قصد داریم تا با هم بررسی کنیم، بعد از این که روتری معرفی نامه ی سایر روترها در ساختار رو دریافت کرد، اون ها رو کجا ذخیره می کنه و بعد چطور با استفاده از این اطلاعات جدول روت خودش رو می سازه.
Link State Database
بعد از این که روترها معرفی نامه ی خودشون رو در قالب Link State Information ها ارسال کردند، این اطلاعات در دیتابیسی به اسم Link State Databaseذخیره میشه. هر Link State Information باید دارای اطلاعاتی باشه که به کمک اون ها روتر توانایی محاسبه ی کوتاهترین مسیر رو داشته باشه. حداقل این اطلاعات عبارتند از: شناسه ای از روتر تولید کننده ی Link State Information، شناسه ای از همسایه ی متصل به این روتر و Cost یا همون هزینه از روتر تولید کننده ی Link State Information تا همسایش.
خوب فرض کنید یک ساختار ساده مثل تصویر زیر داریم: