Raskite nepavykusią užklausą Squid žurnaluose
Naudokite access.log operacijų rezultatams ir cache.log paties Squid gedimams, atskirdami tunelio būseną nuo paskirties būsenos.
Debian Squid 6 pakete pradėkite nuo įprastų operacijų ir tarnybos žurnalų:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logPasirinktinis žurnalų rašymas arba tarnybų tvarkyklė gali siųsti juos kitur. Pakartokite vieną ribotos apimties užklausą iš žinomo šaltinio ir užrašykite laiką, metodą bei paskirtį, kad rastumėte teisingą įrašą.
| Įrodymas | Ką iš jo perskaityti |
|---|---|
| Rezultatas vietiniu access.log formatu | Squid rezultato kodas ir HTTP būsena yra atskiros operacijos dalys. |
| Prieigos hierarchijos informacija | Kaip persiuntimas naudojo aukštesnį įgaliotąjį serverį ar kitą maršrutą. |
| Sėkmingas CONNECT | Tunelis atidarytas; tai nėra vėlesnė svetainės būsena užšifruoto TLS viduje. |
| cache.log | Paties Squid pagalbinių programų, paleidimo, vardų sprendiklio ir konfigūracijos gedimai. |
Jei atitinkančios užklausos nėra, patvirtinkite, kad šis klientas pasiekė šį veikiantį egzempliorių ir klausymo tašką. Patikrinkite žurnalų ACL, buferizavimą, rotaciją ir ar operacija vis dar aktyvi; ilgalaikis tunelis dar gali neturėti galutinio prieigos įrašo. Apėjimas ar senesnis įgaliotojo serverio procesas gali siųsti srautą kitur, todėl prieš keisdami prieigos politiką susiekite klausantį procesą su jo įkelta konfigūracija.
Bendrinkite atitinkamą operaciją su paslėptais jautriais duomenimis ir greta esančias klaidas. URL, užklausos, šaltinių adresai ir naudotojų vardai gali būti privatūs; visų žurnalų išvedimas ar visų antraščių registravimo įjungimas be konkretaus poreikio didina atskleidimą, o ne naudingų įrodymų kiekį.