Tumačenje statusa i izlaznih kodova proxy nadzornika
Prijavite izvršavanje naredbe, HTTP ishod i provjeru certifikata odvojeno u provjeri web-mjesta preko proxyja.
Omotač ne može pretvoriti nulti izlazni kod preuzimatelja u opaženi „HTTP 200 OK“. Zabilježite što je svaki sloj doista prijavio:
| Polje | Pitanje na koje odgovara |
|---|---|
| Izlaz alata ili dodatka | Je li se provjera izvršila i koju je klasu kvara prijavila? |
| Pregovaranje s proxyjem | Je li prosljeđivanje ili traženi tunel odobren? |
| Status izvora i očekivani sadržaj | Je li aplikacija vratila namjeravani rezultat? |
| TLS validacija | Jesu li konfigurirane provjere identiteta uspjele? |
curl obično može vratiti nulu nakon HTTP odgovora s greškom. Njegove fail opcije mijenjaju ponašanje pri izlazu, ali izlaz zbog kvara i dalje ne identificira status jednoznačno. Wgetove izlazne vrijednosti također su kategorije: neuspjeh autentifikacije nije zasebna vrijednost za HTTP 401, a kategorija poslužiteljske greške ne identificira svaki odgovor unutar nje. Provjera koja očekuje 401 mora opaziti taj odgovor.
Držite proxy krajnju točku i naziv web-mjesta odvojeno. TCP partner provjere preko HTTP proxyja je proxy; CONNECT imenuje odredište, čija TLS sesija zatim teče unutar tunela. Kod HTTPS proxyja povjerenje u vanjski proxy je još jedna provjera certifikata.
Ispitajte jamstvo dodatka prije nego SSL zastavicu shvatite kao verifikaciju. Monitoring Plugins stavlja check_http izvan upotrebe u korist check_curl. Dokumentacija check_http upozorava da samo odabir SSL-a ne provjerava ime hosta ni povjerenje u izdavatelja; dokumentirana verify-peer opcija check_curl uključuje tu provjeru.
Koristite i predviđenu autentificiranu rutu. Sonda porta može ostati zelena dok operativni račun prima 407. Dostavite njezinu tajnu odgovarajućim mehanizmom implementacije i prijavite stvarno neuspjelu fazu: odbijen tunel zahtijeva drugačiji popravak od neočekivanog statusa web-mjesta.