IIS Manager nuotolinis valdymas: pirmiausia patikrinkite patį WMSVC adresą

Jūsų svetainė atsako 443 per tunelį, o IIS Manager vis tiek negali prisijungti prie serverio. Ši rezultatų pora nėra prieštaravimas, nes svetainė ir nuotolinio administravimo galinis taškas yra du klausytojai su dviem konfigūracijomis ir dviem prieigos taisyklių rinkiniais. Valdymo klausytojas priklauso Web Management Service, WMSVC, ir turi savo adresą, prievadą, sertifikatą bei IPv4 apribojimus. Patikrinkite tą galinį tašką prieš liesdami bent vieną maršrutą.

Du klausytojai, dvi skirtingos problemos

Užklausa į svetainę pasiekia tos svetainės HTTP.sys susiejimą, kuris apibrėžiamas pagal svetainę ir protokolą applicationHost konfigūracijoje. Užklausa iš IIS Manager pasiekia WMSVC, kuris pagal nutylėjimą atsako HTTPS TCP 8172 prievadu ir konfigūruojamas serverio lygmeniu. Niekas svetainės susiejime nekeičia, kur WMSVC klausosi, ir niekas WMSVC nekeičia, kokiu adresu atsako svetainė. Jie dalijasi mašina ir sertifikatų saugykla, ir ten panašumas baigiasi.

Taigi sėkmingas Test-NetConnection prievadui 443 pasako, kad svetainės klausytojas pasiekiamas, ir nieko nepasako apie valdymą.

Raskite adresą, prie kurio WMSVC iš tikrųjų prijungtas

Paklauskite serverio, ko jis klausosi dabar, o ne kas buvo sukonfigūruota prieš metus. Get-NetTCPConnection -LocalPort 8172 -State Listen išspausdina vietinį adresą, o reikšmė 0.0.0.0 arba :: reiškia visus adresus, o konkretus adresas – tik jį. Jei serverio adresai buvo pakeisti, klausytojas, vis dar pririštas prie nebenaudojamo adreso, yra būtent ta gedimo priežastis, kurią šis patikrinimas pagauna.

Sukonfigūruota reikšmė yra IIS Manager Management Service puslapyje serverio mazge, o už jo – administration.config inetsrv konfigūracijos kataloge. Palyginkite abu: ką sako failas ir prie ko lizdas iš tikrųjų prijungtas.

Tada paleiskite Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed iš paveikto VPN kliento ir perskaitykite išspręstą adresą bei pasirinktą šaltinio adresą. Skirtingas DNS atsakymas VPN tinkle yra pakankamai dažnas, kad vertėtų jį atmesti anksti. Įrašykite į bilietą tą tikslų mazgo vardą ir prievadą, nes vėlesnis palyginimas su kitu vardu nieko neįrodo apie jūsų atliktą pakeitimą.

Perskaitykite šaltinio adresą, kurį mato serveris

WMSVC IPv4 apribojimai vertinami pagal adresą, kuris pasiekia serverį, kuris ne visada yra tas adresas, kurį jūsų nešiojamasis kompiuteris mano turįs. Jei VPN telkinys kažkur kelyje verčiamas, serveris mato išverstą adresą, o leidimų sąrašas, sudarytas iš kliento vidinio adreso, jį atmes. Šis atmetimas kliento pusėje atrodo kaip ryšio klaida, todėl dažnai klaidingai diagnozuojamas kaip maršrutizavimo problema.

Naudokite išsamią TCP testo išvestį ir serverio pačio ryšių lentelę, kad pamatytumėte, kuris šaltinio adresas iš tikrųjų atvyko, prieš redaguodami apribojimų sąrašą.

Keiskite susiejimą kaip paslaugos pakeitimą

WMSVC turi būti sustabdytas prieš redaguojant jo konfigūraciją, todėl planuokite tai kaip pakeitimą su kitu galimu valdymo keliu, pavyzdžiui, konsolės prieiga arba nuotoline sesija, nepriklausančia nuo IIS Manager. Sustabdykite paslaugą, pritaikykite adreso, prievado ar sertifikato pakeitimą, tada paleiskite ją ir patvirtinkite, kad klausytojas persikėlė. Visi kiti, naudojantys nuotolinį IIS administravimą, tame intervale praranda sesiją. Praneškite kitiems administratoriams prieš atidarant intervalą; aptikti tai pakeitimo viduryje – tai būdas, kuriuo du žmonės pradeda redaguoti tą patį klausytoją.

Visų adresų pasirinkimas yra teisėtas variantas, bet traktuokite tai kaip prieigos sprendimą, o ne kaip trumpinį. Klausytojo išplėtimas, kol apribojimų sąrašas lieka atviras, yra būdas, kuriuo valdymo galinis taškas atsiduria atviras tinkle, kurio niekas neketino. Jei serveris turi kelis NIC, apribokite klausytoją valdymo sąsaja, palikite duomenų kelią ramybėje ir patvirtinkite, kad svetainė vis dar atsako savo adresu.

Sertifikatas, kurį pateikia WMSVC, parenkamas atskirai nuo svetainės sertifikatų. Jei keičiate adresą, patvirtinkite, kad sertifikatas vis dar atitinka klientų naudojamą mazgo vardą, kitaip ryšys vėliau nepavyks TLS etape su skundu, neturinčiu nieko bendra su maršrutizavimu.

Atskirkite pasiekiamumą nuo pasitikėjimo ir leidimų

Kai TCP pavyksta, likę gedimai išdėstyti tvarka: TLS pasitikėjimas valdymo sertifikatu, tada Windows autentifikavimas, tada IIS Manager leidimai, suteikti tai paskyrai. Kiekvienas jų sukuria skirtingą klaidą, ir nė vieno neišsprendžia maršrutas ar ugniasienės taisyklė. Skaitykite klaidos tekstą pažodžiui, o ne iš naujo paleiskite paslaugą.

Atlikite keturis patikrinimus ta tvarka: galinis taškas, klausytojas, šaltinio adresas, pasitikėjimas, ir paprastai rasite pasenusį susiejimą anksčiau nei tinklo problemą.