SSTP نے پورٹ 443 لے لی: Apache کیوں شروع نہیں ہوتا

Apache اس دوپہر 443 پر جواب دینا بند کر دیتا ہے جب کوئی آنے والے VPN کنکشن فعال کرتا ہے، اور اس کا غلطی لاگ پیچھے کی بکنگ کے بجائے bind کو مورد الزام ٹھہراتا ہے۔ Windows Routing and Remote Access اسی لمحے SSTP فعال کرتا ہے، اور SSTP سننے والا کسی بھی کلائنٹ کی تصدیق سے پہلے HTTP اسٹیک کے ذریعے TCP 443 کا دعوی کرتا ہے۔ یہ دعوی اس وقت بھی برقرار رہتا ہے جب سرٹیفکیٹ نہ ہو، نام غلط ہو یا ہر handshake مسترد ہو، اس لیے جس VPN میں کوئی لاگ ان نہ کر سکے وہ بھی پورٹ پر قابض رہتا ہے۔ پہلے سننے کا جدول پڑھیں؛ 443 رکھنے والا PID فیصلہ کرتا ہے کہ نیچے دی گئی اصلاحات میں سے کون سی آپ کے لیے کھلی ہے۔

بکنگ ٹوٹے سرٹیفکیٹ سے زیادہ زندہ رہتی ہے

SSTP PPP کو TLS سیشن میں لپیٹتا ہے، اسی لیے اسے 443 چاہیے اور اسی لیے وہ ایسے پراکسی سے گزرتا ہے جو دوسری سرنگیں گرا دیتے ہیں۔ سننے والا وہ socket نہیں جو VPN سروس اپنے لیے کھولتی ہے: 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 کا مالک جان بوجھ کر چنیں اور انتخاب لکھ لیں، کیونکہ ورنہ کوئی خصوصیت فعال کرنے والا اگلا شخص یہ ٹکراؤ دوبارہ دریافت کرے گا۔ کردار الگ رکھنا ہی صاف جواب ہے: عوامی ویب سرور اور دور رسائی اینڈ پوائنٹ کے پیچ، سرٹیفکیٹ اور دوبارہ آغاز کے چکر الگ ہوتے ہیں، اور وہ چکر اپنے ہی شیڈول پر ملتے ہیں۔ کسی بھی صورت میں، سننے کی جانچ، رجسٹری راستہ اور چنا گیا پورٹ حوالگی نوٹ میں چھوڑ دیں۔