Fjernadministration med IIS Manager: tjek først WMSVCs egen adresse

Dit websted svarer på 443 gennem tunnelen, og IIS Manager kan stadig ikke oprette forbindelse til serveren. De to resultater er ikke en modsætning, for webstedet og fjernadministrationens endepunkt er to lyttere med to konfigurationer og to sæt adgangsregler. Administrationslytteren tilhører Web Management Service, WMSVC, og har sin egen adresse, port, certifikat og IPv4-begrænsninger. Tjek det endepunkt, før du rører en enkelt rute.

To lyttere, to forskellige problemer

En anmodning til webstedet når HTTP.sys-bindingen for det websted, som defineres pr. websted og pr. protokol i applicationHost-konfigurationen. En anmodning fra IIS Manager når WMSVC, der som standard svarer HTTPS på TCP 8172 og konfigureres på serverniveau. Intet i webstedets binding ændrer, hvor WMSVC lytter, og intet i WMSVC ændrer, hvilken adresse webstedet svarer på. De deler en maskine og et certifikatlager, og der stopper ligheden.

Så en vellykket Test-NetConnection mod port 443 fortæller dig, at webstedets lytter er tilgængelig, og intet som helst om administration.

Find den adresse, WMSVC faktisk er bundet til

Spørg serveren, hvad den lytter på nu, i stedet for hvad den blev konfigureret til for år tilbage. Get-NetTCPConnection -LocalPort 8172 -State Listen udskriver den lokale adresse, og en værdi på 0.0.0.0 eller :: betyder alle adresser, mens en bestemt adresse kun betyder den ene. Hvis en server har fået ændret sin adressering, er en lytter, der stadig er fastgjort til en pensioneret adresse, netop den fejl, denne kontrol fanger.

Den konfigurerede værdi findes på Management Service-siden i IIS Manager på servernoden og bag den i administration.config under inetsrv-konfigurationsmappen. Sammenlign de to: hvad filen siger, og hvad socketen faktisk er bundet til.

Kør derefter Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed fra den berørte VPN-klient, og læs den opløste adresse og den valgte kildeadresse. Et anderledes DNS-svar over VPN er almindeligt nok til at være værd at udelukke tidligt. Gem præcis det værtsnavn og den port i billetten, for en senere sammenligning med et andet navn beviser intet om den ændring, du foretog.

Læs den kildeadresse, serveren ser

WMSVCs IPv4-begrænsninger vurderes mod den adresse, der ankommer til serveren, og det er ikke altid den adresse, din bærbare computer tror, den har. Hvis VPN-puljen oversættes et sted på vejen, ser serveren den oversatte adresse, og en tilladelsesliste bygget ud fra klientens indre adresse vil afvise den. Den afvisning ligner en forbindelsesfejl fra klientsiden, og derfor fejldiagnosticeres den som routing.

Brug den detaljerede udskrift af TCP-testen plus serverens egen forbindelsestabel til at se, hvilken kildeadresse der faktisk ankom, før du redigerer begrænsningslisten.

Skift bindingen som en serviceændring

WMSVC skal stoppes, før dens konfiguration redigeres, så planlæg det som en ændring med en anden administrationsvej tilgængelig, f.eks. konsoladgang eller en fjernsession, der ikke afhænger af IIS Manager. Stop tjenesten, anvend ændringen af adresse, port eller certifikat, start den derefter, og bekræft, at lytteren flyttede sig. Alle andre, der bruger fjern-IIS-administration, mister deres session i det vindue. Fortæl de andre administratorer det, før vinduet åbner; at opdage det midt i ændringen er, hvordan to personer ender med at redigere den samme lytter.

At vælge alle adresser er en legitim mulighed, men behandl det som en adgangsbeslutning snarere end en genvej. At udvide lytteren, mens begrænsningslisten forbliver åben, er, hvordan et administrationendepunkt ender med at være eksponeret på et netværk, ingen havde tænkt på. Hvis serveren har flere netværkskort, så begræns lytteren til administrationsinterfacet, lad datastien være i fred, og bekræft, at webstedet stadig svarer på sin egen adresse.

Det certifikat, WMSVC præsenterer, vælges separat fra webstedets certifikater. Hvis du ændrer adressen, så bekræft, at certifikatet stadig matcher det værtsnavn, klienterne bruger, ellers fejler forbindelsen senere ved TLS-trinnet med en klage, der intet har med routing at gøre.

Adskil tilgængelighed fra tillid og rettigheder

Når TCP lykkes, er de resterende fejl ordnet: TLS-tillid til administrationscertifikatet, derefter Windows-godkendelse, derefter de IIS Manager-rettigheder, der er givet til den konto. Hver af dem giver en anden fejl, og ingen af dem løses af en rute eller en firewallregel. Læs fejlteksten bogstaveligt i stedet for at genstarte tjenesten igen.

Gå gennem de fire kontroller i den rækkefølge, endepunkt, lytter, kildeadresse, tillid, og du vil normalt finde den forældede binding, før du finder et netværksproblem.