IIS Manager दूरस्थ प्रशासन: आधी WMSVC चा स्वतःचा पत्ता तपासा
WMSVC तुमच्या साइटवर नाही, तर स्वतःच्या HTTPS बाइंडिंगवर ऐकतो. VPN मार्गाला दोष देण्यापूर्वी तो एंडपॉइंट, त्याचे IP निर्बंध आणि प्रमाणपत्र यांची तुलना करा.
तुमची साइट टनेलमधून 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 परवानग्या। त्यांच्यापैकी प्रत्येक वेगळी त्रुटी देतो आणि त्यापैकी कोणतीही मार्ग किंवा फायरवॉल नियमाने सुटत नाही। सेवा पुन्हा सुरू करण्याऐवजी त्रुटीचा मजकूर अक्षरशः वाचा।
त्या क्रमाने चार तपासण्या करा: एंडपॉइंट, श्रोता, स्रोत पत्ता, विश्वास, आणि सहसा नेटवर्क समस्येपूर्वी जुने बाइंडिंग सापडते।