یہ مضمون مضامین کی ایک سیریز میں تیسرا مضمون ہے "اپنے نیٹ ورک انفراسٹرکچر کو کیسے کنٹرول کیا جائے"۔ سیریز کے تمام مضامین کے مواد اور لنکس مل سکتے ہیں۔ یہاں.

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

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

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

اب ہمارا کام نیٹ ورک کی سطح پر سیکیورٹی سے وابستہ خطرات کی نشاندہی کرنا اور انہیں مناسب سطح تک کم کرنا ہے۔

نیٹ ورک سیکیورٹی آڈٹ

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

میں کئی ممکنہ نیٹ ورک سیکیورٹی آڈٹس کو اجاگر کروں گا:

• سامان کی ترتیب کا آڈٹ (سختی)
• سیکورٹی ڈیزائن آڈٹ
• رسائی آڈٹ
• عمل آڈٹ

آلات کی ترتیب کا آڈٹ (سختی)

ایسا لگتا ہے کہ زیادہ تر معاملات میں یہ آپ کے نیٹ ورک کی آڈیٹنگ اور سیکیورٹی کو بہتر بنانے کا بہترین نقطہ آغاز ہے۔ IMHO، یہ Pareto کے قانون کا ایک اچھا مظاہرہ ہے (20% کوشش 80% نتیجہ پیدا کرتی ہے، اور بقیہ 80% کوشش صرف 20% نتیجہ دیتی ہے)۔

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

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

کچھ سسکو آپریٹنگ سسٹم کے لیے کئی مثالیں۔

سسکو آئی او ایس کنفیگریشن سخت کرنا
سسکو IOS-XR کنفیگریشن سخت کرنا
سسکو NX-OS کنفیگریشن سخت کرنا
سسکو بیس لائن سیکیورٹی چیک لسٹ

ان دستاویزات کی بنیاد پر، ہر قسم کے آلات کے لیے ترتیب کی ضروریات کی ایک فہرست بنائی جا سکتی ہے۔ مثال کے طور پر، Cisco N7K VDC کے لیے یہ تقاضے اس طرح نظر آ سکتے ہیں۔ تو.

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

سیکیورٹی ڈیزائن آڈٹ

عام طور پر، ایک انٹرپرائز نیٹ ورک کسی نہ کسی شکل میں درج ذیل حصوں پر مشتمل ہوتا ہے:

• DC (عوامی خدمات DMZ اور انٹرانیٹ ڈیٹا سینٹر)
• انٹرنیٹ تک رسائی
• ریموٹ رسائی VPN
• وان کنارے
• برانچ
• کیمپس (آفس)
• کور

سے لیے گئے عنوانات سسکو سیف ماڈل، لیکن یہ ضروری نہیں ہے کہ ان ناموں اور اس ماڈل کے ساتھ قطعی طور پر منسلک کیا جائے۔ پھر بھی، میں جوہر کے بارے میں بات کرنا چاہتا ہوں اور رسمی باتوں میں الجھنا نہیں چاہتا ہوں۔

ان میں سے ہر ایک طبقے کے لیے، حفاظتی تقاضے، خطرات اور، اس کے مطابق، حل مختلف ہوں گے۔

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

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

ڈیٹا سینٹر

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

کیا فائر وال ضروری ہے یا نہیں؟

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

مثال 1. تاخیر

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

مثال 2. کارکردگی

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

مثال 3. اعتماد

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

مندرجہ بالا مثالوں کی صورت میں، آپ کو غالباً (معمول کے مطابق) سمجھوتہ کرنا پڑے گا۔ درج ذیل حل کی طرف دیکھیں:

• اگر آپ ڈیٹا سینٹر کے اندر فائر وال استعمال نہ کرنے کا فیصلہ کرتے ہیں، تو آپ کو اس بارے میں سوچنے کی ضرورت ہے کہ جہاں تک ممکن ہو اس کے ارد گرد رسائی کو کیسے محدود کیا جائے۔ مثال کے طور پر، آپ انٹرنیٹ سے صرف ضروری بندرگاہیں کھول سکتے ہیں (کلائنٹ ٹریفک کے لیے) اور ڈیٹا سینٹر تک انتظامی رسائی صرف جمپ ہوسٹس سے۔ جمپ ہوسٹس پر، تمام ضروری جانچ پڑتال کریں (تصدیق/ اجازت، اینٹی وائرس، لاگنگ، ...)
• آپ ڈیٹا سینٹر نیٹ ورک کی منطقی تقسیم کو حصوں میں استعمال کر سکتے ہیں، جیسا کہ PSEFABRIC میں بیان کردہ اسکیم کی طرح ہے۔ مثال p002. اس صورت میں، روٹنگ کو اس طرح ترتیب دیا جانا چاہیے کہ تاخیر سے حساس یا زیادہ شدت والی ٹریفک ایک سیگمنٹ (p002، VRF کے معاملے میں) "اندر" جائے اور فائر وال سے نہ گزرے۔ مختلف طبقات کے درمیان ٹریفک فائر وال سے گزرتی رہے گی۔ آپ فائر وال کے ذریعے ٹریفک کو ری ڈائریکٹ کرنے سے بچنے کے لیے VRFs کے درمیان رساؤ کا راستہ بھی استعمال کر سکتے ہیں۔
• آپ فائر وال کو شفاف موڈ میں بھی استعمال کر سکتے ہیں اور صرف ان VLANs کے لیے جہاں یہ عوامل (دیرتا/کارکردگی) اہم نہیں ہیں۔ لیکن آپ کو ہر وینڈر کے لیے اس موڈ کے استعمال سے منسلک پابندیوں کا بغور مطالعہ کرنے کی ضرورت ہے۔
• آپ سروس چین آرکیٹیکچر استعمال کرنے پر غور کر سکتے ہیں۔ یہ صرف ضروری ٹریفک کو فائر وال سے گزرنے کی اجازت دے گا۔ نظریہ میں اچھا لگتا ہے، لیکن میں نے اس حل کو پیداوار میں کبھی نہیں دیکھا۔ ہم نے تقریباً 5 سال قبل Cisco ACI/Juniper SRX/F3 LTM کے لیے سروس چین کا تجربہ کیا تھا، لیکن اس وقت یہ حل ہمیں "خراب" لگتا تھا۔

تحفظ کی سطح

اب آپ کو اس سوال کا جواب دینا ہوگا کہ آپ ٹریفک کو فلٹر کرنے کے لیے کون سے ٹولز استعمال کرنا چاہتے ہیں۔ یہاں کچھ خصوصیات ہیں جو عام طور پر NGFW میں موجود ہیں (مثال کے طور پر، یہاں):

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

اور نہ ہی سب کچھ واضح ہے۔ ایسا لگتا ہے کہ تحفظ کی سطح جتنی زیادہ ہوگی، اتنا ہی بہتر ہے۔ لیکن آپ کو اس پر بھی غور کرنے کی ضرورت ہے۔

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

ہمیشہ کی طرح، آپ کو اپنے نیٹ ورک کے لیے بہترین حل تلاش کرنے کی ضرورت ہے۔

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

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

سیگمنٹیشن

ہم ڈیٹا سینٹر نیٹ ورک کی منطقی تقسیم کے بارے میں بات کر رہے ہیں۔ مثال کے طور پر، VLANs اور subnets میں تقسیم کرنا بھی منطقی سیگمنٹیشن ہے، لیکن ہم اس کے واضح ہونے کی وجہ سے اس پر غور نہیں کریں گے۔ FW سیکورٹی زونز، VRFs (اور مختلف دکانداروں کے حوالے سے ان کے analogues)، منطقی آلات (PA VSYS، Cisco N7K VDC، Cisco ACI Tenant، ...) جیسے اداروں کو مدنظر رکھتے ہوئے دلچسپ تقسیم۔

اس طرح کی منطقی تقسیم اور فی الحال ڈیمانڈ ڈیٹا سینٹر ڈیزائن کی ایک مثال میں دی گئی ہے۔ PSEFABRIC پروجیکٹ کا p002.

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

اگر آپ کے نیٹ ورک میں واضح منطقی تقسیم نہیں ہے اور مختلف ڈیٹا کے بہاؤ کے لیے حفاظتی پالیسیوں کو لاگو کرنے کے قواعد کو باقاعدہ نہیں بنایا گیا ہے، تو اس کا مطلب ہے کہ جب آپ یہ یا وہ رسائی کھولتے ہیں، تو آپ کو اس مسئلے کو حل کرنے پر مجبور کیا جاتا ہے، اور بہت زیادہ امکان کے ساتھ آپ ہر بار مختلف طریقے سے حل کریں گے.

اکثر سیگمنٹیشن صرف ایف ڈبلیو سیکیورٹی زونز پر مبنی ہوتی ہے۔ پھر آپ کو درج ذیل سوالات کے جوابات دینے کی ضرورت ہے:

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

TCAM

ایک عام مسئلہ روٹنگ اور رسائی دونوں کے لیے ناکافی TCAM (Ternary Content Addressable Memory) ہے۔ IMHO، سازوسامان کا انتخاب کرتے وقت یہ سب سے اہم مسائل میں سے ایک ہے، لہذا آپ کو اس مسئلے کا مناسب حد تک نگہداشت کے ساتھ علاج کرنے کی ضرورت ہے۔

مثال 1. فارورڈنگ ٹیبل TCAM۔

آئیے غور کریں پالو آلٹو 7k فائر وال
ہم دیکھتے ہیں کہ IPv4 فارورڈنگ ٹیبل سائز* = 32K
مزید یہ کہ، راستوں کی یہ تعداد تمام VSYSs کے لیے عام ہے۔

آئیے فرض کریں کہ آپ کے ڈیزائن کے مطابق آپ 4 VSYS استعمال کرنے کا فیصلہ کرتے ہیں۔
ان میں سے ہر ایک VSYSs BGP کے ذریعے کلاؤڈ کے دو MPLS PE سے جڑا ہوا ہے جسے آپ BB کے طور پر استعمال کرتے ہیں۔ اس طرح، 4 VSYS تمام مخصوص راستوں کا ایک دوسرے کے ساتھ تبادلہ کرتے ہیں اور ایک فارورڈنگ ٹیبل رکھتے ہیں جس میں روٹس کے تقریباً ایک ہی سیٹ ہوتے ہیں (لیکن مختلف NHs)۔ کیونکہ ہر VSYS کے 2 BGP سیشن ہوتے ہیں (اسی سیٹنگز کے ساتھ)، پھر MPLS کے ذریعے موصول ہونے والے ہر راستے میں 2 NH ہوتے ہیں اور اس کے مطابق، فارورڈنگ ٹیبل میں 2 FIB اندراجات ہوتے ہیں۔ اگر ہم فرض کر لیں کہ ڈیٹا سینٹر میں یہ واحد فائر وال ہے اور اسے تمام راستوں کے بارے میں معلوم ہونا چاہیے، تو اس کا مطلب یہ ہوگا کہ ہمارے ڈیٹا سینٹر میں روٹس کی کل تعداد 32K/(4*2) = 4K سے زیادہ نہیں ہو سکتی۔

اب، اگر ہم فرض کرتے ہیں کہ ہمارے پاس 2 ڈیٹا سینٹرز ہیں (ایک ہی ڈیزائن کے ساتھ)، اور ہم ڈیٹا سینٹرز کے درمیان VLANs کو استعمال کرنا چاہتے ہیں (مثال کے طور پر، vMotion کے لیے)، تو روٹنگ کے مسئلے کو حل کرنے کے لیے، ہمیں میزبان روٹس کا استعمال کرنا چاہیے۔ . لیکن اس کا مطلب ہے کہ 2 ڈیٹا سینٹرز کے لیے ہمارے پاس 4096 سے زیادہ ممکنہ میزبان نہیں ہوں گے اور یقیناً یہ کافی نہیں ہوگا۔

مثال 2. ACL TCAM۔

اگر آپ L3 سوئچز پر ٹریفک کو فلٹر کرنے کا ارادہ رکھتے ہیں (یا دیگر حل جو L3 سوئچ استعمال کرتے ہیں، مثال کے طور پر، Cisco ACI)، تو آپ کو سامان کا انتخاب کرتے وقت TCAM ACL پر توجہ دینی چاہیے۔

فرض کریں کہ آپ Cisco Catalyst 4500 کے SVI انٹرفیس پر رسائی کو کنٹرول کرنا چاہتے ہیں۔ پھر، جیسا کہ یہاں سے دیکھا جا سکتا ہے۔ اس مضمون کا، انٹرفیس پر جانے والے (نیز آنے والے) ٹریفک کو کنٹرول کرنے کے لیے، آپ صرف 4096 TCAM لائنیں استعمال کر سکتے ہیں۔ جو TCAM3 استعمال کرتے وقت آپ کو تقریباً 4000 ہزار ACEs (ACL لائنز) دے گا۔

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

اچھی فراہمی

سوال یہ ہے کہ: کیا مجھے فائر والز کے لیے HA استعمال کرنا چاہیے یا "متوازی طور پر" دو آزاد خانوں کو انسٹال کرنا چاہیے اور، اگر ان میں سے ایک ناکام ہو جاتا ہے، تو ٹریفک کو دوسرے کے ذریعے روٹ کرنا چاہیے؟

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

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

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

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

انتظامی صلاحیت

اصولی طور پر، HA کنٹرول ایبلٹی کے بارے میں بھی ہے۔ 2 خانوں کو الگ الگ کنفیگر کرنے اور کنفیگریشنز کو مطابقت پذیر رکھنے کے مسئلے سے نمٹنے کے بجائے، آپ ان کا اتنا انتظام کرتے ہیں جیسے آپ کے پاس ایک ڈیوائس ہو۔

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

• بیک اپ کنفیگریشنز
• تازہ ترین
• اپ گریڈ
• نگرانی
• لاگنگ

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

لہذا، مثال کے طور پر، اگر آپ پالو آلٹو فائر وال استعمال کر رہے ہیں، تو دیکھیں ایسا حل ہے.

جاری رکھنا

ماخذ: www.habr.com