Обвивката не може да превърне нулевия код за изход на изтеглящия инструмент в наблюдаван „HTTP 200 OK“. Записвайте какво действително е отчел всеки слой:

ПолеВъпрос, на който се отговаря
Изход на инструмента или приставкатаИзпълни ли се проверката и какъв клас отказ отчете?
Договаряне с прокситоДопуснато ли беше препращането или заявеният тунел?
Статус на източника и очаквано съдържаниеВърна ли приложението предвидения резултат?
Проверка на TLSУспешни ли бяха конфигурираните проверки на идентичността?

curl обикновено може да върне нула след отговор с HTTP грешка. Неговите fail опции променят поведението при изход, но изходът при отказ все още не определя еднозначно статуса. Изходните стойности на Wget също са категории: отказът при удостоверяване не е отделна стойност за HTTP 401, а категорията „сървърна грешка“ не определя всеки отговор в нея. Проверка, която очаква 401, трябва да наблюдава този отговор.

Дръжте крайната точка на проксито и името на сайта отделно. TCP партньорът на проверка през HTTP прокси е проксито; CONNECT посочва дестинацията, чиято TLS сесия след това тече вътре в тунела. При HTTPS прокси доверието към външното прокси е още една проверка на сертификат.

Проверете гаранцията на приставката, преди да приемете SSL флаг за проверка. Monitoring Plugins оттегля check_http в полза на check_curl. Документацията на check_http предупреждава, че изборът само на SSL не проверява името на хоста или доверието към издателя; документираната опция verify-peer на check_curl включва тази проверка.

Използвайте и предвидения удостоверен маршрут. Сонда на порт може да остане зелена, докато оперативният акаунт получава 407. Предайте тайната му чрез подходящия механизъм на внедряването и отчетете действително неуспелия етап: отказан тунел изисква различен ремонт от неочакван статус на сайта.

Подобни статии