IIS Manager دور سے: پہلے خود WMSVC کا پتہ دیکھیں

آپ کی سائٹ سرنگ کے ذریعے 443 پر جواب دیتی ہے، اور IIS Manager پھر بھی سرور سے جڑ نہیں سکتا۔ یہ دونوں نتائج تضاد نہیں ہیں، کیونکہ ویب سائٹ اور ریموٹ انتظامی اینڈ پوائنٹ دو مختلف کنفیگریشنوں اور دو مختلف رسائی قواعد کے مجموعوں والے دو سننے والے ہیں۔ انتظامی والا Web Management Service، WMSVC کا ہے اور اس کا اپنا پتہ، پورٹ، سرٹیفکیٹ اور IPv4 پابندیاں ہیں۔ ایک بھی راستے کو چھونے سے پہلے وہ اینڈ پوائنٹ دیکھیں۔

دو سننے والے، دو مختلف مسائل

سائٹ کی طرف درخواست اس سائٹ کی HTTP.sys بائنڈنگ تک پہنچتی ہے، جو applicationHost کنفیگریشن میں ہر سائٹ اور پروٹوکول کے حساب سے متعین ہوتی ہے۔ IIS Manager سے درخواست WMSVC تک پہنچتی ہے، جو بطور طے شدہ TCP 8172 پر HTTPS کا جواب دیتا ہے اور سرور کی سطح پر کنفیگر ہوتا ہے۔ سائٹ کی بائنڈنگ میں کچھ بھی یہ نہیں بدلتا کہ WMSVC کہاں سنتا ہے، اور WMSVC میں کچھ بھی یہ نہیں بدلتا کہ سائٹ کس پتے پر جواب دیتی ہے۔ وہ ایک مشین اور ایک سرٹیفکیٹ اسٹور بانٹتے ہیں، اور مشابہت وہیں ختم ہو جاتی ہے۔

لہٰذا پورٹ 443 پر کامیاب Test-NetConnection بتاتا ہے کہ سائٹ کا سننے والا قابل رسائی ہے، اور انتظام کے بارے میں کچھ نہیں بتاتا۔

وہ پتہ تلاش کریں جس سے WMSVC واقعی جڑا ہوا ہے

سرور سے پوچھیں کہ اب کیا سن رہا ہے، نہ کہ کئی سال پہلے کیا کنفیگر کیا گیا تھا۔ Get-NetTCPConnection -LocalPort 8172 -State Listen مقامی پتہ چھاپتا ہے، اور 0.0.0.0 یا :: کی قدر کا مطلب تمام پتے ہیں، جبکہ مخصوص پتہ صرف وہی۔ اگر سرور کے پتے بدل گئے ہوں تو ریٹائر شدہ پتے سے اب بھی جڑا سننے والا بالکل وہی خرابی ہے جو یہ جانچ پکڑتی ہے۔

کنفیگر کی گئی قدر سرور نوڈ پر IIS Manager کے Management Service صفحے پر ہے، اور اس کے پیچھے inetsrv کنفیگریشن ڈائریکٹری میں administration.config میں۔ دونوں کا موازنہ کریں: فائل کیا کہتی ہے، اور ساکٹ واقعی کس سے جڑا ہے۔

پھر متاثرہ VPN کلائنٹ سے Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed چلائیں اور حل شدہ پتہ اور منتخب شدہ ماخذ پتہ پڑھیں۔ VPN پر مختلف DNS جواب عام ہے، اس لیے اسے جلدی خارج کرنا بہتر ہے۔ ٹکٹ میں وہی درست ہوسٹ نام اور پورٹ رکھیں، کیونکہ بعد میں کسی دوسرے نام سے موازنہ آپ کی کی گئی تبدیلی کا کچھ ثابت نہیں کرتا۔

سرور جو ماخذ پتہ دیکھتا ہے وہ پڑھیں

WMSVC کی IPv4 پابندیاں سرور تک پہنچنے والے پتے پر لاگو ہوتی ہیں، جو ہمیشہ وہ پتہ نہیں ہوتا جو آپ کا لیپ ٹاپ اپنے پاس سمجھتا ہے۔ اگر راستے میں کہیں VPN پول کا ترجمہ ہو جائے تو سرور ترجمہ شدہ پتہ دیکھتا ہے اور کلائنٹ کے اندرونی پتے سے بنی اجازت فہرست اسے مسترد کر دے گی۔ یہ انکار کلائنٹ کی طرف سے کنکشن کی ناکامی جیسا لگتا ہے، اسی لیے اسے اکثر روٹنگ کا مسئلہ سمجھ کر غلط تشخیص کیا جاتا ہے۔

پابندی کی فہرست میں ترمیم سے پہلے یہ دیکھنے کے لیے کہ کون سا ماخذ پتہ واقعی پہنچا، TCP ٹیسٹ کی تفصیلی آؤٹ پٹ اور سرور کی اپنی کنکشن جدول استعمال کریں۔

بائنڈنگ کو سروس کی تبدیلی کے طور پر بدلیں

WMSVC کو اس کی کنفیگریشن میں ترمیم سے پہلے روکنا ضروری ہے، اس لیے اسے کنسول رسائی یا IIS Manager پر منحصر نہ ہونے والے ریموٹ سیشن جیسے دوسرے دستیاب انتظامی راستے والی تبدیلی کے طور پر منصوبہ بنائیں۔ سروس روکیں، پتہ، پورٹ یا سرٹیفکیٹ کی تبدیلی لاگو کریں، پھر اسے دوبارہ شروع کریں اور تصدیق کریں کہ سننے والا ہٹ گیا ہے۔ اس دورانیے میں ریموٹ IIS انتظام استعمال کرنے والا ہر دوسرا شخص اپنا سیشن کھو دیتا ہے۔ دورانیہ کھلنے سے پہلے دوسرے منتظمین کو بتائیں؛ تبدیلی کے بیچ میں یہ معلوم ہونا ہی وہ طریقہ ہے جس سے دو لوگ ایک ہی سننے والے میں ترمیم کرنے لگتے ہیں۔

تمام پتے منتخب کرنا جائز آپشن ہے، لیکن اسے شارٹ کٹ نہیں بلکہ رسائی کا فیصلہ سمجھیں۔ پابندی کی فہرست کھلی رہنے کے دوران سننے والے کو وسیع کرنا ہی وہ طریقہ ہے جس سے انتظامی اینڈ پوائنٹ ایسے نیٹ ورک پر بے نقاب ہو جاتا ہے جس کا کسی نے ارادہ نہیں کیا۔ اگر سرور میں کئی NIC ہیں تو سننے والے کو انتظامی انٹرفیس تک محدود کریں، ڈیٹا راستے کو چھیڑیں نہیں، اور تصدیق کریں کہ سائٹ اب بھی اپنے پتے پر جواب دیتی ہے۔

WMSVC جو سرٹیفکیٹ پیش کرتا ہے وہ سائٹ کے سرٹیفکیٹوں سے الگ منتخب ہوتا ہے۔ اگر پتہ بدلیں تو تصدیق کریں کہ سرٹیفکیٹ اب بھی وہی ہوسٹ نام رکھتا ہے جو کلائنٹ استعمال کرتے ہیں، ورنہ کنکشن بعد میں TLS مرحلے پر روٹنگ سے بے تعلق شکایت کے ساتھ ناکام ہو گا۔

قابل رسائی ہونے کو اعتماد اور اجازتوں سے الگ کریں

جب TCP کامیاب ہو جائے تو باقی ناکامیاں ترتیب میں ہوتی ہیں: انتظامی سرٹیفکیٹ کے لیے TLS اعتماد، پھر Windows توثیق، پھر اس اکاؤنٹ کو دی گئی IIS Manager اجازتیں۔ ان میں سے ہر ایک مختلف غلطی پیدا کرتا ہے، اور کوئی بھی راستے یا فائر وال قاعدے سے درست نہیں ہوتا۔ سروس دوبارہ شروع کرنے کے بجائے غلطی کا متن لفظی پڑھیں۔

انہی چار جانچوں کو اسی ترتیب سے کریں: اینڈ پوائنٹ، سننے والا، ماخذ پتہ، اعتماد، اور عام طور پر نیٹ ورک مسئلے سے پہلے پرانی بائنڈنگ مل جاتی ہے۔