Cred că am descoperit o problemă foarte ciudată, îngustă, legată de o problemă de interoperabilitate cu IIS și WINRM exercitată de Powershell pe Windows 10.
Am un dispozitiv care are un site IIS legat exclusiv la adresa localhost, 127.0.0.1.Când este configurat în acest mod, utilizarea „localhost” în bara de adrese a browserului nu funcționează; conexiunea va fi fie refuzată, fie resetată. Site-ul poate fi accesat doar 127.0.0.1 (în mod explicit). Această problemă este rezolvată prin adăugarea 127.0.0.1 la lista iplisten prin comanda „netsh http add iplisten”. După aceasta, site-ul legat de localhost funcționează. Până acum, bine.
Dar aici devine ciudat. În momentul în care adresa localhost este adăugată la lista iplisten, comenzile de la distanță prin Powershell (invoke-command --> winrm) nu mai funcționează. Pe dispozitiv, testați-winrm împotriva acestuia public Adresa IP acum eșuează. „winrm quickconfig” indică că dispozitivul este deja configurat pentru telecomandă și funcționează corect. Dar Nu comenzile de la distanță funcționează, toate raportând „destinația nu poate fi atinsă”. Interogarea ascultătorilor de pe dispozitivul țintă arată toate punctele finale adecvate definite și configurația pentru ca RM să fie așa de așteptat - totul arată ca așa ar trebui să muncă. Nu există firewall-uri care să blocheze accesul.
Soluția? Eliminarea 127.0.0.1 din lista iplisten de pe dispozitivul țintă elimină instantaneu problema, iar comenzile powershell/la distanță încep să funcționeze. Dar apoi ne întoarcem la problema inițială; „localhost” din browser eșuează. Ca o soluție, pot crea un „alias” DNS fals în gazde care indică înapoi la 127.0.0.1, dar chiar aș prefera să nu trebuiască să mă încurc cu gazdele, dacă este posibil.
Mi se pare că acesta este, în realitate, un sughiț/bug în rezoluția minimă a rețelei pe dispozitivul țintă; adăugarea adresei 127.0.0.1 la lista explicită iplisten nu ar trebui să întrerupă conexiunile WinRM la distanță la o adresă complet diferită. S-ar părea că aceasta este, din neatenție, rutare toate Trafic HTTP către IIS și, atunci când i se trimite o comandă de la distanță, IIS îl primește în mod evident „în primul rând”, nu are nicio legătură pentru el (pe portul 5985), nu are idee ce să facă cu ea și o renunță, provocând telecomandă comanda să eșueze.În realitate, mi se pare că IIS nu ar trebui să-l vadă niciodată; dar adăugarea adresei de loopback la lista iplisten direcționează astfel de trafic tocmai așa.
Există ceva care îmi lipsește sau nu înțeleg despre modul în care este direcționat traficul sau un aspect al acestei configurații pe care pur și simplu l-am trecut cu vederea? DACĂ există un pas suplimentar pe care l-am ratat, aș aprecia direcția de a-l rezolva.
