একটি VPN ক্লায়েন্ট সত্যিই SSTP সমর্থন করে কি না তা যাচাই করার উপায়

কোনও পণ্যকে VPN ক্লায়েন্ট বলা বললেই বোঝায় না যে তা SSTP-তে কথা বলে, আর URL-এ 443 পোর্ট থাকা আরও কম প্রমাণ করে। SSTP প্রথমে TCP 443-এর উপর TLS চালায়, তারপর একটি SSTP নিয়ন্ত্রণ বিনিময়, তারপর সংযোগটির জন্য PPP, আর তার উপরে সার্টিফিকেট যাচাই ও একটি PPP প্রমাণীকরণ পদ্ধতি। ক্লায়েন্ট কেবল তখনই প্রোটোকলটি সমর্থন করে, যখন উল্লিখিত বাস্তবায়নটি ইনস্টল করা সংস্করণে আপনার সার্ভারের প্রয়োজন অনুযায়ী ওই প্রতিটি স্তর সম্পন্ন করে। নিচের যাচাইগুলো ক্রমে করুন এবং প্রথম ব্যর্থটিতেই থামুন, কারণ সেটিই সমাধানের যোগ্য।

বাস্তবায়ন, সংস্করণ ও প্ল্যাটফর্ম মিলিয়ে দেখুন

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

Windows-এ টানেল ধরন আসে প্ল্যাটফর্ম থেকে, GUI থেকে নয়, তাই প্ল্যাটফর্মকেই জিজ্ঞাসা করুন। Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress কমান্ডটি Sstp দেখায় যখন নেটিভ ক্লায়েন্ট প্রোটোকলটি চেষ্টা করবে, এবং সংযোগ ধরনের রেফারেন্স এটিকে অন্তর্নির্মিত টানেল ধরনের তালিকায় রাখে। Linux-এ নেটিভ SSTP ক্লায়েন্ট একেবারেই নেই, তাই প্রশ্ন দাঁড়ায়, sstp-client প্যাকেজের sstpc-এর মতো আলাদা বাস্তবায়ন ইনস্টল ও হালনাগাদ আছে কি না।

লেবেলের আগে প্রোফাইল ফরম্যাট পড়ুন

প্রোফাইলগুলো বিনিময়যোগ্য নয়, আর আপনাকে দেওয়া ফাইলটি সাধারণত যে কোনও ফিচার তালিকার চেয়ে দ্রুত প্রশ্নটির মীমাংসা করে। OpenVPN নির্দেশিকা, WireGuard পিয়ার কী ও SSTP সংযোগ সেটিংস তিনটি সম্পর্কহীন প্রোটোকল বর্ণনা করে, এবং কোনও আমদানি ডায়ালগ একটি থেকে অন্যটি বানায় না। TCP 443 পোর্ট ভাগ করা কিছুই অনুবাদ করে না, কারণ SSTP, TLS-এর উপর OpenVPN এবং সাধারণ HTTPS সেবা একই পোর্ট দখল করতে পারে এবং তার উপরে কোনও মিল নেই।

ফাইলটি যদি .ovpn বা WireGuard কনফিগারেশন হয়, তবে উত্তর আগেই আছে: ওই ক্লায়েন্টকে SSTP-তে কথা বলতে বলা হচ্ছে না। কেবল SSTP-সমর্থক ক্লায়েন্টে এটি আমদানি করলে প্রোফাইল পর্যায়েই ব্যর্থ হয়, প্রোটোকল আলোচনা শুরুর বহু আগে।

TLS স্থাপনা সম্পর্কে যা প্রমাণ করে না

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

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

চারটি পর্যায়ে সেশনটি অনুসরণ করুন

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

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

সমর্থন না থাকলে পরিকল্পনা বদলান

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

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