IIS Manager op ôfstân beheare: kontrolearje earst WMSVC syn eigen adres

Jo side antwurdet op 443 troch de tunnel, en IIS Manager kin noch altyd net mei de server ferbine. Dy twa resultaten binne gjin tsjinstelling, want de webside en it einpunt foar behear op ôfstân binne twa harkers mei twa konfiguraasjes en twa sets tagongsregels. De behearharker heart by de Web Management Service, WMSVC, en hat syn eigen adres, poarte, sertifikaat en IPv4-beperkingen. Kontrolearje dat einpunt foardat jo ien route oanreitsje.

Twa harkers, twa ferskillende problemen

In fersyk nei de side berikt de HTTP.sys-binding foar dy side, dy't per side en per protokol yn 'e applicationHost-konfiguraasje definiearre wurdt. In fersyk fan IIS Manager berikt WMSVC, dat standert HTTPS antwurdet op TCP 8172 en op servernivo konfigurearre wurdt. Neat oan 'e binding fan 'e side feroaret wêr't WMSVC harket, en neat oan WMSVC feroaret op hokker adres de side antwurdet. Se diele ien masine en ien sertifikaatopslach, en dêr hâldt de oerienkomst op.

Dat in slagge Test-NetConnection op poarte 443 seit jo dat de harker fan 'e side berikber is, en hielendal neat oer behear.

Fyn it adres wêr't WMSVC echt oan ferbûn is

Freegje de server wêr't er no nei harket, net wêr't er jierren lyn foar konfigurearre wie. Get-NetTCPConnection -LocalPort 8172 -State Listen prints it lokale adres, en in wearde fan 0.0.0.0 of :: betsjut alle adressen, wylst in spesifyk adres allinnich dat betsjut. As de adressearing fan in server feroare is, is in harker dy't noch oan in ôftanke adres fêst sit krekt de flater dy't dizze kontrôle fangt.

De konfigurearre wearde stiet op 'e Management Service-side fan IIS Manager op 'e serverknooppunt, en dêrefter yn administration.config ûnder de inetsrv-konfiguraasjemap. Ferlykje de twa: wat it bestân seit, en wêr't de socket echt oan ferbûn is.

Rin dêrnei Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed fan 'e troffen VPN-klant en lês it oploste adres en it keazen boarne-adres. In oar DNS-antwurd oer de VPN is gewoan genôch om it betiid út te sluten. Hâld krekt dy hostnamme en poarte yn it ticket, want in lettere ferliking mei in oare namme bewissiget neat oer de feroaring dy't jo makke hawwe.

Lês it boarne-adres dat de server sjocht

De IPv4-beperkingen fan WMSVC wurde beoardiele tsjin it adres dat by de server oankomt, en dat is net altyd it adres dat jo laptop tinkt te hawwen. As de VPN-pool earne op it paad oersetten wurdt, sjocht de server it oersetten adres en in tastiene list dy't fan it ynterne adres fan 'e klant boud is, sil it wegerje. Dy wegering liket fan 'e kliïntkant op in ferbiningsflater, en dêrom wurdt it ferkeard diagnostearre as in routeringsprobleem.

Brûk de detaillearre útfier fan 'e TCP-test en de eigen ferbiningstabel fan 'e server om te sjen hokker boarne-adres echt oankaam foardat jo de beheiningslist bewurkje.

Feroarje de binding as in tsjinstferoaring

WMSVC moat stoppe wurde foardat de konfiguraasje bewurke wurdt, dus plan it as in feroaring mei in oare behearspaad beskikber, lykas konsoltagong of in sesje op ôfstân dy't net fan IIS Manager ôfhinklik is. Stop de tsjinst, pas de feroaring fan adres, poarte of sertifikaat ta, start it dêrnei en befêstigje dat de harker ferhuze is. Elkenien oars dy't IIS-behear op ôfstân brûkt, ferliest syn sesje yn dat finster. Fertel it de oare behearders foardat it finster iepengiet; it ûntdekke midden yn 'e feroaring is hoe't twa minsken itselde harker bewurkje.

Alle adressen kieze is in legitime opsje, mar behannelje it as in tagongsbeslissing en net as in koarte wei. It ferbreedzjen fan 'e harker wylst de beheiningslist iepen bliuwt, is hoe't in behearpunt bleat komt te stean op in netwurk dat nimmen bedoelde. As de server ferskate netwurkkaarten hat, behein de harker dan ta de behearinterface, lit it datapaad gewurde en befêstigje dat de side noch op syn eigen adres antwurdet.

It sertifikaat dat WMSVC presintearret, wurdt apart fan 'e sertifikaten fan 'e side keazen. As jo it adres feroarje, befêstigje dan dat it sertifikaat noch by de hostnamme past dy't klanten brûke, oars sil de ferbining letter by de TLS-stap mislearje mei in klacht dy't neat mei routing te meitsjen hat.

Skied berikberens fan fertrouwen en rjochten

Sadree't TCP slagget, binne de oerbleaune flaters oardere: TLS-fertrouwen foar it behearsertifikaat, dan Windows-autentikaasje, dan de IIS Manager-rjochten dy't oan dat akkount jûn binne. Elk fan dy produsearret in oare flater, en gjinien wurdt reparearre troch in route of in firewallregel. Lês de flatertekst letterlik ynstee fan 'e tsjinst opnij te starten.

Wurkje de fjouwer kontrôles yn dy oarder ôf, einpunt, harker, boarne-adres, fertrouwen, en jo sille meastentiids de ferâldere binding fine foardat jo in netwurkprobleem fine.