SSTP টাইমআউট নাকি সার্টিফিকেট ত্রুটি: দুটির পার্থক্য কীভাবে বুঝবেন

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

দুই ব্যর্থতা, দুই ভিন্ন বিনিময়

SSTP একটি HTTPS-আকৃতির সেশনের ভেতরে টানেল বহন করে, তাই যে নেটওয়ার্ক কেবল 443 অনুমোদন করে সেখানেও এটি টিকে যায়। ক্লায়েন্ট TLS হ্যান্ডশেক শেষ করে, প্রোটোকল-নির্দিষ্ট পদ্ধতিতে একটি HTTP অনুরোধ পাঠায়, তারপর টানেলটি সেই স্ট্রিমের ভেতরে চলে। ওই ধাপগুলোর যেকোনোটিতে ব্যর্থতা সংযোগ থামায়, আর কেবল পরের ধাপগুলোতেই লগইন তথ্য জড়িত।

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

লগের লাইনটি সাধারণত বলে আপনি তিনটির কোনটিতে আছেন, তাই প্রথম পরিবর্তনের আগেই সেটি ধরে রাখা মূল্যবান।

টাইমআউট মানে একটি পর্যায় কখনো শেষ হয়নি

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

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

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

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

সার্টিফিকেট ত্রুটি মানে পরিচয় প্রত্যাখ্যাত হয়েছে

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

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

সফল TLS পর্যায়টি পাস করার পর অক্ষত রাখুন, কারণ পরে তা ফিরিয়ে নিলে কোন পরিবর্তন সত্যিই টানেল সারিয়েছে তা ঢেকে যায়।

দুটি কোথায় গুলিয়ে যায়

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

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

সার্টিফিকেটের প্রশ্ন ও পৌঁছানোযোগ্যতার প্রশ্ন আলাদাভাবে নথিভুক্ত করা হয়েছে কারণেই।

আসল ক্লায়েন্টে আবার পরীক্ষা করুন, তারপর ভেতরের দিকে যান

নির্দিষ্ট সংশোধনটি জায়গামতো বসে গেলে ব্রাউজার ট্যাব নয়, বাস্তব SSTP ক্লায়েন্ট ও আসল প্রোফাইল দিয়ে আবার চেষ্টা করুন।

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

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