Găsește o cerere eșuată în jurnalele Squid
Folosește access.log pentru rezultatele tranzacțiilor și cache.log pentru defecțiunile Squid, distingând starea tunelului de cea a destinației.
În pachetul Squid 6 din Debian, începe cu jurnalele obișnuite ale tranzacțiilor și ale demonului:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logJurnalizarea personalizată sau un gestionar de servicii le poate trimite în altă parte. Reprodu o singură cerere cu domeniu limitat dintr-o sursă cunoscută și notează ora, metoda și destinația pentru a găsi înregistrarea corectă.
| Dovadă | Ce poți afla din ea |
|---|---|
| Rezultatul în formatul nativ access.log | Codul de rezultat Squid și starea HTTP sunt părți separate ale tranzacției. |
| Informații despre ierarhia accesului | Cum a folosit redirecționarea un proxy părinte sau o altă rută. |
| CONNECT reușit | Tunelul s-a deschis; nu este starea ulterioară a site-ului din interiorul TLS criptat. |
| cache.log | Defecțiuni ale programelor auxiliare, pornirii, rezolvatorului și configurației Squid în sine. |
Dacă nu apare o cerere corespunzătoare, confirmă că acest client a ajuns la această instanță și la acest listener. Verifică ACL-urile de jurnalizare, stocarea în buffer, rotația și dacă tranzacția este încă activă; un tunel de lungă durată poate să nu aibă încă o înregistrare finală de acces. O ocolire sau un proces proxy mai vechi poate trimite traficul în altă parte, deci asociază procesul care ascultă cu configurația încărcată înainte să modifici politica de acces.
Partajează tranzacția relevantă cu datele sensibile ascunse și erorile apropiate. URL-urile, interogările, adresele sursă și numele de utilizator pot fi private; publicarea jurnalelor întregi sau activarea înregistrării complete a antetelor fără o nevoie concretă crește expunerea, nu dovezile utile.