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 അനുമതികൾ. അവ ഓരോന്നും വ്യത്യസ്ത പിശക് ഉണ്ടാക്കുന്നു, ഒന്നും ഒരു റൂട്ടോ ഫയർവാൾ നിയമമോ പരിഹരിക്കുന്നില്ല. സേവനം വീണ്ടും ആരംഭിക്കുന്നതിന് പകരം പിശക് പാഠം അക്ഷരാർത്ഥത്തിൽ വായിക്കുക.

ആ ക്രമത്തിൽ നാല് പരിശോധനകൾ ചെയ്യുക: എൻഡ്പോയിന്റ്, ലിസണർ, ഉറവിട വിലാസം, വിശ്വാസം, സാധാരണയായി നെറ്റ്വർക്ക് പ്രശ്നത്തിന് മുമ്പ് പഴയ ബൈൻഡിംഗ് കണ്ടെത്തും.