Administración remota con IIS Manager: comprobe primeiro o enderezo propio do WMSVC

O seu sitio responde en 443 a través do túnel, e IIS Manager segue sen poder conectarse ao servidor. Ese par de resultados non é unha contradición, porque o sitio web e o punto final de administración remota son dous oíntes con dúas configuracións e dous conxuntos de regras de acceso. O de administración pertence ao Servizo de xestión web, WMSVC, e ten o seu propio enderezo, porto, certificado e restricións IPv4. Comprobe ese punto final antes de tocar unha soa ruta.

Dous oíntes, dous problemas distintos

Unha solicitude ao sitio chega á vinculación HTTP.sys dese sitio, que se define por sitio e por protocolo na configuración applicationHost. Unha solicitude de IIS Manager chega ao WMSVC, que por defecto responde HTTPS en TCP 8172 e configúrase a nivel de servidor. Nada na vinculación do sitio cambia onde escoita o WMSVC, e nada no WMSVC cambia en que enderezo responde o sitio. Comparten unha máquina e un almacén de certificados, e aí remata o parecido.

Así que un Test-NetConnection correcto no porto 443 dille que o oínte do sitio é accesible, e absolutamente nada sobre a administración.

Atope o enderezo ao que o WMSVC está realmente vinculado

Pregunte ao servidor en que escoita agora, non en que se configurou para escoitar hai anos. Get-NetTCPConnection -LocalPort 8172 -State Listen imprime o enderezo local, e un valor de 0.0.0.0 ou :: significa todos os enderezos, mentres que un enderezo concreto significa só ese. Se a un servidor lle cambiaron o enderezo, un oínte aínda fixado a un enderezo retirado é exactamente a falla que detecta esta comprobación.

O valor configurado vive na páxina Management Service de IIS Manager no nodo do servidor, e detrás dela en administration.config baixo o directorio de configuración inetsrv. Compare as dúas cousas: o que di o ficheiro e a que está realmente vinculado o socket.

Despois execute Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed desde o cliente VPN afectado e lea o enderezo resolto e o enderezo de orixe seleccionado. Unha resposta DNS distinta na VPN é o bastante habitual como para descartala pronto. Garde ese nome de host e ese porto exactos no ticket, porque unha comparación posterior con outro nome non demostra nada sobre o cambio que fixo.

Lea o enderezo de orixe que ve o servidor

As restricións IPv4 do WMSVC avalíanse contra o enderezo que chega ao servidor, que non sempre é o enderezo que o seu portátil cre ter. Se o conxunto VPN se traduce nalgún punto do camiño, o servidor ve o enderezo traducido e unha lista de permitidos construída a partir do enderezo interno do cliente rexeitarao. Ese rexeitamento parece un fallo de conexión desde o lado do cliente, e por iso se diagnostica mal como un problema de encamiñamento.

Use a saída detallada da proba TCP e a propia táboa de conexións do servidor para ver que enderezo de orixe chegou realmente antes de editar a lista de restricións.

Cambie a vinculación como un cambio de servizo

O WMSVC debe deterse antes de editar a súa configuración, así que planifíqueo como un cambio con outra vía de administración dispoñible, como acceso por consola ou unha sesión remota que non dependa de IIS Manager. Deteña o servizo, aplique o cambio de enderezo, porto ou certificado, logo inícieo e confirme que o oínte se moveu. Calquera outra persoa que use administración remota de IIS perderá a súa sesión durante esa xanela. Avise aos demais administradores antes de que se abra a xanela; descubrilo a metade do cambio é como dúas persoas acaban editando o mesmo oínte.

Escoller todos os enderezos é unha opción lexítima, pero trátea como unha decisión de acceso e non como un atallo. Ampliar o oínte mentres a lista de restricións segue aberta é como un punto final de administración acaba exposto nunha rede que ninguén pretendía. Se o servidor ten varias tarxetas de rede, limite o oínte á interface de administración, deixe o camiño de datos en paz e confirme que o sitio segue respondendo no seu propio enderezo.

O certificado que presenta o WMSVC escóllese por separado dos certificados do sitio. Se cambia o enderezo, confirme que o certificado segue coincidindo co nome de host que usan os clientes, ou a conexión fallará máis adiante no paso TLS cunha queixa que non ten nada que ver co encamiñamento.

Separe a accesibilidade da confianza e dos permisos

Unha vez que TCP funciona, as fallas restantes están ordenadas: confianza TLS do certificado de administración, despois autenticación de Windows, despois os permisos de IIS Manager concedidos a esa conta. Cada unha produce un erro distinto, e ningunha se arranxa cunha ruta nin cunha regra de devasas. Lea o texto do erro literalmente en lugar de reiniciar o servizo outra vez.

Faga as catro comprobacións nesa orde, punto final, oínte, enderezo de orixe, confianza, e normalmente atopará a vinculación obsoleta antes de atopar un problema de rede.