SoftEther VPN Azure: একটি রিলে পথ, খোলা পোর্ট নয়

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

পথে কী বদলায়

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

রিলে সেই সার্ভারকে নিজের ডোমেইনে একটি নাম দেয়, আর ক্লায়েন্টরা সেখানে সংযোগ করতে কনফিগার হয়।

সেই নামটি রিলে সেবার, যা Microsoft Azure VPN Gateway নয় যদিও দুটোকেই Azure কিছু বলা হয়। এদের বিনিময়যোগ্য ভাবলে এমন কনফিগারেশন তৈরি হয় যা কাজ করতে পারে না।

কোন প্রোটোকলগুলো রিলে পেরোয়

রিলে SoftEther প্রোটোকল বহন করে, আর প্রকল্পটি SSTP -কে ক্লায়েন্ট বিকল্প হিসেবে নথিভুক্ত করে, যা উপকারী কারণ Windows-এ একটি SSTP ক্লায়েন্ট থাকে। তবে এটি হোস্টের প্রতিটি লিসেনারের জন্য সাধারণ বাহক হয়ে ওঠে না: OpenVPN লিসেনার, IPsec উত্তরদাতা এবং L2TP সেবার প্রত্যেকের নিজস্ব নাগালের শেষবিন্দু দরকার, এবং কেবল SoftEther সার্ভার সংযুক্ত থাকার কারণে এদের কোনোটিই রিলে দিয়ে পরিবাহিত হয় না।

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

রিলে আপনার জন্য যা করে না

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

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

সার্টিফিকেট যাচাই ও ব্যবহারকারী প্রমাণীকরণ সার্ভারের দায়িত্বই থাকে, এবং রিলে কখনোই দুটির কোনোটির বিকল্প হয় না।

এটি নির্ভরতা হিসেবে চালান

প্রাপ্যতা এখন একটি তৃতীয় পক্ষকে অন্তর্ভুক্ত করে। রিলে নাগালের বাইরে থাকলে আপনার সার্ভার যতই সুস্থ থাকুক ক্লায়েন্টরা সংযোগ করতে পারে না, আর ব্যর্থতাটি বাইরে থেকে ক্লায়েন্ট সমস্যার মতো দেখায়। সার্ভারের নিজের স্বাস্থ্য থেকে আলাদাভাবে রিলে পথ পর্যবেক্ষণ করুন, এবং যেদিন এটি গুরুত্বপূর্ণ হবে সেদিনের জন্য অন্য ঠিকানায় সরাসরি লিসেনারের মতো একটি নথিভুক্ত বিকল্প পরিকল্পনা রাখুন।

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

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