SSTP পোর্ট 443 দখল করে নিল: Apache কেন চালু হয় না
ব্যর্থ সাইটটি 443 ধরে রাখা সাইট নয়। Windows SSTP HTTP স্ট্যাকের মাধ্যমে পোর্ট সংরক্ষণ করে: লিসেনার সরান, তার সামনে IIS বসান, বা সাইট সরান।
কেউ ইনকামিং VPN সংযোগ চালু করার সেই দুপুরে Apache 443-এ উত্তর দেওয়া বন্ধ করে, আর তার ত্রুটি লগ পেছনের সংরক্ষণের বদলে bind-কে দোষ দেয়। Windows Routing and Remote Access সেই মুহূর্তে SSTP চালু করে, এবং SSTP লিসেনার কোনো ক্লায়েন্ট প্রমাণিত হওয়ার আগেই HTTP স্ট্যাকের মাধ্যমে TCP 443 দাবি করে। সনদ না থাকলেও, নাম ভুল হলেও বা প্রতিটি handshake প্রত্যাখ্যাত হলেও দাবিটি বহাল থাকে, তাই যে VPN-এ কেউ লগইন করতে পারে না সেটিও পোর্ট দখল করে থাকে। আগে শোনার সারণি পড়ুন; 443 ধরে রাখা PID-ই ঠিক করে নিচের কোন সমাধান আপনার জন্য খোলা।
সংরক্ষণ ভাঙা সনদের চেয়ে দীর্ঘজীবী
SSTP PPP-কে একটি TLS সেশনে মোড়ে, তাই এর 443 দরকার এবং তাই এটি অন্য টানেল ফেলে দেওয়া প্রক্সির মধ্য দিয়ে যায়। লিসেনার VPN সেবা নিজের জন্য খোলে এমন socket নয়: SstpSvc এটিকে কার্নেলের HTTP ড্রাইভারে নিবন্ধন করে, তাই সেবা চলার যতক্ষণ পোর্ট সংরক্ষিত থাকে। সেই নিবন্ধন কখনো সনদকে জিজ্ঞাসা করে না, অর্থাৎ মেয়াদোত্তীর্ণ নাম, অসঙ্গত subject বা সনদ একেবারেই না থাকা 443-কে দখলকৃতই রাখে। এরপর ব্যর্থতা দুই দিকে ভাগ হয়: প্রত্যাখ্যাত handshake RasSstp-এর অধীনে System লগে যায়, আর ওয়েব সার্ভার কেবল জানাতে পারে যে সে bind করতে পারেনি।
netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"
প্রথম লাইন মালিক PID ফেরত দেয়; দ্বিতীয়টি তার পেছনের সেবার নাম বলে, এবং উত্তর সাধারণত HTTP সেবা বা RRAS স্ট্যাক। যখন tasklist কোনো ভাগ করা হোস্ট প্রসেস দিয়ে উত্তর দেয়, প্রসেসের নাম থেকে অনুমান না করে সেবা কলামটি পড়ুন।
RasSstp সতর্কবার্তা এরপরেই পড়ার যোগ্য, কারণ সেগুলো ব্যর্থ handshake বর্ণনা করে এবং সংঘর্ষ ঘটানো সংরক্ষণ সম্পর্কে কিছুই বলে না। প্রতিটি ক্লায়েন্ট প্রত্যাখ্যান করা VPN এন্ডপয়েন্টও পোর্ট ধরে রাখে। লগকে প্রথম নয়, দ্বিতীয় প্রশ্ন হিসেবে দেখুন।
IIS ড্রাইভার ভাগ করে, Apache socket খোলে
IIS তার bindings SSTP যে কার্নেল ড্রাইভার ব্যবহার করে তারই কাছে দেয়, এবং সেই ড্রাইভার আগত সংযোগগুলোকে হোস্ট নাম ও URL উপসর্গ অনুযায়ী আলাদা করে, তাই দুই সেবাকেই 443 চাওয়ার কথা বলা যায় এবং কোনোটিই ব্যর্থ হয় না। Apache ও nginx উল্টো করে: তারা নিজেদের socket-এ bind ডাকে, আর ঠিকানা আগেই দখল করা থাকায় অপারেটিং সিস্টেম অস্বীকার করে। দুই কনফিগারেশনেই কিছুই ভুল নেই; পার্থক্য কোন API পোর্টটি ধরে আছে তাতে। এজন্যই VPN চালু করলে একটি হোস্টের একটি সাইট পড়ে যায় আর অন্য হোস্টের একই সাইট অক্ষত থাকে।
এই অসামঞ্জস্যই মেরামতের আকার নির্ধারণ করে। IIS যদি আগেই সামনের দরজা হয়, সংঘর্ষ উপসর্গ, bindings ও সনদের প্রশ্ন হয়ে ওঠে। Apache সামনের দরজা হলে হয় সে 443 থেকে সরে যায়, নয় SSTP লিসেনার সরে যায়, আর পরের অংশ দুই পদক্ষেপই কভার করে।
কোন সেবা 443 ধরে রাখবে তা বাছুন
লিসেনারের পোর্ট একটি রেজিস্ট্রি মানেই থাকে, Sstpsvc প্যারামিটার কী-এর অধীনে দশমিক DWORD। মান বদলান, Routing and Remote Access পুনরায় চালু করুন, এবং শোনার সারণি থেকে নিশ্চিত করুন যে পুরোনো পোর্ট খালি।
reg query "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort /t REG_DWORD /d 4443 /f
Restart-Service RemoteAccess
হোস্টে অন্য কারও অপ্রয়োজনীয় একটি পোর্ট বাছুন, এবং তা দশমিকে লিখুন: reg add DWORD-টি লেখা অনুযায়ীই সংরক্ষণ করে, তাই ষোড়শিক ভাবা মান অন্য পোর্ট হিসেবে নেমে আসে। যদি জিজ্ঞাসা বলে মানটি নেই, দ্বিতীয় লাইন সেটি তৈরি করে। Restart-Service RemoteAccess সংযুক্ত সবাইকে বের করে দেয়, যা পরিকল্পনা করার যোগ্য। এরপর শোনার পরীক্ষা আবার চালান, কারণ 443-এ পুরোনো এন্ট্রি মানে সেবা তার পুরোনো নিবন্ধন রেখেছে।
লিসেনার সরানোর একটি দাম আছে যা রেজিস্ট্রি সম্পাদনা দেখায় না। সাধারণ SSTP ক্লায়েন্ট 443 ডায়াল করে, তাই প্রতিটি ক্লায়েন্ট প্রোফাইলের নতুন পোর্ট দরকার, আর পথ পরীক্ষা করা যেকোনো কিছুর কাছে প্রবাহ আর ওয়েব অনুরোধের মতো লাগে না। যে নেটওয়ার্ক কেবল HTTPS-এর মতো ট্রাফিক সহ্য করে, সেখানে এটি SSTP বেছে নেওয়ার বেশিরভাগ কারণ সরিয়ে দেয়। ছোট, পরিচালিত ক্লায়েন্ট জনসংখ্যা এটি হজম করে; সাধারণ বা BYOD ব্যবহারকারী ভিত্তি নয়।
অন্য পদক্ষেপটি 443 IIS-এর কাছে রাখে এবং Apache-কে এমন backend ভাবে যেখানে প্রক্সি এগিয়ে পাঠায়। এটি SSTP-এর ডিফল্ট রক্ষা করে এবং পোর্টের জন্য এক মালিক রাখে, তবে এগিয়ে পাঠানো হেডার, অ্যাপ্লিকেশন আর সরাসরি না-দেখা ক্লায়েন্ট ঠিকানা এবং প্রক্সি সত্যিই যে প্রোটোকল পাঠায় তা বলতে হওয়া backend-এর দামে।
মালিক, সনদ ও handshake ক্রমে প্রমাণ করুন
সম্পূর্ণ TCP সংযোগ কেবল প্রমাণ করে যে লিসেনার আছে, তার বেশি কিছু নয়, তাই টানেল এখনো ব্যর্থ হলেও পোর্ট স্ক্যান সুস্থ দেখাতে পারে। চারটি ধাপ ভিন্নভাবে ব্যর্থ হয়, আর আপনি যে ধাপ ভাঙেননি তাতে লক্ষ্য করা মেরামত সাধারণত সংঘর্ষ গভীর করে। ক্রমে এগুলো করুন এবং উত্তর যেখানে ভাগ হয় সেখানে থামুন।
netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20
প্রথম লাইন 443 ধরে রাখা PID-এর নাম বলে, এবং তা আপনার এইমাত্র কনফিগার করা সেবা হওয়া উচিত। দ্বিতীয়টি মেশিন সনদ তাদের subjects সহ তালিকাভুক্ত করে, তাই ক্লায়েন্ট প্রোফাইলের ঠিকানার সঙ্গে না-মেলা নাম সঙ্গে সঙ্গে চোখে পড়ে। ঘটনা জিজ্ঞাসা সাম্প্রতিক SSTP রেকর্ড ফেরত দেয়, আর যে handshake কখনো PPP প্রমাণীকরণে পৌঁছায় না তা প্রমাণিত হয়ে পরে প্রত্যাখ্যাত হওয়ার চেয়ে আলাদা রেকর্ড রেখে যায়। শেষ ধাপ কেবল ক্লায়েন্টে দেখা যায়, যেখানে এন্ট্রি হয় সংযুক্ত জানায় নয় PPP ত্রুটির নাম বলে।
একই হোস্টকে দুই কাজই করতে হলে 443-এর মালিক সচেতনভাবে বাছুন এবং পছন্দ লিখে রাখুন, নাহলে কোনো বৈশিষ্ট্য চালু করা পরের ব্যক্তি এই সংঘর্ষ আবার আবিষ্কার করবে। ভূমিকা আলাদা রাখাই নির্মল উত্তর: সাধারণ ওয়েব সার্ভার ও দূরবর্তী প্রবেশ এন্ডপয়েন্টের প্যাচ, সনদ ও পুনরায় চালুর চক্র আলাদা, এবং সেই চক্রগুলো নিজেদের সময়সূচি অনুযায়ী মেলে। যেভাবেই হোক, শোনার পরীক্ষা, রেজিস্ট্রি পথ ও বাছাই করা পোর্ট হস্তান্তর নোটে রেখে দিন।