El vostre lloc respon al 443 a través del túnel, i l'IIS Manager encara no es pot connectar al servidor. Aquest parell de resultats no és una contradicció, perquè el lloc web i el punt final d'administració remota són dos oients amb dues configuracions i dos conjunts de regles d'accés. L'oient de gestió pertany al Web Management Service, WMSVC, i té la seva pròpia adreça, port, certificat i restriccions IPv4. Comproveu aquest punt final abans de tocar cap ruta.

Dos oients, dos problemes diferents

Una petició al lloc arriba a la vinculació HTTP.sys d'aquell lloc, que es defineix per lloc i per protocol a la configuració applicationHost. Una petició de l'IIS Manager arriba al WMSVC, que per defecte respon HTTPS al TCP 8172 i es configura a nivell de servidor. Res de la vinculació del lloc no canvia on escolta el WMSVC, i res del WMSVC no canvia a quina adreça respon el lloc. Comparteixen una màquina i un magatzem de certificats, i aquí s'acaba la similitud.

Així, un Test-NetConnection correcte al port 443 us diu que l'oient del lloc és abastable, i absolutament res sobre la gestió.

Trobeu l'adreça a la qual el WMSVC està realment vinculat

Pregunteu al servidor què escolta ara, no què estava configurat per escoltar fa anys. Get-NetTCPConnection -LocalPort 8172 -State Listen imprimeix l'adreça local, i un valor de 0.0.0.0 o :: significa totes les adreces, mentre que una adreça concreta significa només aquella. Si s'ha canviat l'adreçament d'un servidor, un oient encara fixat a una adreça retirada és exactament la fallada que detecta aquesta comprovació.

El valor configurat viu a la pàgina del Management Service de l'IIS Manager al node del servidor, i al darrere a administration.config sota el directori de configuració inetsrv. Compareu les dues coses: què diu el fitxer i a què està realment vinculat el sòcol.

Després executeu Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed des del client VPN afectat i llegiu l'adreça resolta i l'adreça d'origen seleccionada. Una resposta DNS diferent a la VPN és prou habitual per descartar-la aviat. Guardeu exactament aquest nom d'amfitrió i port al tiquet, perquè una comparació posterior amb un altre nom no demostra res sobre el canvi que heu fet.

Llegiu l'adreça d'origen que veu el servidor

Les restriccions IPv4 del WMSVC s'avaluen contra l'adreça que arriba al servidor, que no sempre és l'adreça que el vostre portàtil creu tenir. Si el pool VPN es tradueix en algun punt del camí, el servidor veu l'adreça traduïda i una llista de permisos construïda a partir de l'adreça interna del client la rebutjarà. Aquest rebuig sembla una fallada de connexió des del costat del client, i per això es diagnostica malament com un problema d'encaminament.

Feu servir la sortida detallada de la prova TCP i la taula de connexions del propi servidor per veure quina adreça d'origen ha arribat realment abans d'editar la llista de restriccions.

Canvieu la vinculació com un canvi de servei

El WMSVC s'ha d'aturar abans d'editar la seva configuració, així que planifiqueu-ho com un canvi amb un altre camí de gestió disponible, com ara accés per consola o una sessió remota que no depengui de l'IIS Manager. Atureu el servei, apliqueu el canvi d'adreça, port o certificat, després inicieu-lo i confirmeu que l'oient s'ha mogut. Qualsevol altra persona que faci servir administració remota d'IIS perdrà la sessió durant aquesta finestra. Aviseu els altres administradors abans que s'obri la finestra; descobrir-ho a mig canvi és com dues persones acaben editant el mateix oient.

Triar totes les adreces és una opció legítima, però tracteu-ho com una decisió d'accés i no com un drecera. Ampliar l'oient mentre la llista de restriccions continua oberta és com un punt final de gestió acaba exposat en una xarxa que ningú no volia. Si el servidor té diverses targetes de xarxa, limiteu l'oient a la interfície de gestió, deixeu el camí de dades tranquil i confirmeu que el lloc encara respon a la seva pròpia adreça.

El certificat que presenta el WMSVC es tria per separat dels certificats del lloc. Si canvieu l'adreça, confirmeu que el certificat encara coincideix amb el nom d'amfitrió que fan servir els clients, o la connexió fallarà més endavant al pas TLS amb una queixa que no té res a veure amb l'encaminament.

Separeu l'abastabilitat de la confiança i els permisos

Un cop el TCP té èxit, les fallades restants estan ordenades: confiança TLS del certificat de gestió, després autenticació de Windows, després els permisos d'IIS Manager atorgats a aquell compte. Cadascuna produeix un error diferent, i cap no es corregeix amb una ruta o una regla de tallafoc. Llegiu el text de l'error literalment en lloc de reiniciar el servei una altra vegada.

Feu les quatre comprovacions en aquest ordre, punt final, oient, adreça d'origen, confiança, i normalment trobareu la vinculació obsoleta abans de trobar un problema de xarxa.

Articles relacionats