اپنے نیٹ ورک کے بنیادی ڈھانچے کو کیسے کنٹرول کریں۔ باب دو۔ صفائی اور دستاویزات

یہ مضمون مضامین کی ایک سیریز میں دوسرا ہے "اپنے نیٹ ورک کے بنیادی ڈھانچے کو کیسے کنٹرول کریں۔" سیریز کے تمام مضامین کے مواد اور لنکس مل سکتے ہیں۔ یہاں.

اپنے نیٹ ورک کے بنیادی ڈھانچے کو کیسے کنٹرول کریں۔ باب دو۔ صفائی اور دستاویزات

اس مرحلے پر ہمارا مقصد دستاویزات اور ترتیب کو ترتیب دینا ہے۔
اس عمل کے اختتام پر، آپ کے پاس دستاویزات کا ضروری سیٹ اور ان کے مطابق ایک نیٹ ورک کنفیگر ہونا چاہیے۔

اب ہم سیکیورٹی آڈٹ کے بارے میں بات نہیں کریں گے - یہ تیسرے حصے کا موضوع ہوگا۔

اس مرحلے پر تفویض کردہ کام کو مکمل کرنے کی دشواری، یقیناً، کمپنی سے دوسرے کمپنی میں بہت مختلف ہوتی ہے۔

مثالی صورت حال ہے جب

  • آپ کا نیٹ ورک پروجیکٹ کے مطابق بنایا گیا تھا اور آپ کے پاس دستاویزات کا ایک مکمل سیٹ ہے۔
  • آپ کی کمپنی میں لاگو کیا گیا ہے کنٹرول اور انتظام کے عمل کو تبدیل کریں۔ نیٹ ورک کے لیے
  • اس عمل کے مطابق، آپ کے پاس دستاویزات ہیں (بشمول تمام ضروری خاکے) جو موجودہ حالات کے بارے میں مکمل معلومات فراہم کرتے ہیں۔

اس صورت میں، آپ کا کام بہت آسان ہے. آپ کو دستاویزات کا مطالعہ کرنا چاہئے اور ان تمام تبدیلیوں کا جائزہ لینا چاہئے جو کی گئی ہیں۔

بدترین صورت حال میں، آپ کو پڑے گا

  • بغیر کسی منصوبے کے، بغیر کسی منصوبے کے، بغیر منظوری کے، انجینئرز کے ذریعے بنایا گیا نیٹ ورک جو کافی قابلیت نہیں رکھتے،
  • افراتفری، غیر دستاویزی تبدیلیوں کے ساتھ، بہت سارے "کوڑے دان" اور سب سے بہترین حل کے ساتھ

یہ واضح ہے کہ آپ کی صورتحال کہیں درمیان میں ہے، لیکن بدقسمتی سے، بہتر اور بدتر کے اس پیمانے پر، اس بات کا بہت زیادہ امکان ہے کہ آپ بدترین انجام کے قریب پہنچ جائیں گے۔

اس صورت میں، آپ کو ذہنوں کو پڑھنے کی صلاحیت کی بھی ضرورت ہوگی، کیونکہ آپ کو یہ سمجھنا ہوگا کہ "ڈیزائنرز" کیا کرنا چاہتے ہیں، ان کی منطق کو بحال کرنا، جو ختم نہیں ہوا اسے ختم کرنا اور "کچرا" کو ہٹانا ہوگا۔
اور، یقینا، آپ کو ان کی غلطیوں کو درست کرنے، ڈیزائن کو تبدیل کرنے (اس مرحلے پر جتنا کم سے کم ممکن ہو) اور اسکیموں کو تبدیل یا دوبارہ بنانے کی ضرورت ہوگی۔

یہ مضمون کسی بھی طرح مکمل ہونے کا دعویٰ نہیں کرتا۔ یہاں میں صرف عمومی اصول بیان کروں گا اور کچھ عام مسائل پر توجہ مرکوز کروں گا جن کو حل کرنا ہے۔

دستاویزات کا سیٹ

آئیے ایک مثال سے شروع کرتے ہیں۔

ذیل میں کچھ دستاویزات ہیں جو ڈیزائن کے دوران سسکو سسٹمز میں حسب معمول بنائی جاتی ہیں۔

CR - کسٹمر کی ضروریات، کلائنٹ کی ضروریات (تکنیکی وضاحتیں)۔
یہ کسٹمر کے ساتھ مشترکہ طور پر بنایا گیا ہے اور نیٹ ورک کی ضروریات کا تعین کرتا ہے۔

ایچ ایل ڈی - ہائی لیول ڈیزائن، نیٹ ورک کی ضروریات (CR) پر مبنی اعلیٰ سطح کا ڈیزائن۔ دستاویز میں لیے گئے تعمیراتی فیصلوں کی وضاحت اور جواز پیش کیا گیا ہے (ٹوپولوجی، پروٹوکول، ہارڈویئر کا انتخاب،...)۔ HLD میں ڈیزائن کی تفصیلات شامل نہیں ہیں، جیسے کہ انٹرفیس اور IP پتے استعمال کیے گئے ہیں۔ نیز، مخصوص ہارڈویئر کنفیگریشن پر یہاں بات نہیں کی گئی ہے۔ بلکہ، اس دستاویز کا مقصد گاہک کے تکنیکی انتظام کو کلیدی ڈیزائن کے تصورات کی وضاحت کرنا ہے۔

ایل ایل ڈی - لو لیول ڈیزائن، ہائی لیول ڈیزائن (HLD) پر مبنی لو لیول ڈیزائن۔
اس میں پروجیکٹ کو لاگو کرنے کے لیے ضروری تمام تفصیلات پر مشتمل ہونا چاہیے، جیسے کہ آلات کو جوڑنے اور کنفیگر کرنے کے بارے میں معلومات۔ یہ ڈیزائن کو نافذ کرنے کے لیے ایک مکمل گائیڈ ہے۔ اس دستاویز کو کم اہل افراد کے ذریعہ بھی اس کے نفاذ کے لیے کافی معلومات فراہم کرنی چاہیے۔

کچھ، مثال کے طور پر، IP ایڈریس، AS نمبرز، فزیکل سوئچنگ سکیم (کیبلنگ) کو علیحدہ دستاویزات میں "پوٹ آؤٹ" کیا جا سکتا ہے، جیسے PIN (نیٹ ورک کے نفاذ کا منصوبہ)۔

نیٹ ورک کی تعمیر ان دستاویزات کی تخلیق کے بعد شروع ہوتی ہے اور ان کے مطابق سختی سے ہوتی ہے اور پھر ڈیزائن کی تعمیل کے لیے گاہک (ٹیسٹ) کی طرف سے جانچ پڑتال کی جاتی ہے۔

بلاشبہ، مختلف انٹیگریٹرز، مختلف کلائنٹس، اور مختلف ممالک کی پروجیکٹ دستاویزات کے لیے مختلف تقاضے ہو سکتے ہیں۔ لیکن میں رسمی کارروائیوں سے گریز کرنا چاہوں گا اور اس مسئلے کو اس کی خوبیوں پر غور کرنا چاہوں گا۔ یہ مرحلہ ڈیزائن کے بارے میں نہیں ہے، بلکہ چیزوں کو ترتیب دینے کے بارے میں ہے، اور ہمیں اپنے کاموں کو مکمل کرنے کے لیے کافی دستاویزات (ڈائیگرام، ٹیبل، تفصیل...) کی ضرورت ہے۔

اور میری رائے میں، ایک خاص مطلق کم از کم ہے، جس کے بغیر نیٹ ورک کو مؤثر طریقے سے کنٹرول کرنا ناممکن ہے.

یہ درج ذیل دستاویزات ہیں:

  • فزیکل سوئچنگ (کیبلنگ) کا خاکہ (لاگ)
  • نیٹ ورک ڈایاگرام یا ضروری L2/L3 معلومات کے ساتھ خاکہ

فزیکل سوئچنگ ڈایاگرام

کچھ چھوٹی کمپنیوں میں آلات کی تنصیب اور فزیکل سوئچنگ (کیبلنگ) سے متعلق کام نیٹ ورک انجینئرز کی ذمہ داری ہے۔

اس صورت میں، مسئلہ کو جزوی طور پر مندرجہ ذیل نقطہ نظر سے حل کیا جاتا ہے.

  • انٹرفیس پر ایک وضاحت کا استعمال کریں کہ اس سے کیا منسلک ہے۔
  • انتظامی طور پر تمام غیر منسلک نیٹ ورک آلات کی بندرگاہوں کو بند کر دیں۔

یہ آپ کو موقع فراہم کرے گا، یہاں تک کہ لنک کے ساتھ کسی مسئلے کی صورت میں بھی (جب cdp یا lldp اس انٹرفیس پر کام نہیں کرتا ہے)، فوری طور پر اس بات کا تعین کرنے کے لیے کہ اس پورٹ سے کیا منسلک ہے۔
آپ یہ بھی آسانی سے دیکھ سکتے ہیں کہ کون سی بندرگاہوں پر قبضہ ہے اور کون سی مفت ہے، جو نئے نیٹ ورک آلات، سرورز یا ورک سٹیشنوں کے کنکشن کی منصوبہ بندی کے لیے ضروری ہے۔

لیکن یہ واضح ہے کہ اگر آپ آلات تک رسائی کھو دیتے ہیں، تو آپ اس معلومات تک رسائی بھی کھو دیں گے۔ اس کے علاوہ، اس طرح آپ اس طرح کی اہم معلومات کو ریکارڈ نہیں کر سکیں گے کہ کس قسم کا سامان، بجلی کی کھپت، کتنی بندرگاہیں، یہ کس ریک میں ہے، کون سے پیچ پینلز ہیں اور کہاں (کس ریک/پیچ پینل میں وہ جڑے ہوئے ہیں . لہذا، اضافی دستاویزات (صرف سامان کی وضاحت نہیں) اب بھی بہت مفید ہے۔

مثالی آپشن یہ ہے کہ اس قسم کی معلومات کے ساتھ کام کرنے کے لیے ڈیزائن کردہ ایپلیکیشنز کا استعمال کریں۔ لیکن آپ اپنے آپ کو سادہ جدولوں تک محدود کر سکتے ہیں (مثال کے طور پر، ایکسل میں) یا وہ معلومات ڈسپلے کر سکتے ہیں جسے آپ L1/L2 خاکوں میں ضروری سمجھتے ہیں۔

اہم!

ایک نیٹ ورک انجینئر، یقیناً، SCS کی پیچیدگیوں اور معیارات، ریکوں کی اقسام، بجلی کی بلاتعطل فراہمی کی اقسام، ٹھنڈا اور گرم گلیارے کیا ہے، مناسب گراؤنڈنگ کیسے کرنا ہے، بالکل اچھی طرح جان سکتا ہے... بالکل اسی طرح جیسے وہ اصولی طور پر کر سکتا ہے۔ ابتدائی ذرات یا C++ کی طبیعیات جانیں۔ لیکن پھر بھی یہ سمجھ لینا چاہیے کہ یہ سب اس کے علم کا شعبہ نہیں ہے۔

لہٰذا، تنصیب، کنکشن، سازوسامان کی دیکھ بھال کے ساتھ ساتھ فزیکل سوئچنگ سے متعلق مسائل کو حل کرنے کے لیے مخصوص محکموں یا سرشار لوگوں کا ہونا اچھا عمل ہے۔ عام طور پر ڈیٹا سینٹرز کے لیے یہ ڈیٹا سینٹر انجینئرز ہوتا ہے، اور دفتر کے لیے یہ ہیلپ ڈیسک ہوتا ہے۔

اگر آپ کی کمپنی میں اس طرح کی تقسیم فراہم کی گئی ہے، تو پھر لاگ ان فزیکل سوئچنگ کے مسائل آپ کا کام نہیں ہیں، اور آپ اپنے آپ کو صرف انٹرفیس کی تفصیل اور غیر استعمال شدہ بندرگاہوں کے انتظامی بند کرنے تک محدود کر سکتے ہیں۔

نیٹ ورک ڈایاگرام

خاکے بنانے کے لیے کوئی عالمگیر نقطہ نظر نہیں ہے۔

سب سے اہم بات یہ ہے کہ خاکوں کو یہ سمجھنا چاہیے کہ ٹریفک کس طرح بہے گی، جس کے ذریعے آپ کے نیٹ ورک کے منطقی اور جسمانی عناصر ہیں۔

جسمانی عناصر سے ہمارا مطلب ہے۔

  • فعال سامان
  • انٹرفیس / فعال سامان کی بندرگاہیں

منطق کے تحت -

  • منطقی آلات (N7K VDC، Palo Alto VSYS، ...)
  • وی آر ایف
  • ولانس
  • ذیلی انٹرفیس
  • سرنگیں
  • زون
  • ...

اس کے علاوہ، اگر آپ کا نیٹ ورک مکمل طور پر ابتدائی نہیں ہے، تو یہ مختلف حصوں پر مشتمل ہوگا۔
مثال کے طور پر

  • ڈیٹا سینٹر
  • انٹرنیٹ
  • وان
  • دور دراز تک رسائی
  • آفس LAN
  • DMZ
  • ...

دانشمندی کی بات ہے کہ کئی ایسے خاکے ہوں جو دونوں بڑی تصویر (ان تمام حصوں کے درمیان ٹریفک کیسے چلتے ہیں) اور ہر ایک طبقے کی تفصیلی وضاحت دیتے ہیں۔

چونکہ جدید نیٹ ورکس میں بہت سی منطقی تہیں ہوسکتی ہیں، اس لیے مختلف تہوں کے لیے مختلف سرکٹس بنانا شاید ایک اچھا (لیکن ضروری نہیں) طریقہ ہے، مثال کے طور پر، اوورلے اپروچ کی صورت میں یہ مندرجہ ذیل سرکٹس ہوسکتے ہیں:

  • اتبشایی
  • L1/L2 انڈرلے
  • L3 انڈرلے

بلاشبہ، سب سے اہم خاکہ، جس کے بغیر آپ کے ڈیزائن کے خیال کو سمجھنا ناممکن ہے، روٹنگ ڈایاگرام ہے۔

روٹنگ اسکیم

کم از کم، اس خاکہ کی عکاسی ہونی چاہیے۔

  • کون سے روٹنگ پروٹوکول اور کہاں استعمال ہوتے ہیں۔
  • روٹنگ پروٹوکول کی ترتیبات کے بارے میں بنیادی معلومات (علاقہ/AS نمبر/روٹر آئی ڈی/…)
  • کن آلات پر دوبارہ تقسیم ہوتی ہے؟
  • جہاں فلٹرنگ اور روٹ ایگریگیشن ہوتی ہے۔
  • پہلے سے طے شدہ راستے کی معلومات

نیز، L2 سکیم (OSI) اکثر مفید ہوتی ہے۔

L2 سکیم (OSI)

یہ خاکہ درج ذیل معلومات دکھا سکتا ہے:

  • کیا VLANs
  • کون سی بندرگاہیں ٹرنک پورٹس ہیں۔
  • کن بندرگاہوں کو ایتھر چینل (پورٹ چینل)، ورچوئل پورٹ چینل میں جمع کیا جاتا ہے۔
  • کون سے STP پروٹوکول استعمال کیے جاتے ہیں اور کن آلات پر
  • بنیادی STP ترتیبات: روٹ/روٹ بیک اپ، STP لاگت، بندرگاہ کی ترجیح
  • اضافی STP ترتیبات: BPDU گارڈ/فلٹر، روٹ گارڈ…

عام ڈیزائن کی غلطیاں

نیٹ ورک کی تعمیر کے لیے غلط طریقہ کار کی ایک مثال۔

آئیے ایک سادہ آفس LAN بنانے کی ایک سادہ سی مثال لیتے ہیں۔

طالب علموں کو ٹیلی کام سکھانے کا تجربہ رکھنے کے بعد، میں کہہ سکتا ہوں کہ دوسرے سمسٹر کے وسط تک عملی طور پر کسی بھی طالب علم کے پاس ایک سادہ آفس LAN ترتیب دینے کے لیے ضروری علم (جس کورس کے حصے کے طور پر میں نے پڑھایا تھا) رکھتا ہے۔

سوئچز کو ایک دوسرے سے جوڑنے، VLANs، SVI انٹرفیس (L3 سوئچز کی صورت میں) اور سٹیٹک روٹنگ کو ترتیب دینے میں کیا مشکل ہے؟

سب کام ہو جائے گا۔

لیکن ایک ہی وقت میں، سے متعلق سوالات

  • سیکورٹی
  • بکنگ
  • نیٹ ورک اسکیلنگ
  • پیداوری
  • تھرو پٹ
  • اعتبار
  • ...

وقتاً فوقتاً میں یہ بیان سنتا ہوں کہ آفس LAN بہت آسان چیز ہے اور میں یہ عام طور پر انجینئرز (اور مینیجرز) سے سنتا ہوں جو نیٹ ورک کے علاوہ سب کچھ کرتے ہیں، اور وہ یہ بات اتنے اعتماد سے کہتے ہیں کہ اگر LAN ہو جائے تو حیران نہ ہوں۔ ناکافی مشق اور علم والے لوگوں کے ذریعہ بنایا گیا ہے اور تقریباً انہی غلطیوں کے ساتھ کیا جائے گا جو میں ذیل میں بیان کروں گا۔

عام L1 (OSI) ڈیزائن کی غلطیاں

  • اگر، اس کے باوجود، آپ SCS کے لیے بھی ذمہ دار ہیں، تو آپ کو ملنے والی سب سے ناخوشگوار میراث میں سے ایک لاپرواہی اور غیر سوچی سمجھی تبدیلی ہے۔

میں استعمال شدہ آلات کے وسائل سے متعلق قسم کی L1 غلطیوں کے طور پر بھی درجہ بندی کروں گا، مثال کے طور پر،

  • ناکافی بینڈوتھ
  • آلات پر ناکافی TCAM (یا اس کا غیر موثر استعمال)
  • ناکافی کارکردگی (اکثر فائر وال سے متعلق)

عام L2 (OSI) ڈیزائن کی غلطیاں

اکثر، جب STP کے کام کرنے کے بارے میں اچھی طرح سے سمجھ نہیں آتی ہے اور یہ اس کے ساتھ کیا ممکنہ مسائل لاتا ہے، سوئچز بغیر کسی اضافی STP ٹیوننگ کے، پہلے سے طے شدہ ترتیبات کے ساتھ، افراتفری سے جڑے ہوتے ہیں۔

نتیجے کے طور پر، ہمارے پاس اکثر درج ذیل ہوتے ہیں۔

  • بڑے STP نیٹ ورک کا قطر، جو نشریاتی طوفانوں کا باعث بن سکتا ہے۔
  • STP روٹ کا تعین تصادفی طور پر کیا جائے گا (میک ایڈریس کی بنیاد پر) اور ٹریفک کا راستہ سب سے بہتر ہوگا۔
  • میزبانوں سے منسلک بندرگاہوں کو کنارے (پورٹ فاسٹ) کے طور پر ترتیب نہیں دیا جائے گا، جو اختتامی اسٹیشنوں کو آن/آف کرتے وقت ایس ٹی پی کی دوبارہ گنتی کا باعث بنے گا۔
  • نیٹ ورک کو L1/L2 کی سطح پر تقسیم نہیں کیا جائے گا، جس کے نتیجے میں کسی بھی سوئچ (مثال کے طور پر پاور اوورلوڈ) کے مسائل STP ٹوپولوجی کی دوبارہ گنتی اور تمام سوئچز پر تمام VLANs میں ٹریفک کو روکنے کا باعث بنیں گے (بشمول تسلسل سروس کے حصے کے نقطہ نظر سے ایک اہم)

L3 (OSI) ڈیزائن میں غلطیوں کی مثالیں۔

نوسکھئیے نیٹ ورکرز کی چند عام غلطیاں:

  • جامد روٹنگ کا بار بار استعمال (یا صرف استعمال)
  • دیئے گئے ڈیزائن کے لیے سب سے زیادہ روٹنگ پروٹوکول کا استعمال
  • سب سے زیادہ منطقی نیٹ ورک سیگمنٹیشن
  • ایڈریس اسپیس کا سب سے زیادہ استعمال، جو راستے کو جمع کرنے کی اجازت نہیں دیتا ہے۔
  • کوئی بیک اپ روٹس نہیں۔
  • ڈیفالٹ گیٹ وے کے لیے کوئی ریزرویشن نہیں۔
  • راستوں کی تعمیر نو کے وقت غیر متناسب روٹنگ (NAT/PAT، سٹیٹ فل فائر والز کی صورت میں اہم ہو سکتی ہے)
  • MTU کے ساتھ مسائل
  • جب راستوں کو دوبارہ بنایا جاتا ہے، ٹریفک دوسرے سیکیورٹی زونز یا حتیٰ کہ دیگر فائر والز سے گزرتی ہے، جس کی وجہ سے یہ ٹریفک چھوڑ دی جاتی ہے۔
  • ناقص ٹوپولوجی اسکیل ایبلٹی

ڈیزائن کے معیار کا اندازہ لگانے کے لیے معیار

جب ہم آپٹیملٹی/غیر احسنیت کے بارے میں بات کرتے ہیں، تو ہمیں اس نقطہ نظر سے سمجھنا چاہیے کہ ہم اس کا اندازہ کس معیار سے کر سکتے ہیں۔ یہاں، میرے نقطہ نظر سے، سب سے اہم (لیکن تمام نہیں) معیار (اور روٹنگ پروٹوکول کے سلسلے میں وضاحت):

  • توسیع پذیری
    مثال کے طور پر، آپ ایک اور ڈیٹا سینٹر شامل کرنے کا فیصلہ کرتے ہیں۔ آپ اسے کتنا آسان کر سکتے ہیں؟
  • استعمال میں آسانی (قابل انتظام)
    آپریشنل تبدیلیاں کتنی آسان اور محفوظ ہیں، جیسے کہ نئے گرڈ کا اعلان کرنا یا روٹس کو فلٹر کرنا؟
  • دستیابی
    آپ کا سسٹم کتنے فیصد وقت کی خدمت کی مطلوبہ سطح فراہم کرتا ہے؟
  • سیکورٹی
    منتقل شدہ ڈیٹا کتنا محفوظ ہے؟
  • قیمت

تبدیلیاں

اس مرحلے پر بنیادی اصول کو "کوئی نقصان نہ پہنچائیں" کے فارمولے سے ظاہر کیا جا سکتا ہے۔
لہذا، یہاں تک کہ اگر آپ ڈیزائن اور منتخب کردہ نفاذ (کنفیگریشن) سے پوری طرح متفق نہیں ہیں، تب بھی تبدیلیاں کرنا ہمیشہ مناسب نہیں ہے۔ تمام شناخت شدہ مسائل کو دو پیرامیٹرز کے مطابق درجہ بندی کرنا ایک معقول طریقہ ہے:

  • اس مسئلہ کو کتنی آسانی سے حل کیا جا سکتا ہے۔
  • وہ کتنا خطرہ برداشت کرتی ہے؟

سب سے پہلے، اس کو ختم کرنا ضروری ہے جو فی الحال قابل قبول سطح سے نیچے فراہم کردہ سروس کی سطح کو کم کرتی ہے، مثال کے طور پر، پیکٹ کے نقصان کا باعث بننے والے مسائل۔ پھر اس بات کو درست کریں کہ خطرے کی شدت کے کم ہوتے ہوئے ترتیب میں کیا ٹھیک کرنا سب سے آسان اور محفوظ ہے (زیادہ خطرہ والے ڈیزائن یا کنفیگریشن کے مسائل سے لے کر کم خطرہ والے تک)۔

اس مرحلے پر پرفیکشنزم نقصان دہ ہو سکتا ہے۔ ڈیزائن کو تسلی بخش حالت میں لائیں اور اس کے مطابق نیٹ ورک کنفیگریشن کو سنکرونائز کریں۔

ماخذ: www.habr.com

نیا تبصرہ شامل کریں