Ich glaube, ich habe ein sehr seltsames, eng gefasstes Problem im Zusammenhang mit einem Interoperabilitätsproblem mit IIS und WINRM entdeckt, das von Powershell unter Windows 10 verursacht wird.
Ich habe ein Gerät, dessen IIS-Site ausschließlich an die Localhost-Adresse 127.0.0.1 gebunden ist. Bei dieser Konfiguration funktioniert die Verwendung von „localhost“ in der Adressleiste eines Browsers nicht; die Verbindung wird entweder abgelehnt oder zurückgesetzt. Auf die Site kann nur über 127.0.0.1 zugegriffen werden (explizit). Dieses Problem wird gelöst, indem 127.0.0.1 über den Befehl „netsh http add iplisten“ zur IP-Liste hinzugefügt wird. Danach funktioniert die Localhost-gebundene Site. So weit, so gut.
Aber hier wird es seltsam. Sobald die Localhost-Adresse zur IP-Liste hinzugefügt wird, funktionieren Remote-Befehle über Powershell (invoke-command --> winrm) nicht mehr. Führen Sie auf dem Gerät test-winrm gegen dessenöffentlichDie IP-Adresse schlägt jetzt fehl. „winrm quickconfig“ zeigt an, dass das Gerät bereits für Remote konfiguriert ist und ordnungsgemäß funktioniert. AberNEINRemote-Befehle funktionieren, alle melden "Ziel kann nicht erreicht werden". Die Abfrage der Listener auf dem Zielgerät zeigt, dass alle entsprechenden Endpunkte definiert sind und die Konfiguration für RM wie erwartet ist - es sieht alles so aussollenfunktioniert. Es gibt keine Firewalls, die den Zugriff blockieren.
Die Lösung? Das Entfernen von 127.0.0.1 aus der IP-Liste auf dem Zielgerät behebt das Problem sofort und Powershell-/Remote-Befehle funktionieren. Aber dann sind wir wieder beim ursprünglichen Problem; „localhost“ im Browser funktioniert nicht. Als Workaround kann ich einen falschen DNS-„Alias“ in Hosts erstellen, die auf 127.0.0.1 zurückverweisen, aber ich möchte wirklich lieber nicht mit Hosts herumspielen müssen, wenn möglich.
Mir scheint, dass dies in Wirklichkeit ein Schluckauf/Fehler bei der minimalen Netzwerkauflösung auf dem Zielgerät ist; das Hinzufügen der Adresse 127.0.0.1 zur expliziten IP-Liste sollte Remote-WinRM-Verbindungen über eine völlig andere Adresse nicht unterbrechen. Es scheint, dass dies unbeabsichtigt Routing istalleHTTP-Datenverkehr zu IIS, und wenn ein Remote-Befehl an ihn gesendet wird, erhält IIS ihn offensichtlich „zuerst“, hat keine Bindung dafür (über Port 5985), weiß nicht, was damit zu tun ist, und verwirft ihn, wodurch der Remote-Befehl fehlschlägt. Eigentlich sollte IIS ihn meiner Meinung nach nie sehen; aber das Hinzufügen der Loopback-Adresse zur IP-Liste leitet diesen Datenverkehr genau auf diese Weise um.
Habe ich etwas bei der Verkehrsführung übersehen oder nicht verstanden oder habe ich einen Aspekt dieser Konfiguration einfach übersehen? Wenn ich einen weiteren Schritt übersehen habe, wäre ich für eine Anleitung zur Lösung dankbar.