IIS Manager sa malayo: unahin ang pagsuri sa sariling address ng WMSVC

Sumasagot ang iyong site sa 443 sa pamamagitan ng tunnel, at hindi pa rin makakonekta ang IIS Manager sa server. Ang pares ng resultang ito ay hindi kontradiksyon, dahil ang website at ang endpoint ng remote administration ay dalawang listener na may dalawang configuration at dalawang set ng access rules. Ang para sa pamamahala ay kabilang sa Web Management Service, WMSVC, at may sariling address, port, certificate at IPv4 restrictions. Suriin ang endpoint na iyon bago mo hawakan kahit isang ruta.

Dalawang listener, dalawang magkaibang problema

Ang kahilingan sa site ay umaabot sa HTTP.sys binding ng site na iyon, na tinutukoy ayon sa site at protocol sa applicationHost configuration. Ang kahilingan mula sa IIS Manager ay umaabot sa WMSVC, na bilang default ay sumasagot ng HTTPS sa TCP 8172 at naka-configure sa antas ng server. Walang anuman sa binding ng site ang nagbabago kung saan nakikinig ang WMSVC, at walang anuman sa WMSVC ang nagbabago kung aling address ang sinasagot ng site. Nagbabahagi sila ng isang makina at isang certificate store, at doon nagtatapos ang pagkakatulad.

Kaya ang matagumpay na Test-NetConnection sa port 443 ay nagsasabi na ang listener ng site ay maabot, at wala tungkol sa pamamahala.

Hanapin ang address kung saan talaga nakatali ang WMSVC

Tanungin ang server kung ano ang pinakikinggan nito ngayon, hindi kung ano ang na-configure maraming taon na ang nakalipas. Ini-print ng Get-NetTCPConnection -LocalPort 8172 -State Listen ang lokal na address, at ang value na 0.0.0.0 o :: ay nangangahulugang lahat ng address, habang ang partikular na address ay nangangahulugang iyon lamang. Kung nagbago ang addressing ng isang server, ang listener na nakakabit pa rin sa retiradong address ay eksaktong sira na nahuhuli ng check na ito.

Ang naka-configure na value ay nasa pahina ng Management Service ng IIS Manager sa node ng server, at sa likod nito sa administration.config sa inetsrv configuration directory. Ihambing ang dalawa: ano ang sinasabi ng file, at ano ang aktwal na nakakabit sa socket.

Pagkatapos ay patakbuhin ang Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed mula sa apektadong VPN client at basahin ang naresolba na address at ang napiling source address. Ang ibang sagot ng DNS sa VPN ay karaniwan lang para sulitin ang maagang pagbubukod. Itago ang eksaktong hostname at port sa ticket, dahil ang paghahambing mamaya sa ibang pangalan ay walang pinapatunayan tungkol sa pagbabagong ginawa mo.

Basahin ang source address na nakikita ng server

Ang IPv4 restrictions ng WMSVC ay sinusuri laban sa address na dumarating sa server, na hindi palaging ang address na inaakala ng iyong laptop na mayroon ito. Kung ang VPN pool ay isinalin saanman sa ruta, nakikita ng server ang isinaling address at ang allow list na binuo mula sa panloob na address ng client ay tatanggihan ito. Ang pagtanggi na iyon ay mukhang pagkabigo ng koneksyon mula sa panig ng client, kaya madalas itong mali ang diagnosis bilang problema sa routing.

Gamitin ang detalyadong output ng TCP test, kasama ang sariling talahanayan ng koneksyon ng server, para makita kung aling source address ang aktwal na dumating bago mo i-edit ang listahan ng paghihigpit.

Baguhin ang binding bilang pagbabago ng serbisyo

Kailangang ihinto ang WMSVC bago i-edit ang configuration nito, kaya planuhin ito bilang pagbabago na may ibang available na landas ng pamamahala, tulad ng console access o remote session na hindi umaasa sa IIS Manager. Ihinto ang serbisyo, ilapat ang pagbabago sa address, port o certificate, pagkatapos ay simulan ito at kumpirmahin na gumalaw ang listener. Ang sinumang iba na gumagamit ng remote IIS administration ay nawawalan ng session sa window na iyon. Sabihan ang ibang administrators bago magbukas ang window; ang matuklasan ito sa gitna ng pagbabago ay kung paano nagtatapos ang dalawang tao na nag-e-edit ng parehong listener.

Ang pagpili ng lahat ng address ay lehitimong opsyon, ngunit ituring ito bilang desisyon sa access at hindi shortcut. Ang pagpapalawak ng listener habang bukas ang listahan ng paghihigpit ay kung paano nagtatapos ang isang management endpoint na nakalantad sa network na walang sinuman ang nag-intindi. Kung ang server ay may ilang NIC, limitahan ang listener sa management interface, hayaang mapayapa ang data path, at kumpirmahin na sumasagot pa rin ang site sa sarili nitong address.

Ang certificate na ipinakikita ng WMSVC ay pinipili nang hiwalay sa mga certificate ng site. Kung babaguhin mo ang address, kumpirmahin na tumutugma pa rin ang certificate sa hostname na ginagamit ng mga client, kung hindi ay mabibigo ang koneksyon mamaya sa TLS step na may reklamong walang kaugnayan sa routing.

Paghiwalayin ang maabot mula sa tiwala at mga pahintulot

Kapag nagtagumpay ang TCP, ang natitirang mga pagkabigo ay nakaayos: TLS trust para sa management certificate, pagkatapos ay Windows authentication, pagkatapos ay ang mga pahintulot ng IIS Manager na ibinigay sa account na iyon. Bawat isa ay gumagawa ng ibang error, at wala sa kanila ang naaayos ng ruta o firewall rule. Basahin ang teksto ng error nang literal sa halip na muling simulan ang serbisyo.

Gawin ang apat na pagsusuri sa ayos na iyon, endpoint, listener, source address, tiwala, at karaniwang makikita mo ang lipas na binding bago ka makakita ng problema sa network.