Administración remota con IIS Manager: revise primero la dirección propia de WMSVC

Su sitio responde en 443 a través del túnel, y IIS Manager sigue sin poder conectarse al servidor. Ese par de resultados no es una contradicción, porque el sitio web y el punto de conexión de administración remota son dos agentes de escucha con dos configuraciones y dos conjuntos de reglas de acceso. El de administración pertenece al Servicio de administración web, WMSVC, y tiene su propia dirección, puerto, certificado y restricciones IPv4. Revise ese punto de conexión antes de tocar una sola ruta.

Dos agentes de escucha, dos problemas distintos

Una solicitud al sitio llega a la vinculación HTTP.sys de ese sitio, que se define por sitio y por protocolo en la configuración applicationHost. Una solicitud de IIS Manager llega a WMSVC, que por defecto responde HTTPS en TCP 8172 y se configura a nivel de servidor. Nada en la vinculación del sitio cambia dónde escucha WMSVC, y nada en WMSVC cambia en qué dirección responde el sitio. Comparten una máquina y un almacén de certificados, y ahí termina el parecido.

Así que un Test-NetConnection correcto en el puerto 443 le dice que el agente de escucha del sitio es accesible, y absolutamente nada sobre la administración.

Encuentre la dirección a la que WMSVC está realmente vinculado

Pregunte al servidor en qué escucha ahora, no en qué se configuró para escuchar hace años. Get-NetTCPConnection -LocalPort 8172 -State Listen imprime la dirección local, y un valor de 0.0.0.0 o :: significa todas las direcciones, mientras que una dirección concreta significa solo esa. Si a un servidor le han cambiado el direccionamiento, un agente de escucha todavía anclado a una dirección retirada es exactamente la falla que detecta esta comprobación.

El valor configurado vive en la página Management Service de IIS Manager en el nodo del servidor, y detrás de ella en administration.config bajo el directorio de configuración inetsrv. Compare las dos cosas: lo que dice el archivo y a qué está realmente vinculado el socket.

Después ejecute Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed desde el cliente VPN afectado y lea la dirección resuelta y la dirección de origen seleccionada. Una respuesta DNS distinta en la VPN es lo bastante común como para descartarla pronto. Guarde ese nombre de host y ese puerto exactos en el ticket, porque una comparación posterior con otro nombre no demuestra nada sobre el cambio que hizo.

Lea la dirección de origen que ve el servidor

Las restricciones IPv4 de WMSVC se evalúan contra la dirección que llega al servidor, que no siempre es la dirección que su portátil cree tener. Si el grupo de VPN se traduce en algún punto del camino, el servidor ve la dirección traducida y una lista de permitidos construida a partir de la dirección interna del cliente la rechazará. Ese rechazo parece un fallo de conexión desde el lado del cliente, y por eso se diagnostica mal como un problema de enrutamiento.

Use la salida detallada de la prueba TCP y la propia tabla de conexiones del servidor para ver qué dirección de origen llegó realmente antes de editar la lista de restricciones.

Cambie la vinculación como un cambio de servicio

WMSVC debe detenerse antes de editar su configuración, así que planifíquelo como un cambio con otra vía de administración disponible, como acceso por consola o una sesión remota que no dependa de IIS Manager. Detenga el servicio, aplique el cambio de dirección, puerto o certificado, luego inícielo y confirme que el agente de escucha se movió. Cualquier otra persona que use administración remota de IIS perderá su sesión durante esa ventana. Avise a los demás administradores antes de que se abra la ventana; descubrirlo a mitad del cambio es como dos personas acaban editando el mismo agente de escucha.

Elegir todas las direcciones es una opción legítima, pero trátela como una decisión de acceso y no como un atajo. Ampliar el agente de escucha mientras la lista de restricciones sigue abierta es como un punto de conexión de administración termina expuesto en una red que nadie pretendía. Si el servidor tiene varias tarjetas de red, limite el agente de escucha a la interfaz de administración, deje la ruta de datos en paz y confirme que el sitio sigue respondiendo en su propia dirección.

El certificado que presenta WMSVC se elige por separado de los certificados del sitio. Si cambia la dirección, confirme que el certificado sigue coincidiendo con el nombre de host que usan los clientes, o la conexión fallará más adelante en el paso TLS con una queja que no tiene nada que ver con el enrutamiento.

Separe la accesibilidad de la confianza y los permisos

Una vez que TCP funciona, las fallas restantes están ordenadas: confianza TLS del certificado de administración, luego autenticación de Windows, luego los permisos de IIS Manager concedidos a esa cuenta. Cada una produce un error distinto, y ninguna se arregla con una ruta ni con una regla de firewall. Lea el texto del error al pie de la letra en lugar de reiniciar el servicio otra vez.

Haga las cuatro comprobaciones en ese orden, punto de conexión, agente de escucha, dirección de origen, confianza, y normalmente encontrará la vinculación obsoleta antes de encontrar un problema de red.