IIS Manager eksternt: sjekk WMSVCs egen adresse først

Nettstedet ditt svarer på 443 gjennom tunnelen, og IIS Manager får fortsatt ikke kontakt med serveren. De to resultatene er ikke en motsetning, fordi nettstedet og endepunktet for fjernadministrasjon er to lyttere med to konfigurasjoner og to sett med tilgangsregler. Administrasjonslytteren tilhører Web Management Service, WMSVC, og har sin egen adresse, port, sertifikat og IPv4-begrensninger. Sjekk det endepunktet før du rører én eneste rute.

To lyttere, to forskjellige problemer

En forespørsel til nettstedet når HTTP.sys-bindingen for det nettstedet, som er definert per nettsted og per protokoll i applicationHost-konfigurasjonen. En forespørsel fra IIS Manager når WMSVC, som som standard svarer HTTPS på TCP 8172 og konfigureres på servernivå. Ingenting i nettstedets binding endrer hvor WMSVC lytter, og ingenting i WMSVC endrer hvilken adresse nettstedet svarer på. De deler maskin og sertifikatlager, og der stopper likheten.

Så en vellykket Test-NetConnection mot port 443 forteller deg at nettstedets lytter er tilgjengelig, og ingenting om administrasjon.

Finn adressen WMSVC faktisk er bundet til

Spør serveren hva den lytter på nå, ikke hva den ble konfigurert til for mange år siden. Get-NetTCPConnection -LocalPort 8172 -State Listen skriver ut den lokale adressen, og en verdi på 0.0.0.0 eller :: betyr alle adresser, mens en bestemt adresse betyr bare den ene. Hvis en server har fått endret adresseringen, er en lytter som fortsatt er festet til en avviklet adresse nøyaktig feilen denne kontrollen fanger.

Den konfigurerte verdien ligger på Management Service-siden i IIS Manager på servernoden, og bak den i administration.config i inetsrv-konfigurasjonskatalogen. Sammenlign de to: hva filen sier, og hva sockelen faktisk er bundet til.

Kjør deretter Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed fra den berørte VPN-klienten og les den oppslåtte adressen og den valgte kildeadressen. Et annet DNS-svar over VPN er vanlig nok til å utelukkes tidlig. Ta vare på nøyaktig det vertsnavnet og den porten i saken, fordi en senere sammenligning med et annet navn ikke beviser noe om endringen du gjorde.

Les kildeadressen serveren ser

IPv4-begrensningene til WMSVC vurderes mot adressen som kommer fram til serveren, som ikke alltid er adressen laptopen din tror den har. Hvis VPN-poolen oversettes et sted langs veien, ser serveren den oversatte adressen, og en tillatelsesliste bygget fra klientens indre adresse vil avvise den. Den avvisningen ser ut som en tilkoblingsfeil fra klientsiden, og derfor blir den ofte feildiagnostisert som et ruteproblem.

Bruk den detaljerte utskriften fra TCP-testen, sammen med serverens egen tilkoblingstabell, for å se hvilken kildeadresse som faktisk kom fram før du redigerer begrensningslisten.

Endre bindingen som en tjenesteendring

WMSVC må stoppes før konfigurasjonen redigeres, så planlegg det som en endring med en annen administrasjonsvei tilgjengelig, for eksempel konsoltilgang eller en fjernøkt som ikke er avhengig av IIS Manager. Stopp tjenesten, bruk endringen av adresse, port eller sertifikat, start den så og bekreft at lytteren flyttet seg. Alle andre som bruker ekstern IIS-administrasjon mister økten sin i det vinduet. Si fra til de andre administratorene før vinduet åpnes; å oppdage det midt i endringen er hvordan to personer ender med å redigere samme lytter.

Å velge alle adresser er et legitimt alternativ, men behandle det som en tilgangsbeslutning og ikke en snarvei. Å utvide lytteren mens begrensningslisten står åpen er hvordan et administrasjonsendepunkt ender med å bli eksponert på et nettverk ingen hadde tenkt. Hvis serveren har flere NIC-er, begrens lytteren til administrasjonsgrensesnittet, la datastien være i fred, og bekreft at nettstedet fortsatt svarer på sin egen adresse.

Sertifikatet WMSVC presenterer velges separat fra nettstedets sertifikater. Hvis du endrer adressen, bekreft at sertifikatet fortsatt samsvarer med vertsnavnet klientene bruker, ellers vil tilkoblingen senere feile i TLS-trinnet med en klage som ikke har noe med ruting å gjøre.

Skill tilgjengelighet fra tillit og rettigheter

Når TCP lykkes, er de gjenstående feilene ordnet: TLS-tillit for administrasjonssertifikatet, deretter Windows-autentisering, deretter IIS Manager-rettighetene som er gitt den kontoen. Hver av dem gir en annen feil, og ingen av dem løses av en rute eller en brannmurregel. Les feilteksten bokstavelig i stedet for å starte tjenesten på nytt.

Gå gjennom de fire kontrollene i den rekkefølgen, endepunkt, lytter, kildeadresse, tillit, og du finner vanligvis den foreldede bindingen før du finner et nettverksproblem.