Windows 10 上の Powershell によって実行される IIS と WINRM の相互運用性の問題に関連する、非常に奇妙で限定的な問題を発見したと思います。
私のデバイスには、ローカルホスト アドレス 127.0.0.1 に排他的にバインドされた IIS サイトがあります。このように構成すると、ブラウザーのアドレス バーで「localhost」を使用しても機能せず、接続が拒否されるかリセットされます。サイトには 127.0.0.1 (明示的に) からのみアクセスできます。この問題は、「netsh http add iplisten」コマンドを使用して 127.0.0.1 を iplisten リストに追加することで解決します。これを実行すると、ローカルホストにバインドされたサイトが機能します。ここまでは順調です。
しかし、ここで奇妙なことが起こります。ローカルホストのアドレスがiplistenリストに追加された瞬間、Powershell経由のリモートコマンド（invoke-command --> winrm）が機能しなくなります。デバイス上で、test-winrmをその公共IPアドレスが失敗しました。「winrm quickconfig」は、デバイスがすでにリモート用に構成されており、正常に動作していることを示します。しかしいいえリモートコマンドは機能し、すべて「宛先に到達できません」と報告します。ターゲットデバイスのリスナーを照会すると、適切なエンドポイントがすべて定義され、RMの構成が期待どおりであることが示されます。すべき動作します。アクセスをブロックするファイアウォールはありません。
解決策は? ターゲット デバイスの iplisten リストから 127.0.0.1 を削除すると、問題は即座に解消され、powershell/リモート コマンドが機能し始めます。しかし、その後、元の問題に戻ってしまいます。ブラウザーの「localhost」が失敗します。回避策として、127.0.0.1 を指すホストに偽の DNS「エイリアス」を作成できますが、できればホストをいじりたくないのです。
これは実際には、ターゲットデバイス上の最小限のネットワーク解決における問題/バグであるように思われます。127.0.0.1アドレスを明示的なiplistenリストに追加しても、まったく異なるアドレスを介したリモートWinRM接続が切断されることはありません。これは、意図せずにルーティングされているようです。全てHTTP トラフィックが IIS に送信され、リモート コマンドが送信されると、IIS は明らかにそれを「最初に」取得しますが、そのコマンドに対するバインド (ポート 5985 経由) がないため、そのコマンドをどう処理すればよいか分からず、それを破棄し、リモート コマンドが失敗します。実際には、IIS はそれを見ることすらできないように思われますが、ループバック アドレスを iplisten リストに追加すると、そのようなトラフィックはまさにそのようにルーティングされます。
トラフィックのルーティング方法について私が見落としている、または理解していない点があるのでしょうか、それともこの設定で単に見落としている部分があるのでしょうか。見逃している追加の手順がある場合は、解決方法を教えていただければ幸いです。