ব্রাউজারের HTTPS যেখানে সফল, সেখানে SSTP ব্যর্থ: কেন
SSTP পোর্ট 443-এ TLS-এর ভেতরে চলে, কিন্তু এটি কোনো ওয়েব অনুরোধ নয়। TCP, TLS পরিচয়, SSTP বিনিময় ও PPP প্রমাণীকরণকে আলাদা ধাপ হিসেবে পরীক্ষা করুন।
ব্রাউজার VPN হোস্টনামটি HTTPS-এ কোনো অভিযোগ ছাড়াই খোলে, অথচ SSTP ক্লায়েন্ট সংযোগ করতে অস্বীকার করে। এই জোড়ায় কোনো বৈপরীত্য নেই। SSTP বাইরের পরিবহন হিসেবে TLS ব্যবহার করে, তারপর সেই সংযোগের ভেতরে নিজের অনুরোধ ও PPP পেলোড চালায়, তাই একটি পৃষ্ঠা সফলভাবে লোড হওয়া কেবল একটি সংকীর্ণ বিষয় প্রমাণ করে: হোস্টটি পোর্ট 443-এ একটি GET-এর উত্তর দেয়। ক্লায়েন্ট ভিন্ন প্রশ্ন করছে, আর সার্ভার হয়তো তার উত্তর খারাপভাবে দেবে।
পৃষ্ঠা লোড হয়, সুড়ঙ্গ হয় না
মানুষ ব্রাউজার পরীক্ষায় যায় কারণ এটি দ্রুত, তারপর ফলাফলটিকে সার্ভার পৌঁছানোযোগ্য ও কনফিগার করা হয়েছে এমন প্রমাণ ধরে নেয়। এটি অ্যাড্রেস বার যে পথ খুলেছে সেখানে একটি GET সম্পর্কে প্রমাণ, এর বেশি কিছু নয়। VPN আলাপ একই TLS হ্যান্ডশেকের পরে শুরু হয়, কিন্তু পাঠায় এমন একটি পদ্ধতি ও পথ যা কোনো ওয়েব পৃষ্ঠা কখনো ব্যবহার করে না। তাই ব্রাউজারের জন্য 200 উত্তরটি SSTP এন্ডপয়েন্ট বিদ্যমান কি না সে সম্পর্কে কিছুই বলে না।
দুটি পর্যবেক্ষণ আলাদা করুন, খোঁজ ছোট হয়ে যাবে। পরিবহন ও সার্টিফিকেট চেইন কাজ করে, কিন্তু তাদের উপরের প্রোটোকল বিনিময়ে কিছু কাজ করে না। এটি ভাঙা পোর্ট বা মেয়াদোত্তীর্ণ সার্টিফিকেটের চেয়ে ভিন্ন তদন্ত, এবং ভিন্ন প্রমাণ দরকার।
SSTP ক্লায়েন্ট আসলে কী পাঠায়
ক্লায়েন্ট /sra_{GUID}/ পথে SSTP_DUPLEX_POST পদ্ধতিতে একটি HTTP অনুরোধ পাঠায়, তারপর সংযোগের বডিটি PPP ফ্রেম বহনকারী দ্বিমুখী স্ট্রিম হিসেবে খোলা রাখে। একটি নিয়ম মানা সার্ভার HTTP/1.1 200 উত্তর দেয় এবং ওয়েব সার্ভারের মতো আচরণ বন্ধ করে। অন্য যেকোনো কিছু একটি স্বাক্ষর: 405 বা 404 মানে এন্ডপয়েন্ট নেই, 301 বা 302 মানে কিছু অনুরোধটি পুনর্নির্দেশ করছে, আর তাৎক্ষণিক FIN মানে কোনো প্রক্সি বা সার্ভার স্ট্রিমটি বন্ধ করেছে।
এই কারণেই লক্ষ্যটি TLS সার্টিফিকেট জোড়া লাগানো ওয়েব সার্ভার নয়, SSTP সার্ভার হতে হবে। পদ্ধতি, পথ ও দীর্ঘস্থায়ী বডি প্রোটোকলের প্রয়োজনীয়তা, তাই একটি রিভার্স প্রক্সি কেবল কনফিগারেশন দিয়ে সেগুলো যোগ করতে পারে না। যে প্রক্সি সাধারণ HTTPS নিখুঁতভাবে প্রেরণ করে, সেটিও এমন পদ্ধতি প্রত্যাখ্যান করতে পারে যা সে চেনে না।
কোথায় প্রক্সি বা ওয়েব সার্ভার স্ট্রিম ভাঙে
একটি মধ্যস্থতাকারী কিছু প্রেরণের আগে HTTP অনুরোধ লাইনটি পরীক্ষা করে, আর অস্বাভাবিক পথসহ কাস্টম পদ্ধতি তার নিয়মে ব্যর্থ হতে পারে। কিছু ডিভাইস সাধারণ পৃষ্ঠা পরিবেশন করে কিন্তু সুড়ঙ্গটি প্রত্যাখ্যান বা বিচ্ছিন্ন করে, তাই ক্লায়েন্ট পরিষ্কার প্রত্যাখ্যানের বদলে শুরু হয়ে মরে যাওয়া সংযোগের কথা জানায়। অন্যরা অনুরোধ গ্রহণ করে, তারপর বডি বা নিষ্ক্রিয়তার টাইমআউট প্রয়োগ করে যা PPP কিপঅ্যালাইভ টিকিয়ে রাখতে পারে না। ক্লায়েন্টের দিক থেকে দুটোই একই রকম দেখায়, তাই কোন ধাপটি ব্যর্থ হয়েছে সেটি ত্রুটির লেখার চেয়ে বেশি গুরুত্বপূর্ণ।
একটি ওয়েবসাইট ও SSTP-এর মধ্যে পোর্ট 443 ভাগ করা একটি রাউটিং সিদ্ধান্ত, প্রতিটি হপ দুটি আলাপ একইভাবে সামলাবে এমন প্রতিশ্রুতি নয়। পথে লোড ব্যালেন্সার, ফায়ারওয়াল বা TLS টার্মিনেটর থাকলে VPN কনফিগারেশন স্পর্শ করার আগে সেটিকে সন্দেহভাজন তালিকায় যোগ করুন।
ধাপগুলো আলাদাভাবে পরীক্ষা করুন
পরীক্ষাগুলো ক্রমে চালান এবং প্রথম ব্যর্থতায় থামুন, কারণ প্রতিটি ধাপ ভিন্ন স্তর বাদ দেয়। নিচের TLS প্রোবটি সার্টিফিকেট পরিচয়কে SSTP যা করে তার থেকে আলাদা করে। হোস্টনামের জায়গায় আপনার এন্ডপয়েন্ট দিন এবং এটি যে সাবজেক্ট ও চেইন ছাপে তা পড়ুন।
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comতারপর ক্লায়েন্ট ত্রুটি থেকে অনুমান না করে বাকি প্রমাণগুলো ধাপগুলোর সঙ্গে মিলিয়ে নিন। নিচের সারণিটি টিকিটে উদ্ধৃত করার চেকলিস্ট, যে স্বাক্ষর একটি ব্যর্থতাকে পরেরটি থেকে আলাদা করে।
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
টিকিটে "সংযোগ করা যাচ্ছে না" লেখার বদলে শেষ যে ধাপটি সফল হয়েছে তা লিখুন। MS-SSTP স্পেসিফিকেশন TLS হ্যান্ডশেকের পরে আসা অনুরোধ ও PPP বিনিময় নথিভুক্ত করে, এবং ব্রাউজার পরীক্ষা কেন কোনোটিরই বিকল্প হতে পারে না তার সূত্র এটি।
প্রথমে পরিচয়, তারপর PPP
TLS পরিচয় ও PPP প্রমাণীকরণ ধারাবাহিক, বিকল্প নয়, আর এদের গুলিয়ে ফেলা মানুষকে ভুল সার্ভার সেটিংয়ে পাঠায়। ক্লায়েন্ট প্রথমে সার্ভার সার্টিফিকেট ও এর উদ্দিষ্ট ব্যবহার যাচাই করে, তারপর PPP নিজের অবস্থা নিয়ে দরকষাকষি করে এবং চ্যালেঞ্জ-রেসপন্স পদ্ধতি বা EAP দিয়ে ব্যবহারকারীকে প্রমাণীকরণ করে। সার্টিফিকেট সমস্যা প্রত্যাখ্যাত পাসওয়ার্ডের চেয়ে ভিন্ন ত্রুটি দেয়, আর কোনো ত্রুটিই অন্যটি যে ধাপ ঢাকে তা বর্ণনা করে না।
হোস্টনামের বদলে ঠিকানা ব্যবহার করা, বা সার্টিফিকেট সতর্কবার্তা পেরিয়ে ক্লিক করা, ব্যর্থ ধাপটি শনাক্ত করত এমন পরীক্ষাটি সরিয়ে ফেলে, সেটি সারায় না। সতর্কবার্তাটি রাখুন এবং পড়ুন। HTTP বিনিময় যখন কখনোই SSTP আচরণে পৌঁছায়নি তখন PPP পাসওয়ার্ড রিসেট করবেন না, কারণ শংসাপত্র কখনো চাওয়া হয়নি।