Я считаю, что обнаружил очень странную, узкую проблему, связанную с проблемой взаимодействия с IIS и WINRM, реализуемой Powershell в Windows 10.
У меня есть устройство, на котором сайт IIS привязан исключительно к адресу localhost, 127.0.0.1. При такой настройке использование "localhost" в адресной строке браузера не работает; соединение будет либо отклонено, либо сброшено. Доступ к сайту возможен только по адресу 127.0.0.1 (явно). Эта проблема решается добавлением 127.0.0.1 в список iplisten с помощью команды "netsh http add iplisten". После этого привязанный к localhost сайт работает. Пока все хорошо.
Но вот где все становится странно. В тот момент, когда адрес localhost добавляется в список 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 направляет такой трафик именно таким образом.
Есть ли что-то, что я упускаю или не понимаю в том, как маршрутизируется трафик, или какой-то аспект этой настройки я просто упустил? ЕСЛИ есть какой-то дополнительный шаг, который я упустил, я был бы признателен за указания по его решению.