এই নিবন্ধটি "কিভাবে আপনার নেটওয়ার্ক পরিকাঠামো নিয়ন্ত্রণ করতে হবে" নিবন্ধগুলির একটি সিরিজের তৃতীয়। সিরিজের সমস্ত নিবন্ধের বিষয়বস্তু এবং লিঙ্কগুলি পাওয়া যাবে এখানে.

নিরাপত্তা ঝুঁকি পুরোপুরি দূর করার কথা বলে লাভ নেই। নীতিগতভাবে, আমরা তাদের শূন্যে কমাতে পারি না। আমাদের এটাও বুঝতে হবে যে আমরা নেটওয়ার্ককে আরও বেশি নিরাপদ করার চেষ্টা করছি, আমাদের সমাধানগুলি আরও বেশি ব্যয়বহুল হয়ে উঠছে। আপনাকে খরচ, জটিলতা এবং নিরাপত্তার মধ্যে একটি ট্রেড-অফ খুঁজে বের করতে হবে যা আপনার নেটওয়ার্কের জন্য বোধগম্য।

অবশ্যই, নিরাপত্তা নকশা সামগ্রিক স্থাপত্যে জৈবভাবে একত্রিত করা হয়েছে এবং ব্যবহৃত নিরাপত্তা সমাধানগুলি নেটওয়ার্ক পরিকাঠামোর পরিমাপযোগ্যতা, নির্ভরযোগ্যতা, পরিচালনাযোগ্যতা, ...কে প্রভাবিত করে, যাও বিবেচনায় নেওয়া উচিত।

কিন্তু আমি আপনাকে মনে করিয়ে দিই যে এখন আমরা নেটওয়ার্ক তৈরি করার কথা বলছি না। আমাদের মতে প্রাথমিক শর্তাবলি আমরা ইতিমধ্যে নকশাটি বেছে নিয়েছি, সরঞ্জামগুলি নির্বাচন করেছি এবং অবকাঠামো তৈরি করেছি এবং এই পর্যায়ে, যদি সম্ভব হয়, আমাদের "লাইভ" করা উচিত এবং পূর্বে নির্বাচিত পদ্ধতির পরিপ্রেক্ষিতে সমাধান খুঁজে বের করা উচিত।

আমাদের কাজ এখন নেটওয়ার্ক স্তরে নিরাপত্তার সাথে যুক্ত ঝুঁকিগুলি চিহ্নিত করা এবং সেগুলিকে একটি যুক্তিসঙ্গত স্তরে হ্রাস করা৷

নেটওয়ার্ক নিরাপত্তা নিরীক্ষা

যদি আপনার সংস্থাটি ISO 27k প্রক্রিয়াগুলি প্রয়োগ করে থাকে, তাহলে নিরাপত্তা অডিট এবং নেটওয়ার্ক পরিবর্তনগুলি এই পদ্ধতির মধ্যে সামগ্রিক প্রক্রিয়াগুলির মধ্যে নির্বিঘ্নে ফিট করা উচিত। কিন্তু এই মানগুলি এখনও নির্দিষ্ট সমাধান সম্পর্কে নয়, কনফিগারেশন সম্পর্কে নয়, ডিজাইন সম্পর্কে নয়... আপনার নেটওয়ার্ক কেমন হওয়া উচিত তা বিশদভাবে নির্দেশ করে এমন কোনও স্পষ্ট পরামর্শ নেই, কোনও মানদণ্ড নেই, এটি এই কাজের জটিলতা এবং সৌন্দর্য।

আমি কয়েকটি সম্ভাব্য নেটওয়ার্ক নিরাপত্তা অডিট হাইলাইট করব:

• সরঞ্জাম কনফিগারেশন অডিট (শক্তকরণ)
• নিরাপত্তা নকশা অডিট
• অ্যাক্সেস অডিট
• প্রক্রিয়া নিরীক্ষা

সরঞ্জাম কনফিগারেশন অডিট (শক্তকরণ)

মনে হচ্ছে বেশিরভাগ ক্ষেত্রেই এটি আপনার নেটওয়ার্কের নিরাপত্তার নিরীক্ষা এবং উন্নতির জন্য সেরা সূচনা পয়েন্ট। IMHO, এটি পেরেটোর আইনের একটি ভাল প্রদর্শন (20% প্রচেষ্টা ফলাফলের 80% দেয়, এবং বাকি 80% প্রচেষ্টা ফলাফলের মাত্র 20% দেয়)।

নীচের লাইন হল যে আমরা সাধারণত সরঞ্জাম কনফিগার করার সময় নিরাপত্তার জন্য "সর্বোত্তম অনুশীলন" সম্পর্কিত বিক্রেতাদের কাছ থেকে সুপারিশ করি। একে বলা হয় "শক্তকরণ"।

এছাড়াও আপনি প্রায়শই এই সুপারিশগুলির উপর ভিত্তি করে একটি প্রশ্নাবলী (বা নিজেই একটি তৈরি করুন) খুঁজে পেতে পারেন, যা আপনাকে আপনার সরঞ্জামের কনফিগারেশন এই "সর্বোত্তম অনুশীলনগুলি" এর সাথে কতটা ভালভাবে মেনে চলে তা নির্ধারণ করতে সহায়তা করবে এবং ফলাফল অনুসারে, আপনার নেটওয়ার্কে পরিবর্তন আনতে পারে। . এটি আপনাকে কার্যত কোন খরচ ছাড়াই বেশ সহজে নিরাপত্তা ঝুঁকি উল্লেখযোগ্যভাবে কমাতে দেবে।

কিছু সিসকো অপারেটিং সিস্টেমের জন্য বেশ কয়েকটি উদাহরণ।

সিসকো আইওএস কনফিগারেশন হার্ডেনিং
সিসকো আইওএস-এক্সআর কনফিগারেশন হার্ডনিং
সিসকো এনএক্স-ওএস কনফিগারেশন হার্ডেনিং
সিসকো বেসলাইন নিরাপত্তা চেক তালিকা

এই নথিগুলির উপর ভিত্তি করে, প্রতিটি ধরণের সরঞ্জামের জন্য কনফিগারেশন প্রয়োজনীয়তার একটি তালিকা তৈরি করা যেতে পারে। উদাহরণস্বরূপ, একটি Cisco N7K VDC-এর জন্য এই প্রয়োজনীয়তাগুলি দেখতে কেমন হতে পারে৷ সুতরাং.

এইভাবে, আপনার নেটওয়ার্ক অবকাঠামোতে বিভিন্ন ধরণের সক্রিয় সরঞ্জামের জন্য কনফিগারেশন ফাইল তৈরি করা যেতে পারে। এর পরে, ম্যানুয়ালি বা অটোমেশন ব্যবহার করে, আপনি এই কনফিগারেশন ফাইলগুলি "আপলোড" করতে পারেন। কীভাবে এই প্রক্রিয়াটি স্বয়ংক্রিয় করা যায় তা অর্কেস্ট্রেশন এবং অটোমেশন সম্পর্কিত নিবন্ধের আরেকটি সিরিজে বিশদভাবে আলোচনা করা হবে।

নিরাপত্তা নকশা অডিট

সাধারণত, একটি এন্টারপ্রাইজ নেটওয়ার্ক এক বা অন্য ফর্মে নিম্নলিখিত বিভাগগুলি ধারণ করে:

• ডিসি (পাবলিক সার্ভিস ডিএমজেড এবং ইন্ট্রানেট ডেটা সেন্টার)
• ইন্টারনেট সুবিধা
• দূরবর্তী অ্যাক্সেস VPN
• WAN প্রান্ত
• শাখা
• ক্যাম্পাস (অফিস)
• মূল

থেকে নেওয়া শিরোনাম সিসকো সেফ মডেল, তবে অবশ্যই, এই নামগুলির সাথে এবং এই মডেলের সাথে অবিকল সংযুক্ত করা আবশ্যক নয়। তবুও, আমি সারমর্ম সম্পর্কে কথা বলতে চাই এবং আনুষ্ঠানিকতায় আবদ্ধ না হয়ে চাই।

এই প্রতিটি বিভাগের জন্য, নিরাপত্তা প্রয়োজনীয়তা, ঝুঁকি এবং, সেই অনুযায়ী, সমাধানগুলি ভিন্ন হবে।

নিরাপত্তা ডিজাইনের দৃষ্টিকোণ থেকে আপনি যে সমস্যার সম্মুখীন হতে পারেন সেগুলির জন্য আলাদাভাবে তাদের প্রত্যেকটিকে দেখুন। অবশ্যই, আমি আবারও বলছি যে কোনওভাবেই এই নিবন্ধটি সম্পূর্ণ হওয়ার ভান করে না, যা এই সত্যিকারের গভীর এবং বহুমুখী বিষয়ে অর্জন করা সহজ নয় (যদি অসম্ভব না হয়), তবে এটি আমার ব্যক্তিগত অভিজ্ঞতাকে প্রতিফলিত করে।

কোন নিখুঁত সমাধান নেই (অন্তত এখনও না)। এটা সবসময় একটি আপস. তবে এটি গুরুত্বপূর্ণ যে একটি বা অন্য পদ্ধতি ব্যবহার করার সিদ্ধান্ত সচেতনভাবে নেওয়া হয়, এর সুবিধা এবং অসুবিধা উভয়ই বোঝার সাথে।

তথ্য কেন্দ্র

নিরাপত্তার দৃষ্টিকোণ থেকে সবচেয়ে গুরুত্বপূর্ণ বিভাগ।
এবং, যথারীতি, এখানেও কোন সার্বজনীন সমাধান নেই। এটি সমস্ত নেটওয়ার্ক প্রয়োজনীয়তার উপর ব্যাপকভাবে নির্ভর করে।

একটি ফায়ারওয়াল প্রয়োজনীয় নাকি না?

মনে হবে যে উত্তরটি সুস্পষ্ট, তবে সবকিছু যতটা স্পষ্ট মনে হতে পারে ততটা স্পষ্ট নয়। এবং আপনার পছন্দ না শুধুমাত্র প্রভাবিত হতে পারে মূল্য.

উদাহরণ 1 বিলম্ব।

যদি কিছু নেটওয়ার্ক সেগমেন্টের মধ্যে কম লেটেন্সি একটি অপরিহার্য প্রয়োজন হয়, যা, উদাহরণস্বরূপ, একটি বিনিময়ের ক্ষেত্রে সত্য, তাহলে আমরা এই বিভাগগুলির মধ্যে ফায়ারওয়াল ব্যবহার করতে সক্ষম হব না। ফায়ারওয়ালে লেটেন্সির উপর অধ্যয়ন খুঁজে পাওয়া কঠিন, কিন্তু কয়েকটি সুইচ মডেল 1 mksec এর কম বা কম লেটেন্সি প্রদান করতে পারে, তাই আমি মনে করি যদি মাইক্রোসেকেন্ড আপনার কাছে গুরুত্বপূর্ণ হয়, তাহলে ফায়ারওয়ালগুলি আপনার জন্য নয়।

উদাহরণ 2 কর্মক্ষমতা.

টপ L3 সুইচের থ্রুপুট সাধারণত সবচেয়ে শক্তিশালী ফায়ারওয়ালের থ্রুপুট থেকে বেশি মাত্রার হয়। অতএব, উচ্চ-তীব্রতার ট্র্যাফিকের ক্ষেত্রে, আপনাকে সম্ভবত এই ট্র্যাফিকটিকে ফায়ারওয়াল বাইপাস করার অনুমতি দিতে হবে।

উদাহরণ 3 নির্ভরযোগ্যতা।

ফায়ারওয়াল, বিশেষ করে আধুনিক NGFW (Next-generation FW) হল জটিল ডিভাইস। এগুলি L3/L2 সুইচের চেয়ে অনেক বেশি জটিল। তারা প্রচুর পরিমাণে পরিষেবা এবং কনফিগারেশন বিকল্প সরবরাহ করে, তাই এটি আশ্চর্যজনক নয় যে তাদের নির্ভরযোগ্যতা অনেক কম। যদি পরিষেবার ধারাবাহিকতা নেটওয়ার্কের জন্য গুরুত্বপূর্ণ হয়, তাহলে আপনাকে বেছে নিতে হতে পারে কোনটি আরও ভাল প্রাপ্যতার দিকে নিয়ে যাবে - ফায়ারওয়াল সহ নিরাপত্তা বা নিয়মিত ACL ব্যবহার করে সুইচ (বা বিভিন্ন ধরণের কাপড়) এর উপর নির্মিত নেটওয়ার্কের সরলতা।

উপরের উদাহরণগুলির ক্ষেত্রে, আপনাকে সম্ভবত (স্বাভাবিকভাবে) একটি আপস খুঁজে বের করতে হবে। নিম্নলিখিত সমাধানগুলির দিকে তাকান:

• আপনি যদি ডেটা সেন্টারের অভ্যন্তরে ফায়ারওয়াল ব্যবহার না করার সিদ্ধান্ত নেন, তবে আপনাকে যতটা সম্ভব ঘেরের চারপাশে অ্যাক্সেস সীমিত করার বিষয়ে চিন্তা করতে হবে। উদাহরণস্বরূপ, আপনি ইন্টারনেট থেকে শুধুমাত্র প্রয়োজনীয় পোর্ট খুলতে পারেন (ক্লায়েন্ট ট্র্যাফিকের জন্য) এবং ডাটা সেন্টারে প্রশাসনিক অ্যাক্সেস শুধুমাত্র জাম্প হোস্ট থেকে। জাম্প হোস্টগুলিতে, সমস্ত প্রয়োজনীয় পরীক্ষাগুলি সম্পাদন করুন (প্রমাণিকরণ/অনুমোদন, অ্যান্টিভাইরাস, লগিং, ...)
• আপনি ডেটা সেন্টার নেটওয়ার্কের একটি যৌক্তিক বিভাজন সেগমেন্টে ব্যবহার করতে পারেন, PSEFABRIC-এ বর্ণিত স্কিমের অনুরূপ উদাহরণ p002. এই ক্ষেত্রে, রাউটিংকে এমনভাবে কনফিগার করতে হবে যাতে বিলম্ব-সংবেদনশীল বা উচ্চ-তীব্রতার ট্র্যাফিক একটি সেগমেন্টের (p002, VRF-এর ক্ষেত্রে) "এর মধ্যে" যায় এবং ফায়ারওয়ালের মধ্য দিয়ে না যায়। বিভিন্ন বিভাগের মধ্যে ট্রাফিক ফায়ারওয়ালের মাধ্যমে চলতে থাকবে। ফায়ারওয়ালের মাধ্যমে ট্র্যাফিক রিডাইরেক্ট এড়াতে আপনি VRF-এর মধ্যে লিকিং রুট ব্যবহার করতে পারেন
• আপনি স্বচ্ছ মোডে একটি ফায়ারওয়াল ব্যবহার করতে পারেন এবং শুধুমাত্র সেই VLANগুলির জন্য যেখানে এই কারণগুলি (লেটেন্সি/পারফরম্যান্স) উল্লেখযোগ্য নয়৷ তবে আপনাকে প্রতিটি বিক্রেতার জন্য এই মোড ব্যবহারের সাথে সম্পর্কিত বিধিনিষেধগুলি যত্ন সহকারে অধ্যয়ন করতে হবে
• আপনি একটি পরিষেবা চেইন আর্কিটেকচার ব্যবহার করে বিবেচনা করতে চাইতে পারেন। এটি শুধুমাত্র প্রয়োজনীয় ট্র্যাফিক ফায়ারওয়ালের মধ্য দিয়ে যাওয়ার অনুমতি দেবে। তত্ত্বে সুন্দর দেখায়, কিন্তু আমি এই সমাধানটি উৎপাদনে দেখিনি। আমরা প্রায় 5 বছর আগে Cisco ACI/Juniper SRX/F3 LTM-এর জন্য পরিষেবা চেইন পরীক্ষা করেছিলাম, কিন্তু সেই সময়ে এই সমাধানটি আমাদের কাছে "অশোধিত" বলে মনে হয়েছিল।

সুরক্ষা স্তর

এখন আপনাকে ট্র্যাফিক ফিল্টার করতে আপনি কোন সরঞ্জামগুলি ব্যবহার করতে চান সেই প্রশ্নের উত্তর দিতে হবে। এখানে এমন কিছু বৈশিষ্ট্য রয়েছে যা সাধারণত NGFW-তে উপস্থিত থাকে (উদাহরণস্বরূপ, এখানে):

• রাষ্ট্রীয় ফায়ারওয়ালিং (ডিফল্ট)
• অ্যাপ্লিকেশন ফায়ারওয়ালিং
• হুমকি প্রতিরোধ (অ্যান্টিভাইরাস, অ্যান্টি-স্পাইওয়্যার, এবং দুর্বলতা)
• ইউআরএল ফিল্টারিং
• ডেটা ফিল্টারিং (কন্টেন্ট ফিল্টারিং)
• ফাইল ব্লকিং (ফাইলের প্রকার ব্লকিং)
• ডস সুরক্ষা

এবং সবকিছু পরিষ্কার নয়। দেখে মনে হবে যে সুরক্ষার স্তর যত বেশি হবে তত ভাল। তবে আপনাকে এটিও বিবেচনা করতে হবে

• উপরের ফায়ারওয়াল ফাংশনগুলি আপনি যত বেশি ব্যবহার করবেন, স্বাভাবিকভাবেই এটি তত বেশি ব্যয়বহুল হবে (লাইসেন্স, অতিরিক্ত মডিউল)
• কিছু অ্যালগরিদমের ব্যবহার উল্লেখযোগ্যভাবে ফায়ারওয়াল থ্রুপুট কমাতে পারে এবং বিলম্ব বাড়াতে পারে, উদাহরণ স্বরূপ দেখুন এখানে
• যেকোনো জটিল সমাধানের মতো, জটিল সুরক্ষা পদ্ধতির ব্যবহার আপনার সমাধানের নির্ভরযোগ্যতা হ্রাস করতে পারে, উদাহরণস্বরূপ, অ্যাপ্লিকেশন ফায়ারওয়ালিং ব্যবহার করার সময়, আমি বেশ কিছু মানসম্পন্ন কাজের অ্যাপ্লিকেশন (dns, smb) ব্লক করার সম্মুখীন হয়েছি

সর্বদা হিসাবে, আপনাকে আপনার নেটওয়ার্কের জন্য সর্বোত্তম সমাধান খুঁজে বের করতে হবে।

কি সুরক্ষা ফাংশন প্রয়োজন হতে পারে এই প্রশ্নের সুনির্দিষ্টভাবে উত্তর দেওয়া অসম্ভব। প্রথমত, কারণ এটি অবশ্যই নির্ভর করে আপনি যে ডেটা প্রেরণ করছেন বা সংরক্ষণ করছেন এবং রক্ষা করার চেষ্টা করছেন। দ্বিতীয়ত, বাস্তবে, প্রায়শই নিরাপত্তা সরঞ্জামের পছন্দ বিক্রেতার বিশ্বাস এবং বিশ্বাসের বিষয়। আপনি অ্যালগরিদমগুলি জানেন না, আপনি জানেন না যে সেগুলি কতটা কার্যকর, এবং আপনি সেগুলি সম্পূর্ণভাবে পরীক্ষা করতে পারবেন না।

অতএব, সমালোচনামূলক বিভাগে, একটি ভাল সমাধান হতে পারে বিভিন্ন কোম্পানির অফার ব্যবহার করা। উদাহরণস্বরূপ, আপনি ফায়ারওয়ালে অ্যান্টিভাইরাস সক্ষম করতে পারেন, তবে হোস্টগুলিতে স্থানীয়ভাবে অ্যান্টিভাইরাস সুরক্ষা (অন্য নির্মাতার কাছ থেকে) ব্যবহার করতে পারেন।

সেগমেন্টেশন

আমরা ডেটা সেন্টার নেটওয়ার্কের লজিক্যাল সেগমেন্টেশন সম্পর্কে কথা বলছি। উদাহরণস্বরূপ, ভিএলএএন এবং সাবনেটে বিভাজন করাও যৌক্তিক বিভাজন, তবে আমরা এর স্পষ্টতার কারণে এটি বিবেচনা করব না। FW নিরাপত্তা অঞ্চল, VRFs (এবং বিভিন্ন বিক্রেতাদের সাথে সম্পর্কিত তাদের অ্যানালগ), লজিক্যাল ডিভাইস (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ... এর মতো সত্তাগুলিকে বিবেচনায় নিয়ে আকর্ষণীয় বিভাজন।

এই ধরনের যৌক্তিক বিভাজন এবং বর্তমানে চাহিদা থাকা ডেটা সেন্টার ডিজাইনের একটি উদাহরণ দেওয়া হয়েছে PSEFABRIC প্রকল্পের p002.

আপনার নেটওয়ার্কের যৌক্তিক অংশগুলিকে সংজ্ঞায়িত করার পরে, আপনি তারপরে বর্ণনা করতে পারেন যে কীভাবে বিভিন্ন বিভাগের মধ্যে ট্র্যাফিক চলে যায়, কোন ডিভাইসে ফিল্টারিং সঞ্চালিত হবে এবং কী উপায়ে।

যদি আপনার নেটওয়ার্কে একটি সুস্পষ্ট যৌক্তিক পার্টিশন না থাকে এবং বিভিন্ন ডেটা প্রবাহের জন্য নিরাপত্তা নীতি প্রয়োগ করার নিয়মগুলি আনুষ্ঠানিকভাবে না থাকে, তাহলে এর মানে হল যে আপনি যখন এই বা সেই অ্যাক্সেসটি খুলবেন, তখন আপনি এই সমস্যাটি সমাধান করতে বাধ্য হবেন এবং একটি উচ্চ সম্ভাবনার সাথে আপনি প্রতিবার ভিন্নভাবে সমাধান করবে।

প্রায়শই বিভাজন শুধুমাত্র FW নিরাপত্তা অঞ্চলের উপর ভিত্তি করে। তারপর আপনাকে নিম্নলিখিত প্রশ্নের উত্তর দিতে হবে:

• আপনি কি নিরাপত্তা জোন প্রয়োজন
• এই প্রতিটি অঞ্চলে আপনি কোন স্তরের সুরক্ষা প্রয়োগ করতে চান
• অন্তঃ-জোন ট্রাফিক ডিফল্টরূপে অনুমোদিত হবে?
• যদি না হয়, প্রতিটি জোনের মধ্যে কি ট্রাফিক ফিল্টারিং নীতি প্রয়োগ করা হবে
• প্রতিটি জোনের জন্য ট্রাফিক ফিল্টারিং নীতিগুলি প্রয়োগ করা হবে (উৎস/গন্তব্য)

TCAM

একটি সাধারণ সমস্যা হল অপর্যাপ্ত TCAM (Ternary Content Addressable Memory), উভয় রাউটিং এবং অ্যাক্সেসের জন্য। IMHO, সরঞ্জাম নির্বাচন করার সময় এটি সবচেয়ে গুরুত্বপূর্ণ সমস্যাগুলির মধ্যে একটি, তাই আপনাকে যথাযথ যত্নের সাথে এই সমস্যাটির চিকিত্সা করতে হবে।

উদাহরণ 1. ফরওয়ার্ডিং টেবিল TCAM।

চল বিবেচনা করি Palo Alto 7k ফায়ারওয়াল
আমরা দেখতে পাই যে IPv4 ফরওয়ার্ডিং টেবিলের আকার* = 32K
অধিকন্তু, সমস্ত VSYS-এর জন্য এই সংখ্যক রুট সাধারণ।

ধরা যাক আপনার ডিজাইন অনুযায়ী আপনি 4 VSYS ব্যবহার করার সিদ্ধান্ত নিয়েছেন।
এই প্রতিটি VSYSs BGP এর মাধ্যমে ক্লাউডের দুটি MPLS PE-এর সাথে সংযুক্ত থাকে যা আপনি BB হিসাবে ব্যবহার করেন। এইভাবে, 4টি VSYS একে অপরের সাথে সমস্ত নির্দিষ্ট রুট বিনিময় করে এবং প্রায় একই রুটের সেটগুলির সাথে একটি ফরওয়ার্ডিং টেবিল থাকে (কিন্তু ভিন্ন NH)। কারণ প্রতিটি VSYS-এর 2টি BGP সেশন রয়েছে (একই সেটিংস সহ), তারপর MPLS এর মাধ্যমে প্রাপ্ত প্রতিটি রুটে 2 NH আছে এবং সেই অনুযায়ী, ফরোয়ার্ডিং টেবিলে 2টি FIB এন্ট্রি রয়েছে। যদি আমরা ধরে নিই যে ডাটা সেন্টারে এটিই একমাত্র ফায়ারওয়াল এবং এটি অবশ্যই সমস্ত রুট সম্পর্কে জানতে হবে, তাহলে এর মানে হবে যে আমাদের ডেটা সেন্টারে মোট রুটের সংখ্যা 32K/(4 * 2) = 4K এর বেশি হতে পারে না।

এখন, যদি আমরা ধরে নিই যে আমাদের 2টি ডেটা সেন্টার আছে (একই ডিজাইনের), এবং আমরা ডেটা সেন্টারের মধ্যে "প্রসারিত" VLAN ব্যবহার করতে চাই (উদাহরণস্বরূপ, vMotion এর জন্য), তাহলে রাউটিং সমস্যা সমাধানের জন্য, আমাদের অবশ্যই হোস্ট রুট ব্যবহার করতে হবে। . কিন্তু এর মানে হল যে 2টি ডেটা সেন্টারের জন্য আমাদের কাছে 4096 টির বেশি সম্ভাব্য হোস্ট থাকবে না এবং অবশ্যই, এটি যথেষ্ট নাও হতে পারে।

উদাহরণ 2. ACL TCAM।

আপনি যদি L3 সুইচগুলিতে ট্র্যাফিক ফিল্টার করার পরিকল্পনা করেন (অথবা অন্যান্য সমাধান যা L3 সুইচগুলি ব্যবহার করে, উদাহরণস্বরূপ, সিসকো এসিআই), তাহলে সরঞ্জাম নির্বাচন করার সময় আপনাকে TCAM ACL এর দিকে মনোযোগ দিতে হবে।

ধরুন আপনি সিসকো ক্যাটালিস্ট 4500 এর এসভিআই ইন্টারফেসে অ্যাক্সেস নিয়ন্ত্রণ করতে চান। তারপর, যেমনটি থেকে দেখা যাবে এই নিবন্ধটি এর, ইন্টারফেসে আউটগোয়িং (সেসাথে ইনকামিং) ট্রাফিক নিয়ন্ত্রণ করতে, আপনি শুধুমাত্র 4096 টিসিএএম লাইন ব্যবহার করতে পারেন। যা TCAM3 ব্যবহার করার সময় আপনাকে প্রায় 4000 হাজার ACE (ACL লাইন) দেবে।

আপনি যদি অপর্যাপ্ত টিসিএএম-এর সমস্যার মুখোমুখি হন, তবে প্রথমে আপনাকে অবশ্যই অপ্টিমাইজেশনের সম্ভাবনা বিবেচনা করতে হবে। সুতরাং, ফরোয়ার্ডিং টেবিলের আকারের সাথে সমস্যা হলে, আপনাকে রুটগুলিকে একত্রিত করার সম্ভাবনা বিবেচনা করতে হবে। অ্যাক্সেসের জন্য TCAM আকারে সমস্যা হলে, অডিট অ্যাক্সেস, পুরানো এবং ওভারল্যাপিং রেকর্ডগুলি সরিয়ে ফেলুন এবং সম্ভবত অ্যাক্সেসগুলি খোলার পদ্ধতিটি সংশোধন করুন (অডিটিং অ্যাক্সেসের অধ্যায়ে বিশদভাবে আলোচনা করা হবে)।

উচ্চ প্রাপ্যতা

প্রশ্ন হল: আমার কি ফায়ারওয়ালের জন্য HA ব্যবহার করা উচিত বা "সমান্তরালে" দুটি স্বাধীন বাক্স ইনস্টল করা উচিত এবং তাদের মধ্যে একটি ব্যর্থ হলে, দ্বিতীয়টির মাধ্যমে ট্র্যাফিক রুট করা উচিত?

মনে হবে উত্তরটি সুস্পষ্ট - HA ব্যবহার করুন। যে কারণে এই প্রশ্নটি এখনও উত্থাপিত হয় তা হল যে, দুর্ভাগ্যবশত, তাত্ত্বিক এবং বিজ্ঞাপন 99 এবং অনুশীলনে অ্যাক্সেসযোগ্যতার কয়েক দশমিক শতাংশ এতটা গোলাপী থেকে অনেক দূরে। HA যৌক্তিকভাবে বেশ জটিল জিনিস, এবং বিভিন্ন সরঞ্জামে এবং বিভিন্ন বিক্রেতাদের সাথে (কোনও ব্যতিক্রম ছিল না), আমরা সমস্যা এবং বাগ এবং পরিষেবা বন্ধ করেছিলাম।

আপনি যদি HA ব্যবহার করেন তবে আপনার কাছে পৃথক নোডগুলি বন্ধ করার সুযোগ থাকবে, পরিষেবাটি বন্ধ না করে তাদের মধ্যে স্যুইচ করুন, যা গুরুত্বপূর্ণ, উদাহরণস্বরূপ, আপগ্রেড করার সময়, তবে একই সাথে আপনার উভয় নোডের শূন্য সম্ভাবনা থেকে অনেক দূরে রয়েছে। একই সময়ে ভেঙ্গে যাবে, এবং এটিও যে পরবর্তী আপগ্রেডটি বিক্রেতার প্রতিশ্রুতি অনুসারে সহজে যাবে না (আপনার যদি ল্যাবরেটরি সরঞ্জামগুলিতে আপগ্রেড পরীক্ষা করার সুযোগ থাকে তবে এই সমস্যাটি এড়ানো যেতে পারে)।

আপনি যদি HA ব্যবহার না করেন, তাহলে দ্বিগুণ ব্যর্থতার দৃষ্টিকোণ থেকে আপনার ঝুঁকি অনেক কম (যেহেতু আপনার 2টি স্বাধীন ফায়ারওয়াল আছে), কিন্তু যেহেতু... সেশনগুলি সিঙ্ক্রোনাইজ করা হয় না, তারপর যতবার আপনি এই ফায়ারওয়ালগুলির মধ্যে স্যুইচ করবেন আপনি ট্র্যাফিক হারাবেন। আপনি, অবশ্যই, স্টেটলেস ফায়ারওয়ালিং ব্যবহার করতে পারেন, কিন্তু তারপরে ফায়ারওয়াল ব্যবহার করার বিন্দুটি অনেকাংশে হারিয়ে গেছে।

অতএব, যদি অডিটের ফলস্বরূপ আপনি একাকী ফায়ারওয়ালগুলি আবিষ্কার করেন এবং আপনি আপনার নেটওয়ার্কের নির্ভরযোগ্যতা বাড়ানোর কথা ভাবছেন, তবে HA অবশ্যই প্রস্তাবিত সমাধানগুলির মধ্যে একটি, তবে আপনার সংশ্লিষ্ট অসুবিধাগুলিও বিবেচনা করা উচিত। এই পদ্ধতির সাথে এবং, সম্ভবত, বিশেষভাবে আপনার নেটওয়ার্কের জন্য, অন্য সমাধানটি আরও উপযুক্ত হবে।

পরিচালনাযোগ্যতা

নীতিগতভাবে, HA নিয়ন্ত্রণযোগ্যতা সম্পর্কেও। 2টি বাক্স আলাদাভাবে কনফিগার করার পরিবর্তে এবং কনফিগারেশনগুলিকে সিঙ্কে রাখার সমস্যা মোকাবেলা করার পরিবর্তে, আপনি সেগুলিকে এমনভাবে পরিচালনা করেন যেন আপনার একটি ডিভাইস ছিল।

কিন্তু সম্ভবত আপনার অনেক ডেটা সেন্টার এবং অনেক ফায়ারওয়াল আছে, তাহলে এই প্রশ্নটি একটি নতুন স্তরে উত্থাপিত হয়। এবং প্রশ্ন শুধুমাত্র কনফিগারেশন সম্পর্কে নয়, কিন্তু সম্পর্কেও

• ব্যাকআপ কনফিগারেশন
• আপডেট
• আপগ্রেড
• পর্যবেক্ষণ
• লগিং

এবং এই সব কেন্দ্রীভূত ব্যবস্থাপনা সিস্টেম দ্বারা সমাধান করা যেতে পারে.

সুতরাং, উদাহরণস্বরূপ, আপনি যদি Palo Alto ফায়ারওয়াল ব্যবহার করছেন, তাহলে পরিদৃশ্য যেমন একটি সমাধান.

অবিরত করা।

উত্স: www.habr.com