Fora administrado per IIS Manager: unue kontrolu la propran adreson de WMSVC

Via retejo respondas per 443 tra la tunelo, kaj IIS Manager tamen ne povas konektiĝi al la servilo. Tiuj du rezultoj ne kontraŭdiras unu la alian, ĉar la retejo kaj la finpunkto de fora administrado estas du aŭskultantoj kun du agordoj kaj du aroj da alirreguloj. La administra aŭskultanto apartenas al la Reta Administra Servo, WMSVC, kaj havas propran adreson, pordon, atestilon kaj IPv4-limigojn. Kontrolu tiun finpunkton antaŭ ol tuŝi eĉ unu vojon.

Du aŭskultantoj, du malsamaj problemoj

Peto al la retejo atingas la HTTP.sys-ligon de tiu retejo, kiu estas difinita por ĉiu retejo kaj ĉiu protokolo en la agordo applicationHost. Peto de IIS Manager atingas WMSVC, kiu defaŭlte respondas per HTTPS ĉe TCP 8172 kaj estas agordata je servila nivelo. Nenio en la ligo de la retejo ŝanĝas, kie WMSVC aŭskultas, kaj nenio en WMSVC ŝanĝas, al kiu adreso la retejo respondas. Ili dividas unu maŝinon kaj unu atestilan konservejon, kaj tie la simileco finiĝas.

Do sukcesa Test-NetConnection ĉe pordo 443 diras al vi, ke la aŭskultanto de la retejo estas atingebla, kaj tute nenion pri administrado.

Trovu la adreson al kiu WMSVC estas fakte ligita

Demandu la servilon, al kio ĝi aŭskultas nun, ne al kio ĝi estis agordita antaŭ jaroj. Get-NetTCPConnection -LocalPort 8172 -State Listen presas la lokan adreson, kaj valoro 0.0.0.0 aŭ :: signifas ĉiujn adresojn, dum specifa adreso signifas nur tiun. Se la adresado de servilo estis ŝanĝita, aŭskultanto ankoraŭ fiksita al emerita adreso estas ĝuste la paneo, kiun ĉi tiu kontrolo kaptas.

La agordita valoro troviĝas sur la paĝo Management Service de IIS Manager ĉe la servila nodo, kaj malantaŭ ĝi en administration.config sub la agorda dosierujo inetsrv. Komparu la du: kion diras la dosiero, kaj al kio la ingo estas fakte ligita.

Poste rulu Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed de la tuŝita VPN-kliento kaj legu la solvitan adreson kaj la elektitan fontan adreson. Alia DNS-respondo ĉe la VPN estas sufiĉe ofta por inde ekskludi ĝin frue. Konservu ĝuste tiun gastigan nomon kaj pordon en la bileto, ĉar posta komparo kun alia nomo pruvas nenion pri la ŝanĝo, kiun vi faris.

Legu la fontan adreson, kiun la servilo vidas

La IPv4-limigoj de WMSVC estas taksataj kontraŭ la adreso, kiu alvenas al la servilo, kaj tio ne ĉiam estas la adreso, kiun via tekkomputilo kredas havi. Se la VPN-baseno estas tradukata ie survoje, la servilo vidas la tradukitan adreson, kaj permeslisto konstruita el la interna adreso de la kliento rifuzos ĝin. Tiu rifuzo aspektas kiel konekta paneo de la klienta flanko, kaj tial ĝi estas erare diagnozita kiel enkursiga problemo.

Uzu la detalan eligon de la TCP-testo kaj la propran konektan tabelon de la servilo por vidi, kiu fonta adreso fakte alvenis, antaŭ ol vi redaktos la limigan liston.

Ŝanĝu la ligon kiel servan ŝanĝon

WMSVC devas esti haltigita antaŭ ol ĝia agordo estas redaktata, do planu ĝin kiel ŝanĝon kun alia disponebla administra vojo, ekzemple konsola aliro aŭ fora seanco, kiu ne dependas de IIS Manager. Haltigu la servon, apliku la ŝanĝon de adreso, pordo aŭ atestilo, poste startigu ĝin kaj konfirmu, ke la aŭskultanto moviĝis. Ĉiu alia, kiu uzas foran IIS-administradon, perdos sian seancon dum tiu fenestro. Diru tion al la aliaj administrantoj antaŭ ol la fenestro malfermiĝos; malkovri ĝin meze de la ŝanĝo estas kiel du homoj finas redakti la saman aŭskultanton.

Elekti ĉiujn adresojn estas legitima opcio, sed traktu ĝin kiel decidon pri aliro, ne kiel fuŝsolvon. Larĝigi la aŭskultanton dum la limiga listo restas malfermita estas kiel administra finpunkto finiĝas elmetita en reto, kiun neniu intencis. Se la servilo havas plurajn retkartojn, limigu la aŭskultanton al la administra interfaco, lasu la datuman vojon trankvila, kaj konfirmu, ke la retejo ankoraŭ respondas ĉe sia propra adreso.

La atestilo, kiun WMSVC prezentas, estas elektata aparte de la atestiloj de la retejo. Se vi ŝanĝas la adreson, konfirmu, ke la atestilo ankoraŭ kongruas kun la gastiga nomo, kiun la klientoj uzas, alie la konekto poste malsukcesos ĉe la TLS-paŝo kun plendo, kiu havas nenion komunan kun enkursigado.

Apartigu atingeblon de fido kaj permesoj

Post kiam TCP sukcesas, la ceteraj paneoj estas ordigitaj: TLS-fido por la administra atestilo, poste Windows-aŭtentikigo, poste la IIS Manager-permesoj donitaj al tiu konto. Ĉiu el ili produktas alian eraron, kaj neniun solvas vojo aŭ fajroŝirma regulo. Legu la erartekston laŭvorte anstataŭ restartigi la servon denove.

Trapasu la kvar kontrolojn en tiu ordo, finpunkto, aŭskultanto, fonta adreso, fido, kaj vi kutime trovos la kadukan ligon antaŭ ol trovi retan problemon.