Я считаю, что обнаружил очень странную, узкую проблему, связанную с проблемой взаимодействия с IIS и WINRM, выполняемой Powershell в Windows 10.
У меня есть устройство, на котором сайт IIS привязан исключительно к локальному адресу 127.0.0.1.При такой настройке использование «localhost» в адресной строке браузера не работает; соединение будет либо отклонено, либо сброшено. Доступ к сайту возможен только по адресу 127.0.0.1 (явно). Эта проблема решается добавлением 127.0.0.1 в список iplisten с помощью команды «netsh http add iplisten». После этого сайт, привязанный к локальному хосту, заработает. Все идет нормально.
Но вот где это становится своеобразным. В тот момент, когда адрес локального хоста добавляется в список iplisten, удаленные команды через Powershell (invoke-command --> winrm) перестают работать. На устройстве test-winrm против его публичный IP-адрес теперь не работает. «winrm quickconfig» указывает, что устройство уже настроено для удаленного доступа и работает правильно. Но нет удаленные команды работают, все сообщают, что «пункт назначения недоступен». Запрос слушателей на целевом устройстве показывает все соответствующие определенные конечные точки и конфигурацию для RM, чтобы она соответствовала ожиданиям — все выглядит так. должен работай. Брандмауэров, блокирующих доступ, нет.
Решение? Удаление 127.0.0.1 из списка iplisten на целевом устройстве мгновенно устраняет проблему, и команды powershell/remote начинают работать. Но тогда мы возвращаемся к исходной проблеме; "localhost" в браузере не работает. В качестве обходного пути я могу создать фальшивый «псевдоним» DNS на хостах, указывающих на 127.0.0.1, но я действительно предпочел бы не связываться с хостами, если это возможно.
Мне кажется, что на самом деле это сбой / ошибка в минимальном сетевом разрешении на целевом устройстве; добавление адреса 127.0.0.1 в явный список iplisten не должно прерывать удаленные подключения WinRM через совершенно другой адрес. Казалось бы, это, ненароком, маршрутизация все HTTP-трафик к IIS, и когда ему отправляется удаленная команда, IIS, очевидно, получает ее «первой», не имеет для нее привязки (через порт 5985), понятия не имеет, что с ней делать, и отбрасывает ее, вызывая удаленную команда на провал.На самом деле мне кажется, что IIS никогда не должен его видеть; но добавление петлевого адреса в список iplisten направляет такой трафик именно таким образом.
Есть ли что-то, что я упускаю или не понимаю в том, как маршрутизируется трафик, или какой-то аспект этой настройки, который я просто упустил из виду? ЕСЛИ есть какой-то дополнительный шаг, который я пропустил, я был бы признателен за направление для его решения.
