Finn en mislykket forespørsel i Squids logger
Bruk access.log til transaksjonsresultater og cache.log til Squids egne feil, og skill tunnelstatus fra statusen til målet.
Med Debians Squid 6-pakke begynner du med de vanlige transaksjons- og daemonloggene:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logTilpasset logging eller en tjenestebehandler kan sende dem et annet sted. Gjenskap én avgrenset forespørsel fra en kjent kilde, og noter tidspunkt, metode og mål slik at du kan finne riktig oppføring.
| Bevis | Hva du kan lese ut av det |
|---|---|
| Resultat i det opprinnelige access.log-formatet | Squids resultatkode og HTTP-status er separate deler av transaksjonen. |
| Informasjon om tilgangshierarkiet | Hvordan videresendingen brukte en overordnet proxy eller en annen rute. |
| Vellykket CONNECT | Tunnelen ble åpnet; dette er ikke nettstedets senere status inne i kryptert TLS. |
| cache.log | Feil i hjelpeprogrammer, oppstart, navneoppslag og konfigurasjon i Squid selv. |
Hvis ingen samsvarende forespørsel vises, bekreft at denne klienten nådde denne instansen og lytteren. Kontroller loggings-ACL-er, bufring, rotasjon og om transaksjonen fortsatt er aktiv; en langvarig tunnel har kanskje ingen endelig tilgangsoppføring ennå. En omgåelse eller en eldre proxyprosess kan sende trafikken et annet sted, så knytt den lyttende prosessen til den innlastede konfigurasjonen før du endrer tilgangspolicyen.
Del den relevante transaksjonen med følsomme opplysninger sladdet og feilene i nærheten. URL-er, spørringer, kildeadresser og brukernavn kan være private; å dumpe hele logger eller aktivere full logging av headere uten et konkret behov øker eksponeringen fremfor å gi nyttige bevis.