SoftEther-এর ভার্চুয়াল হাব আসলে কী সংযুক্ত করে

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

হাব একটি সদস্যপদের সীমা

একটি সার্ভার কয়েকটি হাব হোস্ট করতে পারে, প্রতিটির নিজস্ব ব্যবহারকারী, সেশন ও নীতি নিয়ে। প্রমাণীকরণ ঠিক করে সেশনটি কে, আর হাব ঠিক করে সেই সেশন কোন ভার্চুয়াল নেটওয়ার্কে যোগ দেবে। তাই একই হোস্টে দুটি হাব ঠিক দুটি আলাদা সুইচের মতো আচরণ করে যা কেবল হার্ডওয়্যার ভাগ করে। সফল লগইনে সেশনটি আপনার ইচ্ছামতো জায়গায় পৌঁছেছে এমন কিছু বোঝায় না।

স্ক্রিনশট থেকে মনে রাখা নামের বদলে অপারেটরের নথিভুক্ত হাবের নাম ব্যবহার করুন। ভুল হাবে যোগ দেওয়া ক্লায়েন্ট বৈধ ক্রেডেনশিয়াল নিয়েই অন্য নেটওয়ার্কে পৌঁছে, যা নিরাপত্তা লঙ্ঘন নয় বরং কনফিগারেশনের একটি পর্যবেক্ষণ। হাবের নাম ও তার উদ্দেশ্য সংযোগ প্রোফাইলের নোটে রাখুন।

প্রশাসনও একইভাবে সীমাবদ্ধ। একজন হাব প্রশাসক সেই হাব পরিচালনা করেন, আর সার্ভার প্রশাসক প্রক্রিয়া, লিসেনার এবং হোস্টের প্রতিটি হাব পরিচালনা করেন।

সংযুক্তিগুলো ঠিক করে ওপারে কী আছে

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

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

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

সেশন ও নীতি আলাদাভাবে পড়ুন

সেশন, MAC ঠিকানা ও IP ঠিকানার ভিউ দেখায় ভার্চুয়াল নেটওয়ার্ক এখন কেমন দেখাচ্ছে। এগুলো পর্যবেক্ষণ, অনুমতি নয়। তালিকায় দৃশ্যমান একটি সেশন এতেই হাব যে সেবা পর্যন্ত পৌঁছাতে পারে তার সবটির অধিকারী হয় না, আর উল্টোটাও সত্য।

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

সার্ভারে vpncmd হোস্টের দৃষ্টিকোণ থেকে একই চিত্র দেখায়। দুটো অসঙ্গত হলে সেই আউটপুট ক্লায়েন্টের নিজস্ব ভিউয়ের সঙ্গে তুলনা করুন।

vpncmd localhost /SERVER /CMD SessionList
vpncmd localhost /SERVER /CMD HubList

হাব প্রশাসনকে ক্লায়েন্ট অনুমতি নয়, আলাদা ভূমিকা হিসেবে দেখুন। একটি হাব অর্পণ করলে লিসেনার বা অন্য প্রতিটি হাব হোস্ট করা প্রক্রিয়া হস্তান্তর হওয়া উচিত নয়।

যোগ দেওয়ার পরে ক্লায়েন্ট পরীক্ষা করুন

ক্লায়েন্টের দিক থেকে প্রতিষ্ঠিত সেশন কেবল প্রমাণ করে প্রমাণীকরণ ও হাবের নাম গৃহীত হয়েছে। ঠিকানা, রুট ও নাম সমাধান আলাদাভাবে নিশ্চিত করুন, কারণ হাব সেশন গ্রহণের পরেও প্রতিটি ব্যর্থ হতে পারে।

ip -brief address show
ip route get 10.20.30.41
resolvectl query host.internal

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

লিংক নয়, অ্যাপ্লিকেশন পরীক্ষা করুন। যে ইন্ট্রানেট পাতা লোড হয় তা বিশ্বাসযোগ্য ঠিকানা থাকা অ্যাডাপ্টারের চেয়ে শক্তিশালী প্রমাণ।