Sivustosi vastaa portissa 443 tunnelin kautta, eikä IIS Manager silti saa yhteyttä palvelimeen. Nämä kaksi tulosta eivät ole ristiriidassa, koska verkkosivusto ja etähallinnan päätepiste ovat kaksi kuuntelijaa, joilla on kaksi kokoonpanoa ja kaksi joukkoa käyttösääntöjä. Hallintakuuntelija kuuluu Web Management Service -palveluun, WMSVC, ja sillä on oma osoite, portti, sertifikaatti ja IPv4-rajoitukset. Tarkista tämä päätepiste ennen kuin kosket yhteenkään reittiin.

Kaksi kuuntelijaa, kaksi eri ongelmaa

Sivustolle tuleva pyyntö saavuttaa kyseisen sivuston HTTP.sys-sidonnan, joka määritellään sivusto- ja protokollakohtaisesti applicationHost-kokoonpanossa. IIS Managerista tuleva pyyntö saavuttaa WMSVC:n, joka vastaa oletuksena HTTPS:llä TCP-portissa 8172 ja konfiguroidaan palvelintasolla. Mikään sivuston sidonnassa ei muuta sitä, missä WMSVC kuuntelee, eikä mikään WMSVC:ssä muuta sitä, millä osoitteella sivusto vastaa. Ne jakavat yhden koneen ja yhden sertifikaattivaraston, ja siihen yhtäläisyys päättyy.

Onnistunut Test-NetConnection portissa 443 siis kertoo, että sivuston kuuntelija on tavoitettavissa, eikä yhtään mitään hallinnasta.

Selvitä osoite, johon WMSVC on todella sidottu

Kysy palvelimelta, mitä se kuuntelee nyt, älä sitä, mitä se konfiguroitiin kuuntelemaan vuosia sitten. Get-NetTCPConnection -LocalPort 8172 -State Listen tulostaa paikallisen osoitteen, ja arvo 0.0.0.0 tai :: tarkoittaa kaikkia osoitteita, kun taas tietty osoite tarkoittaa vain sitä. Jos palvelimen osoitteistoa on muutettu, eläkkeelle jääneeseen osoitteeseen yhä kiinnitetty kuuntelija on täsmälleen se vika, jonka tämä tarkistus nappaa.

Konfiguroitu arvo on palvelinsolmun IIS Managerin Management Service -sivulla ja sen takana tiedostossa administration.config inetsrv-kokoonpanohakemistossa. Vertaa kahta asiaa: mitä tiedosto sanoo ja mihin pistoke on todella sidottu.

Aja sitten Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed kärsineeltä VPN-asiakkaalta ja lue ratkaistu osoite ja valittu lähdeosoite. Erilainen DNS-vastaus VPN:n yli on tarpeeksi yleistä, että se kannattaa sulkea pois varhain. Merkitse tarkalleen se isäntänimi ja portti tikettiin, koska myöhempi vertailu toiseen nimeen ei todista mitään tehdystä muutoksesta.

Lue lähdeosoite, jonka palvelin näkee

WMSVC:n IPv4-rajoitukset arvioidaan palvelimelle saapuvaa osoitetta vasten, eikä se ole aina se osoite, jonka kannettavasi uskoo itsellään olevan. Jos VPN-ryhmä käännetään jossain matkan varrella, palvelin näkee käännetyn osoitteen, ja asiakkaan sisäosoitteesta rakennettu sallittujen luettelo hylkää sen. Hylkäys näyttää asiakkaan puolelta yhteysvirheeltä, minkä vuoksi se diagnosoidaan virheellisesti reititysongelmaksi.

Käytä TCP-testin yksityiskohtaista tulostetta ja palvelimen omaa yhteystaulua nähdäksesi, mikä lähdeosoite todella saapui, ennen kuin muokkaat rajoitusluetteloa.

Muuta sidontaa palvelumuutoksena

WMSVC on pysäytettävä ennen sen kokoonpanon muokkaamista, joten suunnittele se muutoksena, jossa toinen hallintareitti on käytettävissä, esimerkiksi konsolikäyttö tai etäistunto, joka ei riipu IIS Managerista. Pysäytä palvelu, ota käyttöön osoitteen, portin tai sertifikaatin muutos, käynnistä se sitten ja varmista, että kuuntelija siirtyi. Kuka tahansa muu IIS:n etähallintaa käyttävä menettää istuntonsa tuon ikkunan aikana. Kerro muille ylläpitäjille ennen kuin ikkuna avautuu; sen löytäminen kesken muutoksen on tapa, jolla kaksi ihmistä päätyy muokkaamaan samaa kuuntelijaa.

Kaikkien osoitteiden valinta on laillinen vaihtoehto, mutta käsittele sitä käyttöpäätöksenä, älä oikotienä. Kuuntelijan laajentaminen rajoitusluettelon pysyessä avoimena on tapa, jolla hallintapäätepiste päätyy näkyviin verkossa, jota kukaan ei tarkoittanut. Jos palvelimessa on useita verkkokortteja, rajaa kuuntelija hallintaliitäntään, jätä datareitti rauhaan ja varmista, että sivusto vastaa edelleen omassa osoitteessaan.

Sertifikaatti, jonka WMSVC esittää, valitaan erikseen sivuston sertifikaateista. Jos muutat osoitetta, varmista, että sertifikaatti vastaa edelleen isäntänimeä, jota asiakkaat käyttävät, muuten yhteys epäonnistuu myöhemmin TLS-vaiheessa valitukseen, jolla ei ole mitään tekemistä reitityksen kanssa.

Erota tavoitettavuus luottamuksesta ja käyttöoikeuksista

Kun TCP onnistuu, jäljellä olevat viat ovat järjestyksessä: TLS-luottamus hallintasertifikaattiin, sitten Windows-todennus, sitten kyseiselle tilille myönnetyt IIS Manager -käyttöoikeudet. Jokainen niistä tuottaa eri virheen, eikä yhtäkään korjata reitillä tai palomuurisäännöllä. Lue virheteksti kirjaimellisesti sen sijaan, että käynnistäisit palvelun uudelleen.

Käy neljä tarkistusta siinä järjestyksessä, päätepiste, kuuntelija, lähdeosoite, luottamus, ja yleensä löydät vanhentuneen sidonnan ennen kuin löydät verkko-ongelman.

Aiheeseen liittyvät artikkelit