سفر به اعماق پروتکل های مسیریابی: 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 بیتی باشد مثلا 32 بیتی، حداکثر مقداری که می تواند در آن قرار گیرد: 4,293,967,296=232 ‏‎ خواهد بود. ‏پس بازه ی خطی از 0 شروع شده و تا ‏‎4,293,967,296 ادامه می یابد و شمارش 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 ها (1)

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

***

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

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

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

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

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

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

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

بحث پیچیدگی کلاً جالبه علی‌الخصوص در شبکه؛ تاجایی که خوندم و شنیدم اولین بار بحث 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 به زبون ساده 12 حقیقت/قانونِ دنیایِ شبکه رو مطرح می‌کنه و آخرین قانونِ اون خیلی نزدیک به این بحث هست:

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

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

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