SoftEther ক্যাসকেড: দুটি ভার্চুয়াল হাব সচেতনভাবে সংযুক্ত করুন
একটি ক্যাসকেড একটি কনফিগার করা পরিচয়ের অধীনে স্থানীয় হাবকে দূরবর্তী হাবের সঙ্গে যুক্ত করে। এটি কোনো এক্সিট নোড নয়, এবং এই হাবগুলি যা ইতিমধ্যে ব্রিজ করে তা বহন করে।
একটি ক্যাসকেডে যুক্ত দুটি SoftEther হাব একটি সম্প্রচার ডোমেইন ভাগ করে, তাই একটি লুপ বা দ্বিতীয় DHCP সার্ভার আর স্থানীয় ভুল থাকে না, বরং ভাগ করা ভুল হয়ে যায়। এটাই পুরো ঝুঁকির মডেল। ক্যাসকেড নিজেই একটি কনফিগার করা ক্লায়েন্ট সম্পর্ক: স্থানীয় ভার্চুয়াল হাব একটি দূরবর্তী সার্ভারের হাবে সেই সার্ভারের অনুমোদিত পরিচয়ে সংযুক্ত হয়। এটি বড় ভার্চুয়াল নেটওয়ার্কের একটি নির্মাণ ব্লক, কখনও ইন্টারনেট এক্সিট নয়।
1. লিঙ্কটিকে কী বহন করতে হবে তা ঠিক করুন
বৈশিষ্ট্য থেকে নয়, প্রয়োজন থেকে শুরু করুন। একটি ক্যাসকেড হাবগুলির মধ্যে লেয়ার-টু ফ্রেম নিয়ে যায়, যা তখন দরকার যখন দুটি সাইটকে একটি ইথারনেট সেগমেন্টের মতো দেখাতে হয়। যদি প্রয়োজন শুধু কয়েকটি সাবনেটে রাউটেড অ্যাক্সেস হয়, তবে রাউটেড পথ সরল এবং আরও দৃশ্যমানভাবে ব্যর্থ হয়। ক্যাসকেড বেছে নিলে আপনি ভাগ করা সম্প্রচার, ভাগ করা আবিষ্কার এবং একটি লুপ টপোলজিতে বাঁধা পড়েন।
সার্ভার স্পর্শ করার আগে প্রয়োজনটি এক লাইনে লিখুন: কোন সিস্টেমগুলিকে একই তারে থাকতে হবে এবং কোনগুলির শুধু রুট দরকার। «রুট» উত্তর দেয় এমন সবকিছু ক্যাসকেডের বাইরে থাকে। এই একটি বাক্য ডুপ্লিকেট ঠিকানা সেবায় শেষ হওয়া বেশিরভাগ ডিজাইন আটকায়।
2. যে পরিচয় অনুমোদন করে তার পরিধি নির্ধারণ করুন
যে ক্রেডেনশিয়াল সার্ভার পরিচালনা করে এবং ক্যাসকেড যে পরিচয় দিয়ে সংযুক্ত হয় সেগুলি আলাদা গোপন তথ্য, এবং সেগুলি মেশানো দীর্ঘ প্রভাবযুক্ত একটি সাধারণ শর্টকাট। দূরবর্তী হাবের একটি ব্যবহারকারী বা নীতি এন্ট্রি দরকার যা এই ক্যাসকেডকে সংযুক্ত হতে দেয়। সেই এন্ট্রিই অনুমোদন; সফল লগইন দূরবর্তী হাবের পিছনে কী আছে সে সম্পর্কে কিছুই বলে না।
কোন হাব শুরু করে, কোন দূরবর্তী হাবে যোগ দেয় এবং দূরবর্তী পরিচয় কী পর্যন্ত পৌঁছাতে পারে তা লিখুন। প্রতিশ্রুতি দেওয়ার আগে দুটি আর্কিটেকচার তুলনা করুন:
| Requirement | Routed path | Cascaded segment |
|---|---|---|
| Broadcast domain | Separate on each side | Shared across the link |
| Address service | One DHCP server per side | Must not run two on one domain |
| Loop risk | Route loops only | Layer-two loops if segments overlap |
দুই প্রান্তের ক্রেডেনশিয়াল এবং পুনরুদ্ধারের নির্দেশাবলী হালনাগাদ রাখুন। দূরবর্তী হাবে পাসওয়ার্ড পরিবর্তন বা নীতি সম্পাদনা আপনার স্থানীয় ব্যবহারকারীদের স্পর্শ না করেই ক্যাসকেড ভেঙে দেয়, এবং ব্যর্থতা সাধারণত চালু অথচ খালি লিঙ্ক হিসেবে দেখা যায়।
3. হাব ইতিমধ্যে কী বহন করে তা পরীক্ষা করুন
একটি হাব খুব কমই বিচ্ছিন্ন থাকে। এটি ইতিমধ্যে একটি ভৌত অ্যাডাপ্টারে ব্রিজ করতে, ভার্চুয়াল রাউটারের মধ্য দিয়ে রাউট করতে বা অন্য কোথাও ক্যাসকেড করতে পারে, এবং সেই সংযুক্তিগুলির প্রত্যেকটি নতুন সম্পর্কে বহন করা হয়। তাই «আমরা শুধু দুটি হাব যুক্ত করেছি» প্রায়ই হয়ে ওঠে «কেন এই দুটি সাইট এখন এক সেগমেন্ট?»।
একই ভৌত সেগমেন্টে ব্রিজ করা এবং তারপর একে অপরের সঙ্গে ক্যাসকেড করা দুটি হাব একটি লুপ গঠন করে। স্প্যানিং ট্রি যোগ করুন বা এটি তৈরি করবেন না। একই পরীক্ষা সেই হাবের ক্ষেত্রেও প্রযোজ্য যা অন্য ক্যাসকেডের মাধ্যমে লক্ষ্যে পৌঁছায়: দ্বিতীয় লিঙ্ক ক্ষমতা যোগ করে না, পথ যোগ করে।
একটি রুট অনুপস্থিত বলে লিঙ্ক যোগ করবেন না; রুটটি ঠিক করুন। প্রথমে কাগজে টপোলজি আঁকুন, প্রতিটি ব্রিজ ও ক্যাসকেড সহ, কারণ চিত্রটি দুই মিনিট নেয় এবং বেশিরভাগ লুপ তৈরি হওয়ার আগেই ধরে ফেলে।
4. যোগ দেওয়ার আগে ঠিকানা ঠিক করুন
যুক্ত সেগমেন্টগুলি ডুপ্লিকেট সাবনেট আনে, এবং ডুপ্লিকেট DHCP সার্ভার ক্লাসিক লক্ষণ: ক্লায়েন্টরা যে সার্ভার আগে উত্তর দেয় তার কাছ থেকে লিজ নেয়, তাই আচরণ এলোমেলো দেখায় এবং রিবুটের মধ্যে সরে যায়। আগেই ঠিক করুন কোন পক্ষ ঠিকানা বরাদ্দের মালিক, এবং দূরের সেগমেন্টকে এমন রেঞ্জ দিন যা স্থানীয় কিছুর সঙ্গে ওভারল্যাপ না করে। ক্যাসকেড অনলাইনে আসার আগেই অন্য DHCP সেবা বন্ধ করুন, প্রথম অভিযোগের পরে নয়।
DNS একটি আলাদা প্রশ্ন। ক্যাসকেড ফ্রেম বহন করে; এটি রিজলভার কনফিগার করে না, এবং স্থানীয় দিকে রিজলভ হওয়া একটি নাম লিঙ্কের ওপারে না-ও রিজলভ হতে পারে। IP পথ থেকে আলাদাভাবে লুকআপ পরীক্ষা করুন, কারণ কাজ করা ping দুটির মধ্যে একটিই প্রমাণ করে।
5. বাস্তব সম্পদ দিয়ে এটি প্রমাণ করুন
উদ্দিষ্ট দূরবর্তী সেগমেন্টে একটি অনুমোদিত সেবা বেছে নিন এবং উত্তর ক্যাসকেডের মধ্য দিয়ে ফিরে আসছে তা নিশ্চিত করুন। তারপর নাম রিজলিউশনের জন্য পুনরাবৃত্তি করুন। লক্ষ্য যদি সম্প্রচার আবিষ্কারের উপর নির্ভর করে, তবে একক তারের চেয়ে ব্রিজ করা লিঙ্কে ভিন্ন আচরণ আশা করুন, এবং এটি ত্রুটি হিসেবে নথিভুক্ত করার বদলে পরিকল্পনা করুন।
শেষে টপোলজি লিখে রাখুন: কোন হাব কোথায় ক্যাসকেড করে, কোন পরিচয় তা অনুমোদন করে, কোন সেগমেন্টগুলি ব্রিজ করা এবং প্রতিটিতে ঠিকানা বরাদ্দের মালিক কে। সেই নোটই পরবর্তী ব্যক্তিকে এমন একটি সেগমেন্ট নামিয়ে না দিয়ে নীতি বদলাতে দেয় যার অস্তিত্ব সে জানত না।