Välityspalvelimen valvojan tilan ja paluukoodien tulkinta
Raportoi komennon suoritus, HTTP-tulos ja varmenteen validointi erikseen välityspalvelimen kautta tehtävässä verkkosivuston tarkistuksessa.
Kääre ei voi muuttaa lataajan nollapaluukoodia havainnoiduksi „HTTP 200 OK“ -vastaukseksi. Kirjaa, mitä kukin kerros todella ilmoitti:
| Kenttä | Vastattava kysymys |
|---|---|
| Työkalun tai lisäosan paluukoodi | Suoritettiinko tarkistus ja mitä vikaluokkaa se ilmoitti? |
| Välityspalvelimen neuvottelu | Hyväksyttiinkö välitys tai pyydetty tunneli? |
| Alkuperän tila ja odotettu sisältö | Palauttiko sovellus aiotun tuloksen? |
| TLS-validointi | Onnistuivatko määritetyt identiteettitarkistukset? |
curl voi yleensä palauttaa nollan HTTP-virhevastauksen jälkeen. Sen fail-asetukset muuttavat paluukäyttäytymistä, mutta virhepaluu ei silti yksilöi tilaa. Myös Wgetin paluuarvot ovat luokkia: todennusvirhe ei ole oma arvo HTTP 401:lle, eikä palvelinvirheluokka yksilöi kaikkia sen sisäisiä vastauksia. Tarkistuksen, joka odottaa 401:tä, on havaittava kyseinen vastaus.
Pidä välityspalvelimen päätepiste ja sivuston nimi erillään. HTTP-välityspalvelintarkistuksen TCP-vastapuoli on välityspalvelin; CONNECT nimeää kohteen, jonka TLS-istunto kulkee sitten tunnelin sisällä. HTTPS-välityspalvelimessa ulkoisen välityspalvelimen luottamus on toinen varmennetarkistus.
Tutki lisäosan takuu ennen kuin pidät SSL-lippua todentamisena. Monitoring Plugins poistaa check_http käytöstä check_curl:n hyväksi. check_http:n dokumentaatio varoittaa, että pelkän SSL:n valinta ei todenna isäntänimeä eikä myöntäjän luottamusta; check_curlin dokumentoitu verify-peer-asetus sisältää kyseisen todentamisen.
Käytä myös aiottua todennettua reittiä. Porttitunnistin voi pysyä vihreänä, vaikka operatiivinen tili saa 407:n. Toimita sen salaisuus käyttöönoton asianmukaisella mekanismilla ja raportoi vaihe, joka todella epäonnistui: evätty tunneli vaatii eri korjauksen kuin odottamaton sivuston tila.