IIS Manager kwa mbali: kagua kwanza anwani ya WMSVC yenyewe

Tovuti yako hujibu kwenye 443 kupitia handaki, na IIS Manager bado haiwezi kuunganishwa na seva. Jozi hii ya matokeo si ukinzani, kwa sababu tovuti na kiishio cha usimamizi wa mbali ni wasikilizaji wawili wenye usanidi mbili na seti mbili za kanuni za ufikiaji. Ya usimamizi ni ya Web Management Service, WMSVC, na ina anwani, mlango, cheti na vizuizi vyake vya IPv4. Kagua kiishio hicho kabla ya kugusa hata njia moja.

Wasikilizaji wawili, matatizo mawili tofauti

Ombi kwa tovuti hufikia kiunganishi cha HTTP.sys cha tovuti hiyo, ambacho hufafanuliwa kwa kila tovuti na kila itifaki katika usanidi wa applicationHost. Ombi kutoka IIS Manager hufikia WMSVC, ambayo kwa chaguo-msingi hujibu HTTPS kwenye TCP 8172 na husanidiwa katika ngazi ya seva. Hakuna chochote kwenye kiunganishi cha tovuti kinachobadilisha mahali WMSVC inasikiliza, na hakuna chochote kwenye WMSVC kinabadilisha anwani ambayo tovuti inajibu. Wanashiriki mashine moja na hifadhi moja ya vyeti, na hapo kufanana huisha.

Kwa hiyo Test-NetConnection iliyofanikiwa kwa mlango 443 inasema kuwa msikilizaji wa tovuti anafikika, na hakuna lolote kuhusu usimamizi.

Pata anwani ambayo WMSVC imefungwa nayo kwa kweli

Uliza seva inasikiliza nini sasa, si kile kilichosanidiwa miaka iliyopita. Get-NetTCPConnection -LocalPort 8172 -State Listen huchapisha anwani ya ndani, na thamani ya 0.0.0.0 au :: inamaanisha anwani zote, wakati anwani maalum inamaanisha hiyo pekee. Ikiwa anwani za seva zimebadilishwa, msikilizaji ambaye bado amefungwa kwenye anwani iliyoachwa ni hasa hitilafu ambayo ukaguzi huu unakamata.

Thamani iliyosanidiwa iko kwenye ukurasa wa Management Service wa IIS Manager kwenye nodi ya seva, na nyuma yake katika administration.config katika saraka ya usanidi ya inetsrv. Linganisha zote mbili: kile faili inasema, na kile soketi imefungwa nacho kwa kweli.

Kisha endesha Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed kutoka kwa mteja wa VPN aliyeathirika na usome anwani iliyotatuliwa na anwani ya chanzo iliyochaguliwa. Jibu tofauti la DNS kwenye VPN ni la kawaida vya kutosha kuondolewa mapema. Weka jina kamili la mwenyeji na mlango kwenye tiketi, kwa sababu ulinganisho wa baadaye na jina lingine hauthibitishi chochote kuhusu mabadiliko uliyofanya.

Soma anwani ya chanzo ambayo seva inaona

Vizuizi vya IPv4 vya WMSVC hutathminiwa dhidi ya anwani inayofika kwenye seva, ambayo si kila mara anwani ambayo kompyuta yako inadhani inayo. Ikiwa bwawa la VPN linatafsiriwa mahali fulani njiani, seva inaona anwani iliyotafsiriwa na orodha ya kuruhusiwa iliyojengwa kutoka anwani ya ndani ya mteja itaikataa. Kukataa huko kwa upande wa mteja kunaonekana kama kushindwa kwa muunganisho, ndiyo sababu mara nyingi hutambuliwa vibaya kama tatizo la uelekezaji.

Tumia matokeo ya kina ya jaribio la TCP, pamoja na jedwali la muunganisho la seva yenyewe, kuona ni anwani gani ya chanzo ilifika kwa kweli kabla ya kuhariri orodha ya vizuizi.

Badilisha kiunganishi kama mabadiliko ya huduma

WMSVC lazima isimamishwe kabla ya usanidi wake kuhaririwa, kwa hiyo panga kama mabadiliko yenye njia nyingine ya usimamizi inayopatikana, kama ufikiaji wa konsoli au kipindi cha mbali kisichotegemea IIS Manager. Simamisha huduma, tumia mabadiliko ya anwani, mlango au cheti, kisha iwashe tena na uthibitisho kwamba msikilizaji alihama. Mtu mwingine yeyote anayetumia usimamizi wa IIS wa mbali hupoteza kipindi chake katika muda huo. Waambie wasimamizi wengine kabla dirisha halijafunguliwa; kuigundua katikati ya mabadiliko ndiyo njia ambayo watu wawili huishia kuhariri msikilizaji mmoja.

Kuchagua anwani zote ni chaguo halali, lakini chukulia kama uamuzi wa ufikiaji na si njia ya mkato. Kupanua msikilizaji wakati orodha ya vizuizi inabaki wazi ndiyo njia ambayo kiishio cha usimamizi huishia kufichuliwa kwenye mtandao ambao hakuna aliyekusudia. Ikiwa seva ina NIC kadhaa, weka kikomo msikilizaji kwenye kiolesura cha usimamizi, acha njia ya data, na uthibitisho kwamba tovuti bado inajibu kwenye anwani yake.

Cheti ambacho WMSVC inawasilisha huchaguliwa tofauti na vyeti vya tovuti. Ukibadilisha anwani, uthibitisho kwamba cheti bado kinalingana na jina la mwenyeji wanaotumia wateja, vinginevyo muunganisho utashindwa baadaye kwenye hatua ya TLS na malalamiko yasiyohusiana na uelekezaji.

Tenganisha ufikikaji na uaminifu na ruhusa

Mara TCP inafanikiwa, kushindwa kunaobaki kuna mpangilio: uaminifu wa TLS kwa cheti cha usimamizi, kisha uthibitishaji wa Windows, kisha ruhusa za IIS Manager zilizotolewa kwa akaunti hiyo. Kila moja hutoa hitilafu tofauti, na hakuna inayorekebishwa na njia au kanuni ya firewall. Soma maandishi ya hitilafu kwa maana halisi badala ya kuwasha huduma tena.

Fanya ukaguzi nne kwa mpangilio huo, kiishio, msikilizaji, anwani ya chanzo, uaminifu, na kwa kawaida utapata kiunganishi kilichopitwa na wakati kabla ya kupata tatizo la mtandao.