Kā interpretēt starpniekservera monitoringa statusu un iziešanas kodus
Ziņojiet atsevišķi par komandas izpildi, HTTP rezultātu un sertifikāta validāciju vietnes pārbaudē caur starpniekserveri.
Ietinējs nevar pārvērst lejupielādētāja nulles iziešanas kodu novērotā „HTTP 200 OK“. Pierakstiet, ko katrs slānis patiešām ziņoja:
| Lauks | Atbildētais jautājums |
|---|---|
| Rīka vai spraudņa iziešana | Vai pārbaude tika izpildīta, un kādu kļūdas klasi tā ziņoja? |
| Starpniekservera sarunas | Vai pārsūtīšana vai pieprasītais tunelis tika atļauts? |
| Avota statuss un gaidītais saturs | Vai lietojumprogramma atgrieza paredzēto rezultātu? |
| TLS validācija | Vai konfigurētās identitātes pārbaudes bija veiksmīgas? |
curl parasti var atgriezt nulli arī pēc HTTP kļūdas atbildes. Tā fail opcijas maina iziešanas uzvedību, taču kļūdas iziešana joprojām viennozīmīgi neidentificē statusu. Arī Wget iziešanas vērtības ir kategorijas: autentifikācijas kļūme nav atsevišķa HTTP 401 vērtība, un servera kļūdas kategorija neidentificē katru atbildi tajā. Pārbaudei, kas gaida 401, ir jānovēro šī atbilde.
Turiet starpniekservera galapunktu un vietnes nosaukumu atsevišķi. HTTP starpniekservera pārbaudes TCP partneris ir starpniekserveris; CONNECT nosauc galamērķi, kura TLS sesija pēc tam darbojas tuneļa iekšpusē. HTTPS starpniekservera gadījumā uzticēšanās ārējam starpniekserverim ir vēl viena sertifikāta pārbaude.
Izpētiet spraudņa garantiju, pirms uzskatāt SSL karodziņu par validāciju. Monitoring Plugins izņem check_http no aprites par labu check_curl. check_http dokumentācija brīdina, ka tikai SSL izvēle nepārbauda ne resursdatora nosaukumu, ne uzticēšanos izdevējam; check_curl dokumentētā verify-peer opcija ietver šo pārbaudi.
Izmantojiet arī paredzēto autentificēto ceļu. Porta zonde var palikt zaļa, kamēr operatīvais konts saņem 407. Nododiet tā noslēpumu ar atbilstošu izvietošanas mehānismu un ziņojiet posmu, kas patiešām neizdevās: noraidīts tunelis prasa citu labojumu nekā negaidīts vietnes statuss.