Creo que he descubierto un problema muy extraño y limitado relacionado con un problema de interoperabilidad con IIS y WINRM ejercido por Powershell en Windows 10.
Tengo un dispositivo que tiene un sitio IIS vinculado exclusivamente a la dirección de host local, 127.0.0.1. Cuando se configura de esta manera, usar "localhost" en la barra de direcciones del navegador no funciona; la conexión será rechazada o reiniciada. Solo se puede acceder al sitio 127.0.0.1 (explícitamente). Este problema se resuelve agregando 127.0.0.1 a la lista de iplisten mediante el comando "netsh http add iplisten". Una vez hecho esto, el sitio vinculado al host local funciona. Hasta ahora, todo bien.
Pero aquí es donde se vuelve peculiar. En el momento en que se agrega la dirección del host local a la lista iplisten, los comandos remotos a través de Powershell (invoke-command --> winrm) dejan de funcionar. En el dispositivo, pruebe winrm contra supúblicoLa dirección IP ahora falla. "winrm quickconfig" indica que el dispositivo ya está configurado para control remoto y está funcionando correctamente. PeroNoLos comandos remotos funcionan y todos informan que "no se puede alcanzar el destino". Al consultar a los oyentes en el dispositivo de destino, se muestran todos los puntos finales apropiados definidos y la configuración para que RM sea la esperada; todo parece así.deberíatrabajar. No hay cortafuegos que bloqueen el acceso.
¿La solución? Eliminar 127.0.0.1 de la lista iplisten en el dispositivo de destino elimina instantáneamente el problema y los comandos powershell/remote comienzan a funcionar. Pero luego volvemos al problema original; "localhost" en el navegador falla. Como solución alternativa, puedo crear un "alias" DNS falso en los hosts que apunten a 127.0.0.1, pero, si es posible, preferiría no tener que meterme con los hosts.
Me parece que esto es, en realidad, un problema/error en la resolución mínima de la red en el dispositivo de destino; agregar la dirección 127.0.0.1 a la lista iplisten explícita no debería interrumpir las conexiones WinRM remotas a través de una dirección completamente diferente. Parecería que esto es, sin darse cuenta, una rutatodotráfico HTTP a IIS, y cuando se le envía un comando remoto, IIS obviamente lo recibe "primero", no tiene ningún vínculo (a través del puerto 5985), no tiene idea de qué hacer con él y lo descarta, lo que provoca que el control remoto comando para fallar. En realidad, me parece que IIS nunca debería verlo; pero agregar la dirección de bucle invertido a la lista iplisten enruta dicho tráfico precisamente de esa manera.
¿Hay algo que me falta o no entiendo acerca de cómo se enruta el tráfico, o algún aspecto de esta configuración que simplemente he pasado por alto? SI me he saltado algún paso adicional, agradecería que me indiquen cómo resolverlo.