Jou werf antwoord op 443 deur die tonnel, en IIS Manager kan steeds nie aan die bediener koppel nie. Dié twee resultate is nie 'n teenstrydigheid nie, want die webwerf en die afstandadministrasie-eindpunt is twee luisteraars met twee konfigurasies en twee stelle toegangsreëls. Die bestuureenheid behoort aan die Web Management Service, WMSVC, en het sy eie adres, poort, sertifikaat en IPv4-beperkings. Kyk na daardie eindpunt voordat jy aan 'n enkele roete raak.

Twee luisteraars, twee verskillende probleme

'n Versoek aan die werf bereik die HTTP.sys-binding vir daardie werf, wat per werf en per protokol in die applicationHost-konfigurasie gedefinieer word. 'n Versoek van IIS Manager bereik WMSVC, wat by verstek HTTPS op TCP 8172 antwoord en op bediener-vlak gekonfigureer word. Niks aan die werf se binding verander waar WMSVC luister nie, en niks aan WMSVC verander op watter adres die werf antwoord nie. Hulle deel 'n masjien en 'n sertifikaatstoor, en dit is waar die ooreenkoms eindig.

Dus 'n geslaagde Test-NetConnection teen poort 443 sê vir jou die werf-luisteraar is bereikbaar, en glad niks oor bestuur nie.

Vind die adres waaraan WMSVC werklik gebind is

Vra die bediener waarop dit luister eerder as waarop dit jare gelede gekonfigureer is. Get-NetTCPConnection -LocalPort 8172 -State Listen druk die plaaslike adres, en 'n waarde van 0.0.0.0 of :: beteken alle adresse terwyl 'n spesifieke adres net daardie een beteken. As die adressering van 'n bediener verander is, is 'n luisteraar wat nog aan 'n uitgefaseerde adres vasgepen is juis die fout wat hierdie kontrole vang.

Die gekonfigureerde waarde woon op die Management Service-bladsy van IIS Manager op die bediener-knooppunt, en agter dit in administration.config onder die inetsrv-konfigurasiegids. Vergelyk die twee: wat die lêer sê, en waaraan die sok werklik gebind is.

Begin dan Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed van die geaffekteerde VPN-kliënt en lees die opgeloste adres en die gekose bronadres. 'n Ander DNS-antwoord op die VPN is algemeen genoeg om vroeg uit te skakel. Hou daardie presiese gasheernaam en poort in die kaartjie, want 'n latere vergelyking teen 'n ander naam bewys niks oor die verandering wat jy gemaak het nie.

Lees die bronadres wat die bediener sien

WMSVC se IPv4-beperkings word geëvalueer teen die adres wat by die bediener aankom, wat nie altyd die adres is wat jou skootrekenaar dink hy het nie. As die VPN-poel êrens langs die pad vertaal word, sien die bediener die vertaalde adres en 'n toelaatlys wat uit die kliënt se binne-adres gebou is, sal dit weier. Daardie weiering lyk soos 'n verbindingsfout van die kliënt se kant, en dit is waarom dit as roetering verkeerd gediagnoseer word.

Gebruik die gedetailleerde uitvoer van die TCP-toets, plus die bediener se eie verbindingstabel, om te sien watter bronadres werklik aangekom het voordat jy die beperkingslys wysig.

Verander die binding as 'n diensverandering

WMSVC moet gestop word voordat sy konfigurasie gewysig word, so beplan dit as 'n verandering met nog 'n bestuurspad beskikbaar, soos konsoltoegang of 'n afstand-sessie wat nie van IIS Manager afhanklik is nie. Stop die diens, pas die adres-, poort- of sertifikaatverandering toe, begin dit dan en bevestig die luisteraar het geskuif. Enigiemand anders wat afstand-IIS-administrasie gebruik, verloor hul sessie gedurende daardie venster. Sê vir die ander administrateurs voordat die venster oopgaan; om dit midde-in die verandering te ontdek, is hoe twee mense dieselfde luisteraar eindig en wysig.

Om alle adresse te kies is 'n wettige opsie, maar hanteer dit as 'n toegangsbeslissing eerder as 'n kortpad. Om die luisteraar te verbreed terwyl die beperkingslys oop bly, is hoe 'n bestuurs-eindpunt uiteindelik op 'n netwerk blootgestel word wat niemand bedoel het nie. As die bediener verskeie netwerkkaarte het, beperk die luisteraar tot die bestuurskoppelvlak, los die datapad alleen, en bevestig die werf antwoord steeds op sy eie adres.

Die sertifikaat wat WMSVC aanbied, word afsonderlik van die werf se sertifikate gekies. As jy die adres verander, bevestig die sertifikaat stem nog met die gasheernaam wat kliënte gebruik, of die verbinding sal later by die TLS-stap misluk met 'n klag wat niks met roetering te doen het nie.

Skei bereikbaarheid van vertroue en regte

Sodra TCP slaag, is die oorblywende mislukkings georden: TLS-vertroue vir die bestuursertifikaat, dan Windows-verifikasie, dan die IIS Manager-regte wat aan daardie rekening gegee is. Elkeen lewer 'n ander fout, en nie een word deur 'n roete of 'n firewall-reël reggemaak nie. Lees die foutteks letterlik eerder as om die diens weer te herbegin.

Werk die vier kontroles in daardie volgorde, eindpunt, luisteraar, bronadres, vertroue, en jy sal gewoonlik die verouderde binding vind voordat jy 'n netwerkprobleem vind.

Verwante artikels