IIS Manager távoli adminisztráció: először a WMSVC saját címét ellenőrizze

Az oldala 443-on válaszol az alagúton keresztül, és az IIS Manager mégsem tud csatlakozni a kiszolgálóhoz. Ez a két eredmény nem ellentmondás, mert a webhely és a távoli adminisztráció végpontja két figyelő, két konfigurációval és két hozzáférési szabálykészlettel. Az adminisztrációs figyelő a Web Management Service-hez, azaz a WMSVC-hez tartozik, és saját címe, portja, tanúsítványa és IPv4-korlátozásai vannak. Ellenőrizze ezt a végpontot, mielőtt egyetlen útvonalhoz is hozzányúlna.

Két figyelő, két különböző probléma

A webhelyre érkező kérés az adott webhely HTTP.sys kötéséhez érkezik, amelyet webhelyenként és protokollonként az applicationHost konfiguráció határoz meg. Az IIS Managerből érkező kérés a WMSVC-hez érkezik, amely alapértelmezés szerint HTTPS-sel válaszol a TCP 8172-es porton, és kiszolgálói szinten konfigurálható. Semmi a webhely kötésében nem változtatja meg, hol figyel a WMSVC, és semmi a WMSVC-ben nem változtatja meg, melyik címen válaszol a webhely. Egy gépet és egy tanúsítványtárat osztanak meg, és itt véget ér a hasonlóság.

Tehát egy sikeres Test-NetConnection a 443-as porton azt mondja, hogy a webhely figyelője elérhető, és semmit sem mond az adminisztrációról.

Keresse meg a címet, amelyhez a WMSVC valójában kötve van

Kérdezze meg a kiszolgálót, most mit figyel, ne azt, hogy évekkel ezelőtt mit figyelni konfigurálták. Get-NetTCPConnection -LocalPort 8172 -State Listen kiírja a helyi címet, és a 0.0.0.0 vagy :: érték minden címet jelent, míg egy konkrét cím csak azt jelenti. Ha egy kiszolgáló címzését megváltoztatták, a már kivont címhez még mindig rögzített figyelő pontosan az a hiba, amelyet ez az ellenőrzés elkap.

A konfigurált érték az IIS Manager Management Service oldalán található a kiszolgáló csomópontján, mögötte pedig a administration.config fájlban, az inetsrv konfigurációs könyvtárban. Hasonlítsa össze a kettőt: mit mond a fájl, és mihez van a socket valójában kötve.

Ezután futtassa a Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed az érintett VPN-ügyfélen, és olvassa le a feloldott címet és a kiválasztott forráscímet. A VPN-en keresztüli eltérő DNS-válasz elég gyakori ahhoz, hogy érdemes legyen korán kizárni. Jegyezze fel a jegybe pontosan azt a gazdagépnevet és portot, mert egy későbbi, más névvel való összehasonlítás semmit sem bizonyít az elvégzett változtatásról.

Olvassa le a forráscímet, amelyet a kiszolgáló lát

A WMSVC IPv4-korlátozásait a kiszolgálóhoz érkező címhez mérik, és ez nem mindig az a cím, amelyről a laptopja azt hiszi, hogy rendelkezik vele. Ha a VPN-készlet valahol az útvonalon lefordításra kerül, a kiszolgáló a lefordított címet látja, és az ügyfél belső címéből épített engedélyezési lista elutasítja. Ez az elutasítás az ügyfél oldaláról kapcsolódási hibának tűnik, ezért tévesen útválasztási problémaként diagnosztizálják.

Használja a TCP-teszt részletes kimenetét és a kiszolgáló saját kapcsolattábláját, hogy lássa, melyik forráscím érkezett meg valójában, mielőtt szerkeszti a korlátozási listát.

A kötést szolgáltatásváltozásként módosítsa

A WMSVC-t le kell állítani a konfiguráció szerkesztése előtt, ezért tervezze ezt olyan változásként, amelynél más adminisztrációs útvonal is elérhető, például konzolhozzáférés vagy olyan távoli munkamenet, amely nem függ az IIS Managertől. Állítsa le a szolgáltatást, alkalmazza a cím-, port- vagy tanúsítványváltozást, majd indítsa el, és erősítse meg, hogy a figyelő elmozdult. Mindenki más, aki távoli IIS-adminisztrációt használ, elveszíti a munkamenetét ebben az ablakban. Szóljon a többi adminisztrátornak, mielőtt az ablak kinyílik; a változás közepén felfedezni ezt az, ahogy két ember ugyanazt a figyelőt kezdi szerkeszteni.

Az összes cím kiválasztása jogszerű lehetőség, de kezelje hozzáférési döntésként, nem rövidítésként. A figyelő kiszélesítése miközben a korlátozási lista nyitva marad az, ahogy egy adminisztrációs végpont olyan hálózaton kerül ki, amelyet senki sem szándékozott. Ha a kiszolgálónak több hálózati kártyája van, korlátozza a figyelőt az adminisztrációs felületre, hagyja békén az adatútvonalat, és erősítse meg, hogy a webhely továbbra is a saját címén válaszol.

A WMSVC által bemutatott tanúsítvány a webhely tanúsítványaitól külön választódik. Ha megváltoztatja a címet, erősítse meg, hogy a tanúsítvány továbbra is megfelel az ügyfelek által használt gazdagépnévnek, különben a kapcsolat később a TLS-lépésnél meghiúsul egy olyan panasszal, amelynek semmi köze az útválasztáshoz.

Válassza szét az elérhetőséget a bizalomtól és a jogosultságoktól

Miután a TCP sikerül, a fennmaradó hibák sorrendben vannak: TLS-bizalom az adminisztrációs tanúsítványhoz, majd Windows-hitelesítés, majd az adott fióknak adott IIS Manager-jogosultságok. Mindegyik más hibát ad, és egyiket sem javítja útvonal vagy tűzfal-szabály. Olvassa szó szerint a hiba szövegét, ahelyett hogy újraindítaná a szolgáltatást.

Végezze el a négy ellenőrzést ebben a sorrendben, végpont, figyelő, forráscím, bizalom, és általában hamarabb megtalálja az elavult kötést, mint egy hálózati problémát.