IIS Manager eksternt: sjekk WMSVC si eiga adresse fyrst

Nettstaden din svarar på 443 gjennom tunnelen, og IIS Manager får framleis ikkje kontakt med tenaren. Dei to resultata er ikkje ei motsetning, fordi nettstaden og endepunktet for fjernadministrasjon er to lyttarar med to konfigurasjonar og to sett med tilgangsreglar. Administrasjonslyttaren høyrer til Web Management Service, WMSVC, og har si eiga adresse, port, sertifikat og IPv4-avgrensingar. Sjekk det endepunktet før du rører éi einaste rute.

To lyttarar, to ulike problem

Ei førespurnad til nettstaden når HTTP.sys-bindinga for den nettstaden, som er definert per nettstad og per protokoll i applicationHost-konfigurasjonen. Ei førespurnad frå IIS Manager når WMSVC, som som standard svarar HTTPS på TCP 8172 og vert konfigurert på tenarnivå. Ingenting i bindinga til nettstaden endrar kvar WMSVC lyttar, og ingenting i WMSVC endrar kva adresse nettstaden svarar på. Dei deler maskin og sertifikatlager, og der stoppar likskapen.

Så ein vellukka Test-NetConnection mot port 443 fortel deg at lyttaren til nettstaden er tilgjengeleg, og ingenting om administrasjon.

Finn adressa WMSVC faktisk er bunden til

Spør tenaren kva han lyttar på no, ikkje kva han vart konfigurert til for mange år sidan. Get-NetTCPConnection -LocalPort 8172 -State Listen skriv ut den lokale adressa, og ein verdi på 0.0.0.0 eller :: tyder alle adresser, medan ei bestemd adresse berre tyder den eine. Om adresseringa til ein tenar er endra, er ein lyttar som framleis er fest til ei avvikla adresse nøyaktig feilen denne kontrollen fangar.

Den konfigurerte verdien ligg på Management Service-sida i IIS Manager på tenarnoden, og bak henne i administration.config i inetsrv-konfigurasjonskatalogen. Samanlikn dei to: kva fila seier, og kva sockelen faktisk er bunden til.

Køyr deretter Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed frå den råka VPN-klienten og les den oppslåtte adressa og den valde kjeldeadressa. Eit anna DNS-svar over VPN er vanleg nok til å utelukkast tidleg. Ta vare på nøyaktig det vertsnamnet og den porten i saka, fordi ein seinare samanlikning med eit anna namn ikkje beviser noko om endringa du gjorde.

Les kjeldeadressa tenaren ser

IPv4-avgrensingane til WMSVC vert vurderte mot adressa som kjem fram til tenaren, som ikkje alltid er adressa laptopen din trur han har. Om VPN-poolen vert omsett ein stad langs vegen, ser tenaren den omsette adressa, og ei tillatingsliste bygd frå den indre adressa til klienten vil avvise henne. Den avvisinga ser ut som ein tilkoplingsfeil frå klientsida, og difor vert ho ofte feildiagnostisert som eit ruteproblem.

Bruk den detaljerte utskrifta frå TCP-testen, saman med tenaren si eiga tilkoplingstabell, for å sjå kva kjeldeadresse som faktisk kom fram før du redigerer avgrensingslista.

Endre bindinga som ei tenesteendring

WMSVC må stoggast før konfigurasjonen vert redigert, så planlegg det som ei endring med ein annan administrasjonsveg tilgjengeleg, til dømes konsolltilgang eller ei fjernøkt som ikkje er avhengig av IIS Manager. Stogg tenesta, bruk endringa av adresse, port eller sertifikat, start henne så og stadfest at lyttaren flytta seg. Alle andre som brukar ekstern IIS-administrasjon mistar økta si i det vindauget. Sei frå til dei andre administratørane før vindauget opnar; å oppdage det midt i endringa er korleis to personar endar med å redigere same lyttaren.

Å velje alle adresser er eit legitimt alternativ, men handsam det som ei tilgangsavgjerd og ikkje ei snarveg. Å utvide lyttaren medan avgrensingslista står open er korleis eit administrasjonsendepunkt endar med å bli eksponert på eit nettverk ingen hadde tenkt. Om tenaren har fleire NIC-ar, avgrens lyttaren til administrasjonsgrensesnittet, lat datastien vere i fred, og stadfest at nettstaden framleis svarar på si eiga adresse.

Sertifikatet WMSVC presenterer vert valt separat frå sertifikata til nettstaden. Om du endrar adressa, stadfest at sertifikatet framleis samsvarar med vertsnamnet klientane brukar, elles vil tilkoplinga seinare feile i TLS-trinnet med ei klage som ikkje har noko med ruting å gjere.

Skil tilgjenge frå tillit og rettar

Når TCP lukkast, er dei gjenverande feila ordna: TLS-tillit for administrasjonssertifikatet, deretter Windows-autentisering, deretter IIS Manager-rettane som er gjevne den kontoen. Kvar av dei gir ein annan feil, og ingen av dei vert løyste av ei rute eller ein brannmurregel. Les feilteksten bokstaveleg i staden for å starte tenesta på nytt.

Gå gjennom dei fire kontrollane i den rekkjefølgja, endepunkt, lyttar, kjeldeadresse, tillit, og du finn vanlegvis den forelda bindinga før du finn eit nettverksproblem.