NAT-এর পিছনে SoftEther: সরাসরি ট্রাভার্সাল নাকি VPN Azure রিলে?

আপনার SoftEther সার্ভার এমন একটি প্রোভাইডার রাউটারের পিছনে আছে যা আপনি বদলাতে পারেন না, আর ক্লায়েন্টরা তবুও সংযোগ করে, তাই আপনি ধরে নেন একটি রিলে সবকিছু বহন করছে। এটি সত্য কিনা তা নির্ভর করে কোন প্রক্রিয়াটি কাজটি করেছে তার উপর: একটি DNS নাম, একটি সমন্বিত UDP পথ, নাকি রিলের দিকে একটি আউটবাউন্ড টানেল। তিনটিই একটি সংযুক্ত ক্লায়েন্ট তৈরি করতে পারে, আর তারা ভিন্ন পরিস্থিতিতে ব্যর্থ হয়। ব্যবহারকারী বা হাব স্পর্শ করার আগে আপনি কোন পথ কিনছেন তা ঠিক করুন।

তিনটি প্রক্রিয়া, তিনটি ভিন্ন প্রতিশ্রুতি

ডাইনামিক DNS হলো নামকরণ। এটি একটি হোস্টনামকে বদলাতে থাকা ঠিকানার দিকে ধরে রাখে যাতে মানুষ সংখ্যাটার পিছনে ছোটা বন্ধ করে, আর এটি অন্য কিছু করে না। নেটিভ NAT ট্রাভার্সাল হলো সমন্বয়: দুটি SoftEther এন্ডপয়েন্ট তথ্য বিনিময় করে এবং তাদের মধ্যে থাকা অনুবাদ ডিভাইসগুলোর মধ্য দিয়ে একটি ব্যবহারযোগ্য UDP পথ খুলতে চেষ্টা করে। VPN Azure একটি রিলে: সার্ভারটি পরিষেবার দিকে ডায়াল আউট করে, আর ক্লায়েন্টরা রিলের অবকাঠামোর একটি হোস্টনাম দিয়ে আসে।

তিনটি পরিপূরক, একই বৈশিষ্ট্যের সংস্করণ নয়। একটি স্থাপনা নামকরণ ব্যবহার করতে পারে, অথচ তার সংযোগ আসলে ট্রাভার্সাল বা রিলের উপর নির্ভর করে।

ক্লায়েন্ট ও নেটওয়ার্ক থেকেই সিদ্ধান্ত নিন

নির্বাচন ক্লায়েন্ট থেকে শুরু, কারণ ট্রাভার্সাল কেবল নেটিভ SoftEther সংযোগ প্রক্রিয়াতেই আছে। একই সার্ভারে OpenVPN, L2TP/IPsec ও SSTP লিসেনার এটি উত্তরাধিকারসূত্রে পায় না, যদিও তারা একটি হোস্ট ভাগ করে। ব্যবহারকারী কী চালাবে, তারপর নেটওয়ার্ক কী অনুমোদন করে তা দেখুন। যে কর্পোরেট নেটওয়ার্ক কেবল TCP 443 অনুমোদন করে তা আপনাকে ওই পোর্টের রিলের দিকে ঠেলে দেয়, আর যে নেটওয়ার্ক ট্রাভার্সালের প্রয়োজনীয় UDP পোর্টগুলো পার হতে দেয় সে সরাসরি পথ চেষ্টা করতে পারে; উভয়ই প্রকৃত ইগ্রেস নীতির বিপরীতে যাচাই করুন।

হাতে পৌঁছানো যায় এমন লিসেনার তখনও বৈধ নকশা যখন প্রশাসক একটি প্রকাশ করতে পারেন, তবে এটি নিজস্ব ঠিকানা ও ফায়ারওয়াল কাজসহ আলাদা প্রকল্প।

সেশনটি কোন ট্রান্সপোর্ট বেছে নিয়েছে তা নিশ্চিত করুন

সংযোগ স্থিতিই ব্যবহৃত পথের একমাত্র সৎ উৎস। এটি সার্ভারে পড়ুন, আর ক্লায়েন্টকে দেওয়া হোস্টনামটি রিজলভ করুন।

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

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

নির্বাচিত পথ কীসের উপর নির্ভর করে তা পরিকল্পনা করুন

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

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