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 अनुमति। ती प्रत्येकले फरक त्रुटि दिन्छ र कुनै पनि मार्ग वा फायरवाल नियमले सुधार्दैन। सेवा फेरि सुरु गर्नुको सट्टा त्रुटि पाठ शाब्दिक रूपमा पढ्नुहोस्।

ती क्रममा चार जाँच गर्नुहोस्: अन्त्यबिन्दु, श्रोता, स्रोत ठेगाना, विश्वास, र सामान्यतया नेटवर्क समस्याअघि पुरानो बाइन्डिङ भेटिन्छ।