IIS Manager na daljavo: najprej preverite lastni naslov WMSVC

Vaše spletno mesto odgovarja na 443 skozi tunel, IIS Manager pa se še vedno ne more povezati s strežnikom. Ta par rezultatov ni protislovje, ker sta spletno mesto in končna točka oddaljene administracije dva poslušalca z dvema konfiguracijama in dvema nizoma pravil dostopa. Upravni pripada Web Management Service, WMSVC, in ima lasten naslov, vrata, potrdilo in omejitve IPv4. Preverite to končno točko, preden se dotaknete ene same poti.

Dva poslušalca, dve različni težavi

Zahteva na spletno mesto doseže vezavo HTTP.sys tega mesta, ki je definirana za vsako mesto in protokol v konfiguraciji applicationHost. Zahteva iz IIS Manager doseže WMSVC, ki privzeto odgovarja HTTPS na TCP 8172 in se konfigurira na ravni strežnika. Nič v vezavi mesta ne spremeni, kje WMSVC posluša, in nič v WMSVC ne spremeni naslova, na katerem odgovarja mesto. Delita stroj in shrambo potrdil, in tam se podobnost konča.

Torej uspešen Test-NetConnection na vrata 443 pove, da je poslušalec mesta dosegljiv, in nič o upravljanju.

Poiščite naslov, na katerega je WMSVC dejansko vezan

Vprašajte strežnik, kaj posluša zdaj, ne kaj je bilo konfigurirano pred leti. Get-NetTCPConnection -LocalPort 8172 -State Listen izpiše lokalni naslov, vrednost 0.0.0.0 ali :: pa pomeni vse naslove, medtem ko določen naslov pomeni samo tega. Če se je naslavljanje strežnika spremenilo, je poslušalec, ki je še vedno pripet na umaknjen naslov, natanko tista okvara, ki jo ujame to preverjanje.

Konfigurirana vrednost je na strani Management Service v IIS Manager na vozlišču strežnika, za njo pa v administration.config v konfiguracijski mapi inetsrv. Primerjajte oba: kaj pravi datoteka in na kaj je vtičnica dejansko vezana.

Nato zaženite Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed s prizadetega odjemalca VPN in preberite razrešeni naslov ter izbrani izvorni naslov. Drugačen odgovor DNS prek VPN je dovolj pogost, da ga velja zgodaj izključiti. V zahtevek shranite točno to ime gostitelja in vrata, ker poznejša primerjava z drugim imenom ne dokaže ničesar o spremembi, ki ste jo naredili.

Preberite izvorni naslov, ki ga vidi strežnik

Omejitve IPv4 WMSVC se ocenjujejo glede na naslov, ki prispe na strežnik, kar ni vedno naslov, za katerega vaš prenosnik misli, da ga ima. Če se skupek VPN nekje na poti prevede, strežnik vidi prevedeni naslov in seznam dovoljenih, zgrajen iz notranjega naslova odjemalca, ga bo zavrnil. Ta zavrnitev je z vidika odjemalca videti kot neuspeh povezave, zato je pogosto napačno diagnosticirana kot težava usmerjanja.

Uporabite podroben izpis preizkusa TCP skupaj s strežnikovo lastno tabelo povezav, da vidite, kateri izvorni naslov je v resnici prispel, preden uredite seznam omejitev.

Spremenite vezavo kot spremembo storitve

WMSVC je treba ustaviti pred urejanjem konfiguracije, zato to načrtujte kot spremembo z drugo razpoložljivo potjo upravljanja, na primer dostopom do konzole ali oddaljeno sejo, ki ni odvisna od IIS Manager. Ustavite storitev, uporabite spremembo naslova, vrat ali potrdila, nato jo zaženite in potrdite, da se je poslušalec premaknil. Vsakdo drug, ki uporablja oddaljeno administracijo IIS, v tem oknu izgubi sejo. Obvestite druge skrbnike, preden se okno odpre; odkriti to sredi spremembe je način, kako dva človeka začneta urejati istega poslušalca.

Izbira vseh naslovov je legitimna možnost, vendar jo obravnavajte kot odločitev o dostopu, ne kot bližnjico. Razširitev poslušalca, medtem ko seznam omejitev ostane odprt, je način, kako končna točka upravljanja konča izpostavljena v omrežju, ki ga nihče ni načrtoval. Če ima strežnik več kartic NIC, omejite poslušalca na upravljalni vmesnik, pustite podatkovno pot pri miru in potrdite, da mesto še vedno odgovarja na svojem naslovu.

Potrdilo, ki ga predstavi WMSVC, se izbere ločeno od potrdil mesta. Če spremenite naslov, potrdite, da se potrdilo še vedno ujema z imenom gostitelja, ki ga uporabljajo odjemalci, sicer bo povezava pozneje spodletela v koraku TLS s pritožbo, ki nima nič skupnega z usmerjanjem.

Ločite dosegljivost od zaupanja in dovoljenj

Ko TCP uspe, so preostale okvare urejene: zaupanje TLS v potrdilo upravljanja, nato preverjanje Windows, nato dovoljenja IIS Manager, dodeljena temu računu. Vsako od njih daje drugačno napako in nobene ne odpravi pot ali pravilo požarnega zidu. Preberite besedilo napake dobesedno, namesto da storitev znova zaženete.

Opravite štiri preverjanja v tem vrstnem redu, končna točka, poslušalec, izvorni naslov, zaupanje, in običajno boste našli zastarelo vezavo, preden boste našli omrežno težavo.