Windows 10의 Powershell에서 실행되는 IIS 및 WINRM의 상호 운용성 문제와 관련하여 매우 이상하고 좁은 문제를 발견했다고 생각합니다.
로컬 호스트 주소 127.0.0.1에만 바인딩된 IIS 사이트가 있는 장치가 있습니다. 이러한 방식으로 구성하면 브라우저 주소 표시줄에서 "localhost"를 사용할 수 없습니다. 연결이 거부되거나 재설정됩니다. 이 사이트는 127.0.0.1(명시적으로)에만 액세스할 수 있습니다. 이 문제는 "netsh http add ilisten" 명령을 통해 ilisten 목록에 127.0.0.1을 추가하면 해결됩니다. 완료되면 localhost 바인딩 사이트가 작동합니다. 여태까지는 그런대로 잘됐다.
그런데 여기서 좀 이상해집니다. localhost 주소가 ilisten 목록에 추가되는 순간 Powershell(invoke-command --> winrm)을 통한 원격 명령의 작동이 중지됩니다. 장치에서 해당 장치에 대해 test-winrm을 수행합니다.공공의이제 IP 주소가 실패합니다. "winrm Quickconfig"는 장치가 이미 원격용으로 구성되어 있고 올바르게 작동하고 있음을 나타냅니다. 하지만아니요원격 명령이 작동하고 모두 "대상에 도달할 수 없습니다."라고 보고합니다. 대상 장치의 리스너를 쿼리하면 정의된 모든 적절한 엔드포인트와 RM에 대한 구성이 예상대로 표시됩니다. 모두 그렇게 보입니다.~해야 한다일하다. 액세스를 차단하는 방화벽이 없습니다.
해결책? 대상 장치의 ilisten 목록에서 127.0.0.1을 제거하면 문제가 즉시 제거되고 powershell/remote 명령이 작동하기 시작합니다. 그러나 우리는 원래의 문제로 돌아갑니다. 브라우저의 "localhost"가 실패합니다. 해결 방법으로 호스트에 127.0.0.1을 다시 가리키는 가짜 DNS "별칭"을 만들 수 있지만 가능하다면 호스트를 엉망으로 만들 필요가 없습니다.
제가 보기에는 이것이 실제로 대상 장치의 최소 네트워크 해상도에 문제가 있는 문제/버그인 것 같습니다. 명시적인 ilisten 목록에 127.0.0.1 주소를 추가해도 완전히 다른 주소를 통한 원격 WinRM 연결이 중단되어서는 안 됩니다. 이것은 의도치 않게 라우팅인 것 같습니다.모두IIS에 대한 HTTP 트래픽과 원격 명령이 전송되면 IIS는 분명히 이를 "먼저" 가져오고 이에 대한 바인딩이 없으며(포트 5985를 통해) 어떻게 해야 할지 모르고 폐기합니다. 실패하라는 명령. 실제로는 IIS가 이를 결코 볼 수 없을 것 같습니다. 그러나 ilisten 목록에 루프백 주소를 추가하면 해당 트래픽이 정확하게 그 방식으로 라우팅됩니다.
트래픽이 라우팅되는 방식에 대해 내가 놓치거나 이해하지 못하는 것이 있습니까? 아니면 단순히 간과했던 이 설정의 일부 측면이 있습니까? 제가 놓친 추가 단계가 있는 경우 이를 해결하도록 지시해 주시면 감사하겠습니다.