Find en mislykket forespørgsel i Squids logs
Brug access.log til transaktionsresultater og cache.log til Squids egne fejl, og skeln mellem tunnelstatus og destinationens status.
Med Debians Squid 6-pakke begynder du med de sædvanlige transaktions- og daemonlogs:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logTilpasset logning eller en servicemanager kan sende dem et andet sted hen. Genskab én afgrænset forespørgsel fra en kendt kilde, og notér tidspunkt, metode og destination, så du kan finde den rigtige post.
| Bevis | Hvad du kan læse ud af det |
|---|---|
| Resultat i access.logs eget format | Squids resultatkode og HTTP-status er separate dele af transaktionen. |
| Oplysninger om adgangshierarki | Hvordan videresendelsen brugte en overordnet proxy eller en anden rute. |
| CONNECT lykkedes | Tunnelen blev åbnet; det er ikke webstedets senere status inde i krypteret TLS. |
| cache.log | Fejl i hjælpeprogrammer, opstart, resolver og konfiguration i Squid selv. |
Hvis ingen tilsvarende forespørgsel vises, skal du bekræfte, at denne klient nåede denne instans og lytter. Kontrollér lognings-ACL’er, buffering, rotation og om transaktionen stadig er aktiv; en langvarig tunnel har muligvis endnu ingen afsluttende adgangspost. En omgåelse eller en ældre proxyproces kan sende trafikken et andet sted hen, så knyt den lyttende proces til dens indlæste konfiguration, før du ændrer adgangspolitikken.
Del den relevante transaktion med følsomme oplysninger skjult og de nærliggende fejl. URL’er, forespørgsler, kildeadresser og brugernavne kan være private; at udskrive hele logs eller aktivere fuld headerlogning uden et konkret behov øger eksponeringen frem for at give nyttige beviser.