سفر به اعماق پروتکل های مسیریابی: Link State ها (۲)

سلام به همه ی همراهان عزیز. اگر از مطلب قبل یادتون باشه، گفتیم که پیچیده ترین و مهم ترین بخش عملکرد Link State ها مربوط می شد به جریان Link State Information ها در ساختار. و گفتیم برای این که این جریان درست انجام بشه از فیلدهایی داخل فرمت Link State Information (اگر براتون سواله که چرا من از لفظ Link State Information استفاده می کنم، در قسمت قبل این موضوع رو توضیح دادم 🙂 ) استفاده می شد که یکی از اون ها Sequence Number بود. طراحی عملکرد این فیلد تاثیر زیادی بر نحوه ی فلودینگ Link State Information ها میذاشت. به همین دلیل مدل های مختلفی برای نحوه ی عملکرد این فیلد معرفی شد که عبارت بودند از : Linear , Circular و Lollipop. قصد داریم تا در این مطلب، با هم این مدل ها رو بررسی کنیم.

***

  • در نظر گرفتن فضای خطی برای Sequence Number:

در این مدل تصمیم بر آن شد که مقدار فیلد Sequence Number در یک بازه ی خطی متناهی از اعداد مثبت قرار داشته باشد. بنابراین اینطور در نظر گرفته شد که اگر Sequence Number، یک فیلد N بیتی باشد مثلا ۳۲ بیتی، حداکثر مقداری که می تواند در آن قرار گیرد: ۴,۲۹۳,۹۶۷,۲۹۶=۲۳۲ ‏‎ خواهد بود. ‏پس بازه ی خطی از ۰ شروع شده و تا ‏‎۴,۲۹۳,۹۶۷,۲۹۶ ادامه می یابد و شمارش Sequence Number هم از صفر شروع شده تا به حداکثر این بازه برسد.

Linear Sequence Number

در این روش اگر چند Link State Information یکسان با Sequence Number های مختلف دریافت می گردید، Link State Information با Sequence Number بزرگتر جدیدتر در نظر گرفته می شد. اما این مدل دو مشکل بزرگ داشت: اول این که در این مدل، بازه به صورت متناهی در نظر گرفته شده بود و  زمان طراحی این مدل فرض بر این بود که مقدار حداکثر بازه، آنقدر بزرگ است که روتر ‏به این مقدار حداکثر نمی رسد. اما این موضوع در نظر گرفته نشد که روتر یک دستگاه است و ممکن است دچار تداخل در عملکرد شده و همین امر باعث شود که مقدار Sequence Number به حداکثر مقدار تعیین شده برای آن برسد. در این صورت اتفاقی که رخ می داد آن بود که کل فرآیند از ‏کار می افتاد و آنقدر منتظر می ماند تا ‏Age‏ آنLink State Information ‎  در تمام ‏دیتابیس ها منقضی شده و حذف شود و حال فرآیند می توانست نمونه ی جدیدی از آنLink State Information ‎  با مقدار حداقل برای Sequence Number را تولید و ارسال نماید. ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: Link State ها (۲)”

سفر به اعماق پروتکل های مسیریابی: Link State ها (۱)

سلام به همه ی همراهان عزیز. اگر با موفقیت از سرزمین Distance Vector عبور کنیم، سرزمین بعدی که بهش خواهیم رسید ‏Link State‏ نام داره. زمانی که از  Link State Routing Protocol ها یاد میشه، اون ها رو ‏هوشمند ولی پر از رمز و راز و پیچیدگی معرفی می کنن. بهتره پیش از ورود به این سرزمین، ‏کمی با خصوصیات این روتینگ پروتکل ها آشنا بشیم!  🙂

***

تاریخچه ی مختصری از تکنولوژی مسیریابی ‏Link State
برخلاف Distance Vector ها که فقط مسیرها را تبلیغ می کنند و هیچ  دیدی از کل شبکه در اختیار قرار نمی دهند، در ‏link state‏ ها روتر، مسیر تبلیغ نمی کند بلکه اطلاعاتی راجع به لینک های متصل به خود، وضعیت این لینک ها و همسایه ‏هایی که به این لینک ها متصل می باشند را به همسایه های خود تبلیغ می کند. روترها تا زمانی که این اطلاعات را از ‏همسایه های خود دریافت نکنند مسیری را برای رسیدن به مقصدی انتخاب نمی کنند. پس می توان اینگونه بیان کرد که:

Link State Routing Protocol

اگر Distance Vector ‏ها حکم یک تابلو سر دو راهی را دارند، Link State ها در حکم یک نقشه ی کامل می باشند.

اما نحوه ی عملکرد ‏link state‏ ها به طور کلی به اینصورت است که:‏

  • تشکیل رابطه ی ‏adjacency‏ یا مجاورت با همسایه ها
  •  معرفی خود به همسایه ها
  • ساخت دیتابیسی از اطلاعاتی که از همسایه ها فراگرفته شده
  • ساخت جدول روت بر اساس اطلاعات دیتابیس تشکیل شده

    ‏تمام عملکرد ‏Link State‏ ها در این چهار خط خلاصه می شود. اما این فقط ظاهر امر می باشد، بیایید دقیق تر بررسی کنیم و ببینیم ‏پشت هر کدام از این موارد چه اتفاقی در حال رخ دادن است.‏

ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: Link State ها (۱)”

پیچیدگی در امنیت شبکه

بحث پیچیدگی کلاً جالبه علی‌الخصوص در شبکه؛ تاجایی که خوندم و شنیدم اولین بار بحث Complexity رو آقای David Mayer مطرح کرد و حتی برای این موضوع در IRTF هم یک Working-group بنام Network Complexity Research Group درنظر گرفته شد. امیدوارم به مرور بتونم بیشتر راجبش بخونم، بهفمم و بیشتر بنویسم.
اولین مطلب در این بحث رو با امنیت شبکه و کارهایی که میکنیم تا جلوی مخاطرات امنیتی رو بگیریم شروع میکنم.

روز به روز ابزارهای جدید امنیتی تولید می‌شن و با کلی تبلیغات و به‌به و چه‌چه روونه‌ی بازار. و از دست بد روزگار گاهی بدون برنامه و با توهم اشتباه اینکه این ابزار مشکلات امنیتی‌مون رو حل می‌کنه، سریع میایم قوی‌ترین فایروال‌ها و آنتی،ویروس‌ها و … خرید میکنیم و یکجوری می‌گنجونیم توی شبکه. حالا هزینه‌های فجیعی که در خرید و نصب و راه‌اندازی میشه که هیچ… از برگزاری منافصه گرفته تا هزینه‌ی مشاور و ناظر و خرید و اجرا و نگهداری و … نمیدونم، گاهی فکر میکنم شاید این بحث‌های صرفه‌جوئی در هزینه و کاهش هزینه‌ها و … فقط حرف هست علی‌الخصوص در سازمان‌ها و شرکت‌های بزرگ، بالاخره بودجه‌اش یجوری میرسه یا یکی میرسونه یا یکی میخواد و میرسونَدِش 🙂

اما ای دریغ که بزرگترین مشکلات امنیتی انقدر بزرگ هستند که دیده نمیشن! و حتی گاهی همون پیچیدگی‌ها به ندیدنشون دامن می‌زنه.

یکی از اولین قدم‌های امنیت اطلاعات، فرهنگ‌سازی در سازمانه؛ در معماری کلان فناوری اطلاعات یک سازمان حتماً باید آموزش‌هایی ساده جهت آشنایی و روش‌های جلوگیری از درز اطلاعات برای کاربران خیلی معمول درنظر گرفته بشه.  مثل اینکه اطلاعات سازمانی رو روی نرم‌افزارهای چت نباید رد و بدل کرد، نباید روی سرویس‌های ثالث مثل Google Drive و Dropbox و … گذاشت و ازین قبیل موارد.

قطعاً در کنار این موارد هم باید یکسری سیاست‌های امنیتی و بقولی Enforcement وجود داشته باشه؛ مثلاْ محدود کردن پورت‌های USB، اجبار استفاده از رمز مناسب، محدود کردن دسترسی به اینترنت برای کاربران و سرورها، گذردادن ترافیک اینترنت از یک پروکسی و …

راهکارهای سخت‌افزاری و نرم‌افزاری امنیتی جزو ملزومات هستن اما باید مراقب بود که طراحی پیچیده نشه؛ جوری نباشه که اگه ساعت ۲ شب با مهندس شیفت تماس گرفته شد سرش رو بکوبونه به میز و نتونه بفهمه مشکل کجاس.
مثلا یک اتفاقی که خیلی جدیداً شنیده میشه اینه که کلاً بیایم و ترافیک مدیریتی شبکه، ترافیک دیتای داخلی، ترافیک اینترنت و .. رو بطور فیزیکی از هم جدا کنیم. متاسفانه خودم هم دوبار همچین طرحی رو مجبور شدم که بنویسم… خب این کار در کنار هزینه‌های سرسام‌آوری که داره، پیچیدگی‌های خاص خودش رو هم خواهد داشت؛ قبلاً شما داشتین فقط یک شبکه رو نگهداری می‌کردین اما حالا چند شبکه! قبول دارم که بعضی سناریوهای خاص لازمه اما نه اینکه همه‌گیر بشه این کار.
در عمده‌ی شبکه‌های بسیار گسترده، تمام این ترافیک‌ها روی یک بستر فیزیکی هستن اما خب طبعاً با استفاده از راه‌کاری‌های مختلف امنیتی که گاهش شامل مجازی‌سازی هم میشه مثل درنظرگرفتن VLAN مجزا (بله VLAN هم نوعی راه‌کار مجازی‌سازی محسوب میشه) یا VRF مجزا (بحث مجازی‌سازی شبکه هم بسیار شیرین هست و سر فرصت خودش انشاالله راجبش می‌نویسم)

احتمالاً همچین اتفاقی رو خیلیا شاهدش بودن:

هیچوقت یادم نمیره زمانی که وارد بازار کار شدم و در اولین کارم بعنوان یک ادمین مشغول شده بودم، تصمیم گرفتیم که سیاست‌های رمزگذاری در شبکه تعیین کنیم (Password Policy). بعد از کلی مشقات تاییدیه گرفتیم و اجرا شد.
یک روز رفته بودم واحد حسابداری برای فیش حقوقی ام که دیدم یکی از کارمندای حسابداری نام کاربری و رمز ورودش به سیستم حسابداری رو روی برگه نوشته و به خیال خودش کلی امنیت به خرج داده بود و چسبونده بود زیر کیبورد!

می‌بینین؟ فرهنگ‌سازی!

چندسال قبل یک شرکت امنیتی بنام AlgoSec از متخصصان امنیت شبکه نظرخواهی کرده بود و یکی از نتایج جالب اون این بود که بیش از نصف این متخصصین اظهار داشتن پیچیدگی‌های امنیتی و تعدد Security Policy ها بالاخره یک موقعی منجر به درز اطلاعات یا قطعی سرویس شده بوده! حالا بیایم و چندتا فایروال بگذاریم پشت سرِ هم 🙂
نمیخوام وارد بحث معماری و طراحی شبکه و امنیت شبکه بشم اما صرفا در رابطه با همین مورد چند فایروال از شرکت های مختلف: برای یه شبکه معمول، خیلی ساده میشه پیشنهاد کرد که در لایه‌ی ارتباط با اینترنت از یک Firewall (چشم، دیواره‌ی آتش) و یک IPS (سیستم پیشگیری از نفوذ) استفاده کرد که خیلی rule های کلی داشته باشند و از وندور A باشن؛ و حالا در لایه‌های درونی‌تر (برای شبکه‌های بزرگ تر با block های مختلف) از فایروال‌های وندور B با رول‌های خاص و بقولی specific استفاده بشه.

فراموش نکنیم که یک شبکه باید مستندسازی بشه، و پر واضحه که مستندسازی یک شبکه با سیاست‌های امنیتی پیچیده چقدر سخت خواهد بود. اگر میخواین Complexity رو از امنیت شبکه اتون دور کنین، بعد از اینکه این مطلب رو خوندین (و اگر دوس داشتین نظرتون رو گفتین و عضو خبرنامه شدین 🙂 ) برین سراغ مستندسازی شبکه. انشاالله که وجود داره اما اگر نیست، بوجود بیارین.

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

بنظرم پیچیدگی بدترین دشمن امنیت اطلاعات هست! من معتقدم هر چیزی در زندگی باید به اندازه باشه؛ شبکه و امنیت شبکه هم اگر زندگیِ ما نباشه، فارغ از اون نیست.
من بشدت علاقمند به RFC1925 هستم؛ این RFC به زبون ساده ۱۲ حقیقت/قانونِ دنیایِ شبکه رو مطرح می‌کنه و آخرین قانونِ اون خیلی نزدیک به این بحث هست:

وقتی دیگه ویژگی‌ای برای “اضافه کردن” باقی نمونده، به این معنی نیست که طراحی [پروتکل] به کمال رسیده؛ بلکه زمانی که دیگه چیزی برای کم‌کردن نیست به نقطه‌ی کامل‌بودن نزدیک شده.

حرف زیاد است و مجال کم. لطفاً نظرتون رو بگین و تجربیاتتون درباره‌ی پیچیدگی‌های امنیتی بنویسین.

ضمناً به نصیحت برخی دوستان پیرو همه‌گیر شدن تلگرام در ایران، کانالی برای وبلاگ ایجاد کردم که با عضو شدن میتونین براحتی از مطالب جدید مطلع بشین. ID کانال networkz هست؛ میتونین براحتی با کلیک کردن در اینجا کانال رو ببنین.

سفر به اعماق پروتکل های مسیریابی: Distance Vector ها (۲)

سلام به همه ی مهندسین گرامی. در این قسمت سعی داریم تا با هم بررسی کنیم که پروتکل های مسیریابی Distance Vector  برای حل مشکلاتی که در پایان قسمت قبل مطرح کردیم، چه راهکارهایی رو به کار می برند.

***

  • اگر از قسمت قبل به یاد داشته باشید، بیان شد که Distance Vector ها بر طبق قانون خود باید کل Routing Table را بعد از گذشت یک بازه ی زمانی مشخص ارسال می کردند. اما تصور کنید روتر X همسایه ای با نام Y دارد و از آن مسیرها به مقاصد A و B را فرا گرفته و در Routing Table خود ثبت نموده است. بازه ی زمانی مشخص می گذرد و X باید تمام مسیرهای موجود در Routing Table خود را با یک پیام آپدیت برای همسایه ی خود یعنی Y ارسال نماید، در این صورت روتر X باید مسیرها به مقاصد A و B ای را که از Y فرا گرفته، دوباره به آن تبلیغ کند.

اینجا دو مساله مطرح می شود: اول این که روتر X با این کار بیهوده به نوعی سبب هدر رفت منابع می شود (پهنای باند برای ارسال جداول روتی با حجم بالا که اکثر مسیرها از طریق همان همسایه فراگرفته شده باشد)

دوم این که فرض کنید مقصد A، از دسترس خارج شود. روتر Y از این موضوع باخبر می شود و قصد دارد تا با یک پیام آپدیت این موضوع رو به همسایه اش اطلاع دهد، اما قبل از این که بتواند این کار را انجام دهد ناگهان آپدیتی از روتر X دریافت می کند مبنی بر این که روتر X به مقصد A که یک گام با آن فاصله دارد، دسترسی دارد. اگر به خاطر داشته باشید بیان شد که Distance Vector ها حکم تابلویی سر دو راهی را دارند که فقط فاصله و جهت تا یک مقصد را اطلاع می دهند، اما این که آیا این اطلاعات واقعا درست است یا نه، هیچ تضمینی نیست. بنابراین روتر Y، حرف X را قبول کرده و دوباره مسیر به مقصد A را با افزایش یک گام به hop-count آن، به جدول روت خود اضافه می کند. به این ترتیب اگر پکتی به مقصد A به دست X برسد، آن را برای Y ارسال می کند و Y دوباره آن را برای X ارسال می کند و این عمل همینطور ادامه پیدا کرده و  Loop در مسیریابی رخ میدهد.

در اینجا قانونی مطرح می شود که : اگر آپدیتی از طریق یک اینترفیس ارسال شود، نباید شامل مسیرهایی باشد که از طریق دریافت پیام آپدیتی از روی همان اینترفیس، فرا گرفته شده باشند. به این قانون یک خطی Simple Split Horizon گفته می شود. پس Simple Split Horizon با سرکوب مسیرها از بروز loop جلوگیری میکند.

ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: Distance Vector ها (۲)”

سفر به اعماق پروتکل های مسیریابی: Distance Vector ها (۱)

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

تقریبا کل دیروز و داشتم در رابطه با این فکر می کردم که نقطه ی شروع مباحثم چی می تونه باشه، نهایتا یاد چند ماه پیش افتادم که تصمیم گرفتم پروتکل های مسیریابی رو خیلی جزیی بررسی کنم. تو شروع این راه فهمیدم اگر میخوام رفتار یک پروتکل مسیریابی رو خوب درک کنم باید هرچی که تا اون لحظه یاد گرفتم رو بذارم کنار و دوباره شروع کنم به یادگیری. من باید تمام پیش فرض ها رو فراموش میکردم و از صفر شروع میکردم. فهمیدم تو این راه مدام ذهنم باید بپرسه چرا؟ چطور؟ و این که پشت هر مساله ی سختی یک مفهوم خیلی ساده بوده که فراموش شده، پس باید از اول با همون مفاهیم ساده که خیلی بهشون اهمیت نمی دادم کارم رو شروع کنم.

تصمیم بر این هست که اون چه دارم تو این مسیر از اول فرا میگیرم با شما به اشتراک بذارم. اما قبل از رفتن سراغ یک پروتکل مسیریابی مشخص و بررسی نحوه ی عملکرد حقیقی یک پروتکل، شروع داستان سفرم رو قصد دارم با همون مفاهیم ساده ولی خیلی مهم که به فراموشی سپرده میشن شروع کنم یعنی: بررسی عملکرد دو دسته ی کلی Distance Vector ها و Link State ها! همیشه داشتن اطلاعات در رابطه با منشا یک موضوع، دید بازتری به آدم در تحلیل اون موضوع خواهد داد (البته به نظر من 🙂 )
برای همین قسمت اول “سفر به اعماق پروتکل های مسیریابی” رو به بررسی رفتار کلی Distance Vector ها اختصاص دادم.

ادامه خواندن “سفر به اعماق پروتکل های مسیریابی: Distance Vector ها (۱)”