SSTP আগে সার্ভার যাচাই করে, পরে ব্যবহারকারীকে

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

বিশ্বস্ত সার্টিফিকেট প্রান্তবিন্দুকে প্রমাণ করে; অ্যাকাউন্ট সম্পর্কে এটি কিছুই বলে না।

TLS হ্যান্ডশেক কী প্রতিষ্ঠা করে

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

তাই লগইন প্রম্পটে পৌঁছাতে সার্টিফিকেট যাচাই সরানো ভুল সমাধান। আপনি এমন সংযোগে লগইন প্রম্পট পান যা যাচাই করতে পারেন না। সার্টিফিকেট ত্রুটি হোস্টনাম, ঘড়ি, চেইন বা ট্রাস্ট কনফিগারেশনের বিষয়।

SSTP ও PPP এর উপরে কী যোগ করে

SSTP HTTPS-এর উপর চলে এবং ভিতরে PPP বহন করে, সংযোগের চারপাশে নিজস্ব নিয়ন্ত্রণ বিনিময়সহ। এরপর PPP তার লিংক ও প্রমাণীকরণ পর্যায় চালায়, এবং প্রমাণীকরণ পদ্ধতি নির্ভর করে সার্ভারের নীতি ও ক্লায়েন্টের সামর্থ্যের উপর। PAP, CHAP, MS-CHAPv2 ও EAP সবই খুব ভিন্ন বৈশিষ্ট্যযুক্ত PPP প্রমাণীকরণ বিকল্প। VPN-এর ব্যবহারকারী যাচাই ওই PPP পর্যায়, নিচের TLS স্তর নয়।

তাই ব্যবহারকারী প্রত্যাখ্যান মানে শংসাপত্র, অ্যাকাউন্ট সীমাবদ্ধতা বা পদ্ধতির অমিল হতে পারে।

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

ত্রুটিকে স্তরের সঙ্গে মেলান

সংযোগটি TLS-এ পৌঁছায় কি না, তারপর SSTP HTTP বিনিময়, তারপর PPP পর্যায় দেখুন। পুনরায় চেষ্টার মধ্যে লগের টাইমস্ট্যাম্প সারিবদ্ধ রাখুন যাতে আগের ব্যর্থতা পরের সাফল্যের সঙ্গে গুলিয়ে না যায়। যে ক্লায়েন্ট এক উইন্ডোতে দুটি চেষ্টা লগ করে, সে অন্যথায় শেষ যে স্তরে পৌঁছেছে সেখানেই ব্যর্থ দেখাবে। শেষ লাইন নয়, প্রথম প্রাসঙ্গিক ত্রুটি পড়ুন।

একই সারিবদ্ধতা সার্ভার-পক্ষেও গুরুত্বপূর্ণ, যেখানে প্রমাণীকরণ রেকর্ড ও পরিবহন লগ প্রায়ই আলাদা ঘড়ির আলাদা ফাইল। দুই মিনিটের ব্যবধানই স্পষ্ট কারণকে অসম্ভব দেখাতে যথেষ্ট।

লগইনের পরে অনুমোদন এখনও আলাদা

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

এটি হ্যান্ডশেক যে একই স্তরবিন্যাস দেখিয়েছিল, এক স্তর উপরে।

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