Acredito ter descoberto um problema muito estranho e restrito relacionado a um problema de interoperabilidade com IIS e WINRM exercido pelo Powershell no Windows 10.
Eu tenho um dispositivo que possui um site IIS vinculado exclusivamente ao endereço localhost, 127.0.0.1. Quando configurado desta forma, usar "localhost" na barra de endereço do navegador não funciona; a conexão será recusada ou redefinida. O site só pode ser acessado 127.0.0.1 (explicitamente). Este problema é resolvido adicionando 127.0.0.1 à lista iplisten por meio do comando "netsh http add iplisten". Feito isso, o site vinculado ao localhost funciona. Até agora tudo bem.
Mas é aqui que fica peculiar. No momento em que o endereço localhost é adicionado à lista iplisten, os comandos remotos via Powershell (invoke-command -> winrm) param de funcionar. No dispositivo, teste-winrm em relação ao seupúblicoO endereço IP agora falha. "winrm quickconfig" indica que o dispositivo já está configurado para remoto e funcionando corretamente. Masnãoos comandos remotos funcionam, todos informando que "o destino não pode ser alcançado". Consultar os ouvintes no dispositivo de destino mostra todos os endpoints apropriados definidos e a configuração para o RM ser conforme o esperado - tudo parece com issodevetrabalhar. Não há firewalls bloqueando o acesso.
A solução? Remover 127.0.0.1 da lista iplisten no dispositivo de destino elimina instantaneamente o problema e os comandos powershell/remote começam a funcionar. Mas então voltamos ao problema original; "localhost" no navegador falha. Como solução alternativa, posso criar um "alias" de DNS falso em hosts que apontam para 127.0.0.1, mas prefiro não ter que mexer com hosts, se possível.
Parece-me que isso é, na realidade, um soluço/bug na resolução mínima da rede no dispositivo de destino; adicionar o endereço 127.0.0.1 à lista iplisten explícita não deve interromper as conexões WinRM remotas em um endereço totalmente diferente. Parece que isso é, inadvertidamente, um roteamentotodostráfego HTTP para o IIS, e quando um comando remoto é enviado para ele, o IIS obviamente o recebe "primeiro", não tem ligação para ele (pela porta 5985), não tem ideia do que fazer com ele e o descarta, fazendo com que o controle remoto comando para falhar. Na realidade, parece-me que o IIS nunca deveria ver isso; mas adicionar o endereço de loopback à lista iplisten roteia esse tráfego exatamente dessa maneira.
Há algo que estou perdendo ou não entendo sobre como o tráfego é roteado ou algum aspecto dessa configuração que simplesmente esqueci? SE houver alguma etapa adicional que perdi, agradeceria orientação para resolvê-la.