IIS Manager la distanță: verificați mai întâi adresa proprie a WMSVC

Site-ul dvs. răspunde pe 443 prin tunel, iar IIS Manager tot nu se poate conecta la server. Această pereche de rezultate nu este o contradicție, pentru că site-ul web și endpoint-ul de administrare la distanță sunt doi ascultători cu două configurații și două seturi de reguli de acces. Cel de administrare aparține serviciului Web Management Service, WMSVC, și are propria adresă, port, certificat și restricții IPv4. Verificați acel endpoint înainte de a atinge măcar o rută.

Doi ascultători, două probleme diferite

O cerere către site ajunge la legătura HTTP.sys a acelui site, definită pe site și pe protocol în configurația applicationHost. O cerere din IIS Manager ajunge la WMSVC, care implicit răspunde HTTPS pe TCP 8172 și este configurat la nivel de server. Nimic din legătura site-ului nu schimbă locul în care ascultă WMSVC, și nimic din WMSVC nu schimbă adresa pe care răspunde site-ul. Împart o mașină și un depozit de certificate, și acolo se termină asemănarea.

Deci un Test-NetConnection reușit pe portul 443 vă spune că ascultătorul site-ului este accesibil, și nimic despre administrare.

Găsiți adresa la care WMSVC este de fapt legat

Întrebați serverul pe ce ascultă acum, nu ce a fost configurat acum ani. Get-NetTCPConnection -LocalPort 8172 -State Listen afișează adresa locală, iar o valoare 0.0.0.0 sau :: înseamnă toate adresele, în timp ce o adresă specifică înseamnă doar aceea. Dacă adresarea unui server a fost schimbată, un ascultător încă fixat pe o adresă retrasă este exact defecțiunea pe care o prinde această verificare.

Valoarea configurată se află în pagina Management Service din IIS Manager pe nodul serverului, iar în spatele ei în administration.config din directorul de configurație inetsrv. Comparați-le pe amândouă: ce spune fișierul și la ce este de fapt legat socketul.

Apoi rulați Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed de pe clientul VPN afectat și citiți adresa rezolvată și adresa sursă selectată. Un răspuns DNS diferit prin VPN este destul de obișnuit pentru a merita exclus devreme. Păstrați în tichet exact acel nume de gazdă și acel port, pentru că o comparație ulterioară cu alt nume nu dovedește nimic despre modificarea făcută.

Citiți adresa sursă pe care o vede serverul

Restricțiile IPv4 ale WMSVC sunt evaluate față de adresa care ajunge la server, care nu este întotdeauna adresa pe care laptopul dvs. crede că o are. Dacă pool-ul VPN este tradus undeva pe traseu, serverul vede adresa tradusă, iar o listă de permisiuni construită din adresa internă a clientului o va refuza. Acel refuz arată din partea clientului ca o eroare de conexiune, motiv pentru care este adesea diagnosticat greșit ca problemă de rutare.

Folosiți ieșirea detaliată a testului TCP, împreună cu tabelul de conexiuni al serverului, pentru a vedea ce adresă sursă a ajuns de fapt înainte de a edita lista de restricții.

Schimbați legătura ca o modificare de serviciu

WMSVC trebuie oprit înainte de a-i fi editată configurația, așa că planificați-o ca o modificare cu o altă cale de administrare disponibilă, cum ar fi accesul la consolă sau o sesiune la distanță care nu depinde de IIS Manager. Opriți serviciul, aplicați modificarea de adresă, port sau certificat, apoi porniți-l și confirmați că ascultătorul s-a mutat. Oricine altcineva care folosește administrarea IIS la distanță își pierde sesiunea în acel interval. Anunțați ceilalți administratori înainte de deschiderea ferestrei; a descoperi asta la mijlocul modificării este modul în care doi oameni ajung să editeze același ascultător.

Alegerea tuturor adreselor este o opțiune legitimă, dar tratați-o ca o decizie de acces, nu ca o scurtătură. Lărgirea ascultătorului în timp ce lista de restricții rămâne deschisă este modul în care un endpoint de administrare ajunge expus într-o rețea pe care nimeni nu o intenționa. Dacă serverul are mai multe NIC-uri, restricționați ascultătorul la interfața de administrare, lăsați calea de date în pace și confirmați că site-ul răspunde în continuare pe propria adresă.

Certificatul pe care îl prezintă WMSVC este selectat separat de certificatele site-ului. Dacă schimbați adresa, confirmați că certificatul corespunde în continuare numelui de gazdă folosit de clienți, altfel conexiunea va eșua mai târziu la pasul TLS cu o plângere care nu are nimic de-a face cu rutarea.

Separați accesibilitatea de încredere și permisiuni

Odată ce TCP reușește, defecțiunile rămase sunt ordonate: încrederea TLS pentru certificatul de administrare, apoi autentificarea Windows, apoi permisiunile IIS Manager acordate acelui cont. Fiecare produce o eroare diferită și niciuna nu este rezolvată de o rută sau o regulă de firewall. Citiți textul erorii literal în loc să reporniți serviciul încă o dată.

Parcurgeți cele patru verificări în această ordine, endpoint, ascultător, adresă sursă, încredere, și de obicei veți găsi legătura învechită înainte de a găsi o problemă de rețea.