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 அனுமதிகள். ஒவ்வொன்றும் வெவ்வேறு பிழையை உருவாக்குகிறது, எதுவும் ஒரு வழி அல்லது ஃபயர்வால் விதியால் சரிசெய்யப்படுவதில்லை. சேவையை மீண்டும் தொடங்குவதற்குப் பதிலாக பிழை உரையை அச்சொட்டாகப் படியுங்கள்.
அந்த வரிசையில் நான்கு சரிபார்ப்புகளைச் செய்யுங்கள்: முனை, கேட்பான், மூல முகவரி, நம்பிக்கை, பொதுவாக வலையமைப்புச் சிக்கலுக்கு முன் பழைய பிணைப்பைக் கண்டுபிடிப்பீர்கள்.