Znajdź nieudane żądanie w dziennikach Squida
Używaj access.log do wyników transakcji, a cache.log do awarii samego Squida, odróżniając status tunelu od statusu celu.
W pakiecie Squid 6 dla Debiana zacznij od zwykłych dzienników transakcji i demona:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logNiestandardowe logowanie lub menedżer usług może wysyłać je gdzie indziej. Odtwórz jedno żądanie o ograniczonym zakresie ze znanego źródła i zapisz czas, metodę oraz cel, aby dopasować właściwy wpis.
| Dowód | Co z niego odczytać |
|---|---|
| Wynik w natywnym formacie access.log | Kod wyniku Squida i status HTTP to oddzielne części transakcji. |
| Informacje o hierarchii dostępu | Jak przekazywanie wykorzystało nadrzędne proxy lub inną trasę. |
| Udany CONNECT | Tunel został otwarty; nie jest to późniejszy status witryny wewnątrz szyfrowanego TLS. |
| cache.log | Awarie programów pomocniczych, uruchamiania, resolvera i konfiguracji samego Squida. |
Jeśli nie ma pasującego żądania, potwierdź, że ten klient dotarł do tej instancji i punktu nasłuchu. Sprawdź ACL logowania, buforowanie, rotację i czy transakcja nadal trwa; długo utrzymywany tunel może jeszcze nie mieć końcowego wpisu dostępu. Ominięcie proxy lub starszy proces proxy może kierować ruch gdzie indziej, więc przed edycją polityki dostępu powiąż proces nasłuchujący z załadowaną przez niego konfiguracją.
Udostępnij odpowiednią transakcję z ukrytymi danymi wrażliwymi i pobliskie błędy. Adresy URL, zapytania, adresy źródłowe i nazwy użytkowników mogą być prywatne; zrzucanie całych dzienników lub włączanie pełnego logowania nagłówków bez konkretnej potrzeby zwiększa ujawnianie danych zamiast dostarczać użytecznych dowodów.