چگونه زیرساخت شبکه خود را کنترل کنیم فصل دوم. نظافت و مستندسازی

این مقاله دومین مقاله از سری مقالات «چگونه کنترل زیرساخت شبکه خود را در دست بگیریم» است. محتویات تمام مقالات این مجموعه و پیوندها را می توان یافت اینجا.

چگونه زیرساخت شبکه خود را کنترل کنیم فصل دوم. نظافت و مستندسازی

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

اکنون ما در مورد ممیزی های امنیتی صحبت نمی کنیم - این موضوع قسمت سوم خواهد بود.

البته دشواری انجام وظیفه محول شده در این مرحله از شرکتی به شرکت دیگر بسیار متفاوت است.

وضعیت ایده آل زمانی است که

  • شبکه شما مطابق با پروژه ایجاد شده است و شما مجموعه کاملی از اسناد را دارید
  • در شرکت شما پیاده سازی شده است فرآیند کنترل و مدیریت تغییر برای شبکه
  • مطابق با این فرآیند، شما اسنادی (شامل تمام نمودارهای لازم) دارید که اطلاعات کاملی در مورد وضعیت فعلی ارائه می دهد.

در این مورد، وظیفه شما بسیار ساده است. باید مدارک را مطالعه کنید و تمام تغییرات ایجاد شده را بررسی کنید.

در بدترین حالت، خواهید داشت

  • شبکه ای که بدون پروژه، بدون برنامه، بدون تایید، توسط مهندسانی که سطح کافی از صلاحیت ها را ندارند ایجاد شده است.
  • با تغییرات آشفته و غیرمستند، با انبوهی از "زباله ها" و راه حل های غیربهینه

واضح است که وضعیت شما جایی در این بین است، اما متأسفانه، در این مقیاس بهتر - بدتر، احتمال زیادی وجود دارد که به بدترین پایان نزدیک شوید.

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

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

مجموعه ای از اسناد

بیایید با یک مثال شروع کنیم.

در زیر برخی از اسنادی که معمولاً در سیسکو سیستمز در حین طراحی ایجاد می شوند، آورده شده است.

CR - نیازهای مشتری، نیازهای مشتری (مشخصات فنی).
به طور مشترک با مشتری ایجاد می شود و نیازهای شبکه را تعیین می کند.

HLD – طراحی سطح بالا، طراحی سطح بالا بر اساس نیازهای شبکه (CR). این سند تصمیمات معماری اتخاذ شده (توپولوژی، پروتکل ها، انتخاب سخت افزار،...) را توضیح و توجیه می کند. HLD شامل جزئیات طراحی، مانند رابط‌ها و آدرس‌های IP مورد استفاده نمی‌شود. همچنین، پیکربندی سخت افزاری خاص در اینجا مورد بحث قرار نمی گیرد. در عوض، این سند برای توضیح مفاهیم کلیدی طراحی برای مدیریت فنی مشتری در نظر گرفته شده است.

LLD – طراحی سطح پایین، طراحی سطح پایین بر اساس طراحی سطح بالا (HLD).
باید شامل تمام جزئیات لازم برای اجرای پروژه باشد، مانند اطلاعاتی در مورد نحوه اتصال و پیکربندی تجهیزات. این یک راهنمای کامل برای اجرای طرح است. این سند باید اطلاعات کافی را برای اجرای آن حتی توسط پرسنل کمتر واجد شرایط ارائه دهد.

چیزی، به عنوان مثال، آدرس‌های IP، شماره‌های AS، طرح سوئیچینگ فیزیکی (کابل‌کشی)، می‌تواند در اسناد جداگانه‌ای مانند پین (طرح اجرای شبکه).

ساخت شبکه پس از ایجاد این اسناد آغاز می شود و مطابق با آنها اتفاق می افتد و سپس توسط مشتری (تست) برای مطابقت با طراحی بررسی می شود.

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

و به نظر من حداقل مطلق خاصی وجود دارد که بدون آن کنترل موثر شبکه غیرممکن است.

اینها اسناد زیر هستند:

  • نمودار (log) سوئیچینگ فیزیکی (کابل کشی)
  • نمودار شبکه یا نمودارهایی با اطلاعات ضروری L2/L3

نمودار تعویض فیزیکی

در برخی از شرکت های کوچک، کارهای مربوط به نصب تجهیزات و سوئیچینگ فیزیکی (کابل کشی) بر عهده مهندسان شبکه می باشد.

در این مورد، مشکل تا حدی با رویکرد زیر حل می شود.

  • از یک توضیح در رابط استفاده کنید تا آنچه را که به آن متصل شده است توصیف کنید
  • تمام پورت های تجهیزات شبکه غیر متصل به صورت اداری را خاموش کنید

این به شما این فرصت را می دهد که حتی در صورت بروز مشکل در پیوند (زمانی که cdp یا lldp روی این رابط کار نمی کند) به سرعت تشخیص دهید که چه چیزی به این پورت متصل است.
همچنین می توانید به راحتی ببینید که کدام پورت ها اشغال شده و کدام یک آزاد هستند که برای برنامه ریزی اتصال تجهیزات شبکه، سرورها یا ایستگاه های کاری جدید ضروری است.

اما واضح است که در صورت از دست دادن دسترسی به تجهیزات، دسترسی به این اطلاعات را نیز از دست خواهید داد. علاوه بر این، در این روش شما نمی توانید اطلاعات مهمی مانند نوع تجهیزات، مصرف انرژی، چند پورت، در چه رک، چه پچ پنل ها و کجا (در چه رک/پچ پنل) را ثبت کنید. ) متصل هستند. بنابراین، اسناد اضافی (نه فقط توضیحات روی تجهیزات) هنوز بسیار مفید است.

گزینه ایده آل استفاده از برنامه هایی است که برای کار با این نوع اطلاعات طراحی شده اند. اما می توانید خود را به جداول ساده محدود کنید (مثلاً در اکسل) یا اطلاعاتی را که لازم می دانید در نمودارهای L1/L2 نمایش دهید.

مهم!

یک مهندس شبکه، البته، به خوبی می تواند پیچیدگی ها و استانداردهای SCS، انواع رک ها، انواع منبع تغذیه اضطراری، راهروی سرد و گرم چیست، نحوه اتصال به زمین را به خوبی انجام دهد ... همانطور که در اصل می تواند فیزیک ذرات بنیادی یا C++ را بدانید. اما هنوز باید درک کرد که همه اینها حوزه دانش او نیست.

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

اگر چنین تقسیم‌بندی‌هایی در شرکت شما ارائه شده است، پس مسائل مربوط به سوئیچینگ فیزیکی مربوط به ورود به سیستم، وظیفه شما نیست و می‌توانید خود را فقط به توضیح در مورد رابط و خاموش کردن اداری پورت‌های بلااستفاده محدود کنید.

نمودارهای شبکه

هیچ رویکرد جهانی برای ترسیم نمودار وجود ندارد.

مهمترین چیز این است که نمودارها باید درک درستی از نحوه جریان ترافیک ارائه دهند که از طریق کدام عناصر منطقی و فیزیکی شبکه شما جریان دارد.

منظور ما از عناصر فیزیکی است

  • تجهیزات فعال
  • رابط ها / پورت های تجهیزات فعال

تحت منطقی -

  • دستگاه های منطقی (N7K VDC، Palo Alto VSYS، ...)
  • VRF
  • ویلان ها
  • رابط های فرعی
  • تونل ها
  • منطقه
  • ...

همچنین اگر شبکه شما کاملا ابتدایی نباشد از بخش های مختلفی تشکیل می شود.
مثلا

  • مرکز اطلاعات
  • اینترنت
  • WAN
  • دسترسی از راه دور
  • LAN اداری
  • DMZ
  • ...

عاقلانه است که چندین نمودار داشته باشید که هم تصویر بزرگ (نحوه جریان ترافیک بین تمام این بخش ها) و هم توضیح مفصلی از هر بخش را ارائه دهد.

از آنجایی که در شبکه‌های مدرن می‌تواند لایه‌های منطقی زیادی وجود داشته باشد، شاید ساخت مدارهای مختلف برای لایه‌های مختلف یک رویکرد خوب (اما نه ضروری) باشد، برای مثال، در مورد رویکرد همپوشانی، این می‌تواند مدارهای زیر باشد:

  • پوشش
  • زیرانداز L1/L2
  • زیرانداز L3

البته مهمترین نموداری که بدون آن درک ایده طراحی شما غیر ممکن است، نمودار مسیریابی است.

طرح مسیریابی

حداقل، این نمودار باید منعکس شود

  • چه پروتکل های مسیریابی و کجا استفاده می شود
  • اطلاعات اولیه در مورد تنظیمات پروتکل مسیریابی (منطقه/شماره AS/شناسه روتر/…)
  • در کدام دستگاه ها توزیع مجدد انجام می شود؟
  • جایی که فیلترینگ و تجمع مسیر رخ می دهد
  • اطلاعات مسیر پیش فرض

همچنین، طرح L2 (OSI) اغلب مفید است.

طرح L2 (OSI)

این نمودار ممکن است اطلاعات زیر را نشان دهد:

  • چه VLAN هایی
  • کدام پورت ها پورت های ترانک هستند
  • کدام پورت ها در کانال اتر (کانال پورت)، کانال پورت مجازی جمع می شوند
  • چه پروتکل های STP و در چه دستگاه هایی استفاده می شود
  • تنظیمات اولیه STP: پشتیبان گیری ریشه / ریشه، هزینه STP، اولویت پورت
  • تنظیمات اضافی STP: محافظ/فیلتر BPDU، محافظ ریشه…

اشتباهات معمولی طراحی

نمونه ای از رویکرد بد برای ساخت شبکه.

بیایید یک مثال ساده از ساخت یک LAN اداری ساده را در نظر بگیریم.

با داشتن تجربه تدریس تلکام به دانشجویان، می توانم بگویم که تقریباً هر دانش آموزی تا اواسط ترم دوم دانش لازم را (به عنوان بخشی از درسی که من تدریس کردم) برای راه اندازی یک LAN اداری ساده دارد.

چه مشکلی در مورد اتصال سوئیچ ها به یکدیگر، راه اندازی VLAN، رابط های SVI (در مورد سوئیچ های L3) و راه اندازی مسیریابی استاتیک وجود دارد؟

همه چیز کار خواهد کرد.

اما در عین حال سوالات مربوط به

  • امنیت
  • رزرو
  • مقیاس بندی شبکه
  • بهره وری
  • توان عملیاتی
  • قابلیت اطمینان
  • ...

گهگاه این جمله را می شنوم که LAN اداری چیزی بسیار ساده است و من معمولاً این را از مهندسان (و مدیران) می شنوم که همه کارها را انجام می دهند به جز شبکه ها، و آنها این را چنان با اطمینان می گویند که اگر شبکه LAN باشد تعجب نکنید. توسط افرادی با تمرین و دانش ناکافی انجام می شود و تقریباً با همان اشتباهاتی که در زیر توضیح خواهم داد، انجام خواهد شد.

اشتباهات رایج طراحی L1 (OSI).

  • اگر، با این وجود، شما نیز مسئول SCS هستید، یکی از ناخوشایندترین میراثی که ممکن است دریافت کنید، تعویض بی دقت و بد فکری است.

من همچنین به عنوان خطاهای نوع L1 مربوط به منابع تجهیزات مورد استفاده طبقه بندی می کنم، به عنوان مثال،

  • پهنای باند ناکافی
  • TCAM ناکافی در تجهیزات (یا استفاده ناکارآمد از آن)
  • عملکرد ناکافی (اغلب مربوط به فایروال ها)

اشتباهات رایج طراحی L2 (OSI).

اغلب، زمانی که درک خوبی از نحوه عملکرد STP و مشکلات احتمالی آن وجود ندارد، سوئیچ‌ها به‌طور آشفته، با تنظیمات پیش‌فرض، بدون تنظیم STP اضافی به هم متصل می‌شوند.

در نتیجه اغلب موارد زیر را داریم

  • قطر شبکه STP بزرگ، که می تواند منجر به طوفان های پخش شود
  • ریشه STP به طور تصادفی (بر اساس آدرس مک) تعیین می شود و مسیر ترافیک کمتر از حد مطلوب خواهد بود.
  • پورت های متصل به هاست ها به عنوان لبه (portfast) پیکربندی نمی شوند، که منجر به محاسبه مجدد STP هنگام روشن/خاموش کردن ایستگاه های پایانی می شود.
  • شبکه در سطح L1/L2 قطعه بندی نمی شود، در نتیجه مشکلات مربوط به هر سوییچ (به عنوان مثال، اضافه بار برق) منجر به محاسبه مجدد توپولوژی STP و توقف ترافیک در تمام VLAN ها در همه سوئیچ ها (از جمله سوئیچ ها) می شود. از نقطه نظر بخش خدمات تداوم حیاتی است)

نمونه هایی از اشتباهات در طراحی L3 (OSI).

چند اشتباه معمولی نتورکرهای تازه کار:

  • استفاده مکرر (یا فقط استفاده) از مسیریابی استاتیک
  • استفاده از پروتکل های مسیریابی بهینه برای یک طراحی معین
  • تقسیم بندی شبکه منطقی نابهینه
  • استفاده نابهینه از فضای آدرس، که اجازه تجمع مسیر را نمی دهد
  • بدون مسیرهای پشتیبان
  • هیچ رزروی برای دروازه پیش فرض وجود ندارد
  • مسیریابی نامتقارن هنگام بازسازی مسیرها (می تواند در مورد NAT/PAT، فایروال های statefull حیاتی باشد)
  • مشکلات با MTU
  • هنگامی که مسیرها بازسازی می شوند، ترافیک از طریق سایر مناطق امنیتی یا حتی دیوارهای آتش دیگر می گذرد که منجر به حذف این ترافیک می شود.
  • مقیاس پذیری توپولوژی ضعیف

معیارهای ارزیابی کیفیت طراحی

وقتی از بهینه بودن/عدم بهینه بودن صحبت می کنیم، باید بفهمیم که از چه معیارهایی می توانیم این را ارزیابی کنیم. در اینجا، از دیدگاه من، مهمترین (و نه همه) معیارها (و توضیح در رابطه با پروتکل های مسیریابی) وجود دارد:

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

تغییرات

اصل اساسی در این مرحله را می توان با فرمول "آسیب نزن" بیان کرد.
بنابراین، حتی اگر کاملاً با طراحی و پیاده سازی انتخاب شده (پیکربندی) موافق نباشید، همیشه توصیه نمی شود که تغییراتی ایجاد کنید. یک رویکرد معقول این است که همه مشکلات شناسایی شده را بر اساس دو پارامتر رتبه بندی کنیم:

  • چقدر راحت میشه این مشکل رو رفع کرد
  • او چقدر ریسک دارد؟

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

کمال گرایی در این مرحله می تواند مضر باشد. طرح را به حالت رضایت بخش برسانید و پیکربندی شبکه را مطابق با آن هماهنگ کنید.

منبع: www.habr.com

اضافه کردن نظر