SSTP হলো HTTPS-এর ওপর PPP, পোর্ট 443-এ কোনো ওয়েব পেজ নয়

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

চারটি ধাপ ক্রমানুসারে ধরে এগোন, আর তুমি যে ব্যর্থতা দেখছ তা তাদের একটিতেই পড়বে।

ধাপ 1: TCP ও TLS

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

একটি সাধারণ ওয়েব সার্ভার এই ধাপ নিখুঁতভাবে শেষ করে পরের ধাপে ব্যর্থ হতে পারে। TLS-এর সাফল্য সার্টিফিকেটের প্রমাণ, তার পেছনের প্রোটোকলের নয়।

ধাপ 2: HTTPS অনুরোধ

SSTP একটি নির্দিষ্ট মেথড, SSTP_DUPLEX_POST দিয়ে তার অনুরোধ করে এবং ডকুমেন্ট ফেরানোর বদলে বিনিময়টি খোলা রাখে। সাধারণ পেজ অনুরোধের জন্য কনফিগার করা সার্ভার বা প্রক্সি সংযোগটি গ্রহণ করে পরে মেথডটি প্রত্যাখ্যান করতে পারে। সেই প্রত্যাখ্যানই সেই সামঞ্জস্যের সমস্যা যা মানুষ সাধারণত পোর্ট 443 ব্লক হওয়া বলে বর্ণনা করে।

সার্ভার লগে রেসপন্স কোড ও মেথড পড়ো। এই ধাপে প্রত্যাখ্যান TCP টাইমআউট থেকে আলাদা সমস্যা, আর দুটো আলাদা সমাধানে নিয়ে যায়।

ধাপ 3: কন্ট্রোল বার্তা

অনুরোধ গৃহীত হলে SSTP এমন কন্ট্রোল বার্তা বিনিময় করে যা টানেল নিয়ে দরকষাকষি করে ও প্রস্তুত করে। এগুলো HTTP অনুরোধ নয়, HTTPS বডির ভেতরের প্রোটোকল বার্তা, তাই যে প্রক্সি বডি পরীক্ষা করে পুনর্লিখন করে সে পেজ অনুরোধ অক্ষত রেখেই এগুলো ভাঙতে পারে।

এখানেই ডিপ-ইনস্পেকশন মিডলবক্স তার সুনাম অর্জন করে। পেজ লোড হয় অথচ VPN ব্যর্থ হয়, তবে পোর্ট খোলা কিনা তা নয়, বরং বডি পরিবর্তন হচ্ছে কিনা তা দেখো।

ধাপ 4: PPP নিয়ন্ত্রণ নেয়

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

গৃহীত সার্টিফিকেট আর প্রত্যাখ্যাত লগইন পরস্পরবিরোধী নয়। এগুলো স্বাধীন ফলাফলসহ ধারাবাহিক ধাপ।

প্রমাণীকরণের কয়েকটি ভূমিকা আছে

ক্লায়েন্ট তার ট্রাস্ট স্টোর ও কনফিগার করা নামের বিপরীতে TLS সার্ভারের পরিচয় যাচাই করে। তারপর PPP ব্যবহারকারী বা মেশিনকে প্রমাণীকরণ করে, যা স্থাপনার ওপর নির্ভর করে। সার্ভার কে সংযোগ করতে পারবে ও কী পর্যন্ত পৌঁছাতে পারবে সে বিষয়ে নিজের নীতি যোগ করতে পারে। হোস্টনাম সার্টিফিকেট পরিচয়ের সঙ্গে সামঞ্জস্যপূর্ণ রাখো, কারণ কাঁচা ঠিকানা বসালে কাজ করা সেটআপ নাম-যাচাই ব্যর্থতায় পরিণত হয়।

কোন ধাপ ব্যর্থতা জানিয়েছে তা লিখে রাখো। সার্টিফিকেট, মেথড, কন্ট্রোল বার্তা, PPP প্রমাণীকরণ, তারপর রুট: পাঁচ জায়গা, পাঁচ সংশোধন।

ব্রাউজার পরীক্ষা কী দেখাতে পারে আর কী পারে না

ঠিকানায় একটি পেজ লোড করা DNS রিজলিউশন, TCP পৌঁছানোযোগ্যতা এবং HTTP বলা কিছু শ্রবণ করছে তা প্রমাণ করে। এটি প্রমাণ করে না যে মেথড গৃহীত হয়েছে, কন্ট্রোল বিনিময় টিকে আছে বা PPP প্রমাণীকরণ কনফিগার হয়েছে। পোর্ট বদলে অন্য প্রোফাইল রূপান্তরের বদলে SSTP বাস্তবায়ন করে এমন ক্লায়েন্ট ব্যবহার করো।

সেশন ওঠার পরেও রুট, DNS ও সার্ভার-পাশের ফরওয়ার্ডিং ঠিক করে ব্যবহারকারী কী পর্যন্ত পৌঁছাতে পারে। টানেল একটি পথ, কোনো অনুমোদন নয়।