SoftEther লোকাল ব্রিজ বনাম SecureNAT: কোনটি চালু করবেন

SoftEther Manager খুলুন, আর কোনো হাব সম্পর্কে প্রথম সত্যিকারের সিদ্ধান্ত কোনো চেকবক্স নয়, এটি টোপোলজির প্রশ্ন। লোকাল ব্রিজ সেই হাবটিকে একটি ফিজিক্যাল অ্যাডাপ্টারের সঙ্গে যুক্ত করে এবং বিদ্যমান সেগমেন্টকেই ঠিকানা সরবরাহ করতে দেয়, আর SecureNAT হাবটিকে তার নিজের ভার্চুয়াল রাউটার, NAT ও DHCP দেয়। এদের মধ্যে বেছে নেওয়া ঠিকানা কোথা থেকে আসবে এবং কোন ডিভাইস তার উত্তর দেবে তা বদলে দেয়। দুটোই চালু করে একটি জিতবে বলে আশা করা — এভাবেই একটি কাজ করা ল্যাব সাপোর্ট থ্রেডে পরিণত হয়।

আপনি যে হাবটি সত্যিই সম্পাদনা করছেন সেখান থেকেই শুরু করুন

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

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

কিছু ক্লিক করার আগে উত্তরটি লিখে রাখুন, কারণ দুটি সেটিং পরস্পর বিনিময়যোগ্য নয় এবং ফিরিয়ে নিতে সিদ্ধান্ত নেওয়ার চেয়ে বেশি সময় লাগে। দুই মিনিটের লেখা এক ঘণ্টার পুনঃসংযোগ বাঁচায়।

লোকাল ব্রিজ ঠিকানার সঙ্গে কী করে

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

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

গ্রাফিক্যাল ট্রি অস্পষ্ট হলে কমান্ড লাইন থেকে ব্রিজ টেবিল পড়ুন। আউটপুট অ্যাডাপ্টারের নাম বলে, যা ট্রি সবসময় করে না।

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

সংযুক্ত সেশনসহ খালি ব্রিজ তালিকা একটি কাজের ছবি: ক্লায়েন্টরা ভার্চুয়াল হাবের ভিতরে, আর এখনো কিছুই এটিকে সেগমেন্টে সম্প্রসারিত করছে না।

SecureNAT কী যোগ করে, আর কী লুকায়

SecureNAT হাবটিকে একটি ভার্চুয়াল রাউটার, একটি NAT ফাংশন ও একটি DHCP সেবা দেয়, সবই SoftEther প্রসেসের ভিতরে। ক্লায়েন্টরা ভার্চুয়াল DHCP পরিসর থেকে ঠিকানা পায়, ভার্চুয়াল রাউটার ডিফল্ট গেটওয়ের উত্তর দেয়, আর বের হতে যাওয়া ট্রাফিক অনূদিত হয়। কোনো ফিজিক্যাল অ্যাডাপ্টার জড়িত নয়, এই কারণেই একটি NIC ও কোনো সুইচ কনফিগারেশন ছাড়া হোস্টে এটি কাজ করে।

খরচটি হলো ভার্চুয়াল ঠিকানাগুলো হাবের, আর অন্য কিছুর নয়। অফিস LAN-এর একটি মেশিন সাহায্য ছাড়া কোনো ক্লায়েন্টের SecureNAT ঠিকানায় রাউট করতে পারে না, আর সোর্স ঠিকানা লগ করে এমন সবকিছু SoftEther হোস্টের অনূদিত ঠিকানাই দেখে। আপনার অ্যাক্সেস নিয়ম বা অডিট ট্রেইল যদি ক্লায়েন্টের আসল ঠিকানার ওপর নির্ভর করে, তবে এটি বিস্তারিত নয়, নকশার পরিবর্তন। এটি এটাও ঠিক করে সোর্স-ঠিকানা নিয়ম ক্লায়েন্টকে আদৌ দেখবে কি না।

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

অন্য কিছু চালু করার আগে দেখুন হাবটি এখন কী সেবা দিচ্ছে। প্রতিটি কমান্ড বর্তমান অবস্থা ছাপে, কাঙ্ক্ষিত অবস্থা নয়।

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

একটি চালু করা, অন্যটি না ভেঙে

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

পরিবর্তনটি এমনভাবে সাজান যাতে ক্লায়েন্ট পুল LAN পরিসরের সঙ্গে ওভারল্যাপ না করে। ওভারল্যাপিং সাবনেট হলো সংযুক্ত হয়ে তারপর কিছুতে পৌঁছাতে না পারা টানেলের দ্বিতীয় সবচেয়ে সাধারণ কারণ, আর দুটি ঠিকানা পরিকল্পনা পাশাপাশি মিলিয়ে না দেখা পর্যন্ত এগুলো অদৃশ্য থাকে।

তারপর ক্লায়েন্ট থেকে আবার সংযুক্ত হন এবং সে কী পেয়েছে তা পড়ুন, কারণ হাবের সেশন-দৃষ্টি ক্লায়েন্টের নিজের নেটওয়ার্ক-দৃষ্টি নয়। নতুন লিজ বাধ্য করার একমাত্র নির্ভরযোগ্য উপায় হলো পুনঃসংযোগ।

ক্লায়েন্টে গেটওয়ে ও রিজলভার যাচাই করুন

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

Windows-এ অ্যাডাপ্টার বিস্তারিত লিজ ও রিজলভার দেখায়, আর রুট টেবিল দেখায় টানেলটি সত্যিই ডিফল্ট পথ কি না।

ipconfig /all
route print -4
nslookup intranet.corp.internal

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