IIS Manageri kaug haldamine: kontrolli kõigepealt WMSVC enda aadressi

Sinu sait vastab tunnelis pordil 443, ja IIS Manager ei saa ikkagi serveriga ühendust. Need kaks tulemust ei ole vastuolu, sest veebisait ja kaug haldamise lõpp-punkt on kaks kuulajat kahe konfiguratsiooni ja kahe juurdepääsureeglite komplektiga. Halduskuulaja kuulub veebihaldusteenusele WMSVC ja sellel on oma aadress, port, sertifikaat ja IPv4-piirangud. Kontrolli seda lõpp-punkti enne, kui puudutad ühtki marsruuti.

Kaks kuulajat, kaks erinevat probleemi

Saidi suunatud päring jõuab selle saidi HTTP.sys-sidumiseni, mis on määratletud saidi ja protokolli kaupa applicationHost konfiguratsioonis. IIS Managerist tulev päring jõuab WMSVC-ni, mis vaikimisi vastab HTTPS-iga TCP pordil 8172 ja mida konfigureeritakse serveri tasandil. Miski saidi sidumises ei muuda, kus WMSVC kuulab, ja miski WMSVC-s ei muuda, millisel aadressil sait vastab. Nad jagavad ühte masinat ja ühte sertifikaadihoidlat, ja seal sarnasus lõpeb.

Nii et õnnestunud Test-NetConnection pordil 443 ütleb, et saidi kuulaja on kättesaadav, ja mitte midagi halduse kohta.

Leia aadress, millega WMSVC tegelikult seotud on

Küsi serverilt, mida see praegu kuulab, mitte mida see aastaid tagasi kuulama seadistati. Get-NetTCPConnection -LocalPort 8172 -State Listen prindib kohaliku aadressi, ja väärtus 0.0.0.0 või :: tähendab kõiki aadresse, samas kui konkreetne aadress tähendab ainult seda. Kui serveri adresseerimist on muudetud, on kasutusest kõrvaldatud aadressi külge kinni jäänud kuulaja täpselt see rike, mille see kontroll tabab.

Konfigureeritud väärtus asub serveri sõlme IIS Manageri lehel Management Service ja selle taga failis administration.config kaustas inetsrv. Võrdle mõlemat: mida fail ütleb ja millega pistikupesa tegelikult seotud on.

Seejärel käivita Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed mõjutatud VPN-kliendist ja loe lahendatud aadress ning valitud lähteaadress. VPN-i kaudu erinev DNS-vastus on piisavalt tavaline, et seda varakult välistada. Jäta piletisse täpselt see hostinimi ja port, sest hilisem võrdlus teise nimega ei tõesta muudatuse kohta midagi.

Loe lähteaadress, mida server näeb

WMSVC IPv4-piiranguid hinnatakse serverile saabuva aadressi järgi, ja see ei ole alati aadress, mille sinu sülearvuti arvab endal olevat. Kui VPN-i aadressikogu kusagil teel tõlgitakse, näeb server tõlgitud aadressi ja kliendi sisaadressist koostatud lubatud loend keeldub sellest. See keeldumine näeb kliendi poolelt välja nagu ühenduse rike, mistõttu diagnoositakse see ekslikult marsruutimisprobleemina.

Kasuta TCP-testi üksikasjalikku väljundit ja serveri enda ühendustabelit, et näha, milline lähteaadress tegelikult saabus, enne kui muudad piirangute loendit.

Muuda sidumist teenusemuudatusena

WMSVC tuleb enne konfiguratsiooni muutmist peatada, seega planeeri see muudatusena, mille jaoks on olemas teine haldustee, näiteks konsoolijuurdepääs või kaugseanss, mis ei sõltu IIS Managerist. Peata teenus, rakenda aadressi, pordi või sertifikaadi muudatus, seejärel käivita see ja kinnita, et kuulaja liikus. Iga teine, kes kasutab IIS-i kaug haldust, kaotab selle akna jooksul oma seansi. Ütle teistele administraatoritele enne akna avanemist; selle avastamine muudatuse keskel on viis, kuidas kaks inimest hakkavad sama kuulajat muutma.

Kõigi aadresside valimine on seaduslik valik, kuid käsitle seda juurdepääsuotsusena, mitte lühiühendusena. Kuulaja laiendamine piirangute loendi lahtiseks jäädes on viis, kuidas halduslõpp-punkt satub võrku, mida keegi ei kavatsenud. Kui serveril on mitu võrgukaarti, piira kuulaja haldusliidesega, jäta andmetee rahule ja kinnita, et sait vastab endiselt oma aadressil.

Sertifikaat, mida WMSVC esitab, valitakse saidi sertifikaatidest eraldi. Kui muudad aadressi, kinnita, et sertifikaat vastab endiselt hostinimele, mida kliendid kasutavad, muidu ebaõnnestub ühendus hiljem TLS-i etapis kaebusega, millel pole marsruutimisega mingit seost.

Eralda kättesaadavus usaldusest ja õigustest

Kui TCP õnnestub, on ülejäänud rikked järjestatud: TLS-i usaldus haldussertifikaadi vastu, seejärel Windowsi autentimine, seejärel sellele kontole antud IIS Manageri õigused. Igaüks neist annab erineva vea ja ühtki ei paranda marsruut ega tulemüürireegel. Loe veateksti sõna-sõnalt, selle asemel et teenust uuesti käivitada.

Tee need neli kontrolli selles järjekorras, lõpp-punkt, kuulaja, lähteaadress, usaldus, ja tavaliselt leiad aegunud sidumise enne, kui leiad võrguprobleemi.