IIS Manager रिमोट एडमिन: पहले WMSVC का अपना पता जाँचें

आपकी साइट टनल के ज़रिए 443 पर जवाब देती है, और IIS Manager फिर भी सर्वर से कनेक्ट नहीं हो पाता। ये दोनों नतीजे विरोधाभास नहीं हैं, क्योंकि वेबसाइट और रिमोट एडमिनिस्ट्रेशन एंडपॉइंट दो अलग कॉन्फ़िगरेशन और दो अलग एक्सेस नियम-समूहों वाले दो श्रोता हैं। प्रबंधन वाला श्रोता वेब मैनेजमेंट सर्विस, यानी WMSVC का है, और उसका अपना पता, पोर्ट, प्रमाणपत्र और IPv4 प्रतिबंध हैं। किसी भी रूट को छूने से पहले वह एंडपॉइंट जाँचें।

दो श्रोता, दो अलग समस्याएँ

साइट के लिए आया अनुरोध उस साइट की HTTP.sys बाइंडिंग तक पहुँचता है, जो applicationHost कॉन्फ़िगरेशन में प्रति साइट और प्रति प्रोटोकॉल परिभाषित होती है। IIS Manager से आया अनुरोध WMSVC तक पहुँचता है, जो डिफ़ॉल्ट रूप से TCP 8172 पर HTTPS जवाब देता है और सर्वर स्तर पर कॉन्फ़िगर होता है। साइट की बाइंडिंग में कुछ भी यह नहीं बदलता कि WMSVC कहाँ सुनता है, और WMSVC में कुछ भी यह नहीं बदलता कि साइट किस पते पर जवाब देती है। वे एक मशीन और एक प्रमाणपत्र भंडार साझा करते हैं, और समानता वहीं खत्म होती है।

यानी एक सफल Test-NetConnection पोर्ट 443 पर बताता है कि साइट का श्रोता पहुँच योग्य है, और प्रबंधन के बारे में कुछ भी नहीं।

वह पता खोजें जिससे WMSVC वास्तव में बंधा है

सर्वर से पूछें कि वह अब किस पर सुन रहा है, न कि वर्षों पहले किस पर सुनने के लिए कॉन्फ़िगर किया गया था। Get-NetTCPConnection -LocalPort 8172 -State Listen स्थानीय पता छापता है, और 0.0.0.0 या :: का मान सभी पते दर्शाता है, जबकि कोई विशिष्ट पता केवल उसे ही दर्शाता है। अगर किसी सर्वर का एड्रेसिंग बदला गया है, तो सेवानिवृत्त पते पर अटका श्रोता ठीक वही खराबी है जिसे यह जाँच पकड़ती है।

कॉन्फ़िगर किया गया मान सर्वर नोड पर IIS Manager के Management Service पृष्ठ पर रहता है, और उसके पीछे administration.config में, inetsrv कॉन्फ़िगरेशन निर्देशिका के अंतर्गत। दोनों की तुलना करें: फ़ाइल क्या कहती है, और सॉकेट वास्तव में किससे बंधा है।

फिर प्रभावित VPN क्लाइंट से Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed चलाएँ और हल किया गया पता तथा चुना गया स्रोत पता पढ़ें। VPN पर अलग DNS उत्तर काफ़ी सामान्य है, इसलिए उसे जल्दी बाहर करना उचित है। टिकट में ठीक वही होस्टनाम और पोर्ट रखें, क्योंकि बाद में किसी दूसरे नाम से तुलना आपके किए बदलाव के बारे में कुछ साबित नहीं करती।

सर्वर जो स्रोत पता देखता है, उसे पढ़ें

WMSVC के IPv4 प्रतिबंध सर्वर तक पहुँचने वाले पते के आधार पर आँके जाते हैं, और यह हमेशा वह पता नहीं होता जो आपका लैपटॉप अपना मानता है। अगर VPN पूल रास्ते में कहीं अनुवादित होता है, तो सर्वर अनुवादित पता देखता है और क्लाइंट के भीतरी पते से बनी अनुमति सूची उसे अस्वीकार कर देगी। वह अस्वीकृति क्लाइंट की ओर से कनेक्शन विफलता जैसी दिखती है, इसीलिए उसे गलती से रूटिंग समस्या के रूप में निदान किया जाता है।

प्रतिबंध सूची संपादित करने से पहले यह देखने के लिए TCP परीक्षण का विस्तृत आउटपुट और सर्वर का अपना कनेक्शन तालिका इस्तेमाल करें कि कौन-सा स्रोत पता वास्तव में आया।

बाइंडिंग को सेवा-परिवर्तन की तरह बदलें

WMSVC का कॉन्फ़िगरेशन संपादित करने से पहले सेवा रोकनी पड़ती है, इसलिए इसे ऐसे बदलाव के रूप में योजना बनाएँ जिसमें प्रबंधन का दूसरा रास्ता उपलब्ध हो, जैसे कंसोल एक्सेस या IIS Manager पर निर्भर न रहने वाला रिमोट सत्र। सेवा रोकें, पते, पोर्ट या प्रमाणपत्र का बदलाव लागू करें, फिर उसे शुरू करें और पुष्टि करें कि श्रोता हट गया है। रिमोट IIS प्रशासन इस्तेमाल करने वाला हर दूसरा व्यक्ति उस अवधि में अपना सत्र खो देगा। अवधि खुलने से पहले दूसरे प्रशासकों को बताएँ; बदलाव के बीच में इसे खोजना ही दो लोगों के एक ही श्रोता को संपादित करने की स्थिति बनाता है।

सभी पते चुनना वैध विकल्प है, पर इसे शॉर्टकट नहीं, एक्सेस निर्णय मानिए। प्रतिबंध सूची खुली रहते हुए श्रोता को चौड़ा करना ही प्रबंधन एंडपॉइंट के ऐसे नेटवर्क पर खुल जाने का कारण बनता है जो किसी ने नहीं चाहा था। अगर सर्वर में कई नेटवर्क कार्ड हैं, तो श्रोता को प्रबंधन इंटरफ़ेस तक सीमित रखें, डेटा मार्ग को अछूता छोड़ें, और पुष्टि करें कि साइट अब भी अपने पते पर जवाब देती है।

WMSVC जो प्रमाणपत्र प्रस्तुत करता है वह साइट के प्रमाणपत्रों से अलग चुना जाता है। अगर आप पता बदलते हैं, तो पुष्टि करें कि प्रमाणपत्र अब भी क्लाइंट द्वारा इस्तेमाल होने वाले होस्टनाम से मेल खाता है, वरना कनेक्शन बाद में TLS चरण पर ऐसी शिकायत के साथ विफल होगा जिसका रूटिंग से कोई संबंध नहीं है।

पहुँच को भरोसे और अनुमतियों से अलग करें

TCP सफल होने के बाद बाकी विफलताएँ क्रम में हैं: प्रबंधन प्रमाणपत्र के लिए TLS भरोसा, फिर Windows प्रमाणीकरण, फिर उस खाते को दी गई IIS Manager अनुमतियाँ। इनमें से हर एक अलग त्रुटि देती है, और कोई भी रूट या फ़ायरवॉल नियम से ठीक नहीं होती। सेवा फिर से शुरू करने के बजाय त्रुटि का पाठ शब्दशः पढ़ें।

चारों जाँचें उसी क्रम में करें, एंडपॉइंट, श्रोता, स्रोत पता, भरोसा, और आम तौर पर नेटवर्क समस्या मिलने से पहले पुरानी बाइंडिंग मिल जाएगी।