Spåra Squid 7-autentisering med debug_options avsnitt 29
Använd en avgränsad felsökningssession för avsnitt 29 för att följa utmaningen, klientens svar, autentiseringshjälparen och beslut om åtkomstpolicy.
Squids första 407 kan vara början på autentisering. För att hitta var ett försök stannar följer du en förfrågningssekvens genom klienten, autentiseringsmekanismen och åtkomstbeslutet.
I en Squid 7-diagnostisk session innehåller avsnitt 29 felsökningsmeddelanden för autentisering. En tillfällig konfiguration kan behålla den allmänna varningsnivån samtidigt som avsnittet höjs:
debug_options ALL,1 29,5Anteckna den tidigare felsökningsinställningen, tillämpa diagnostikkonfigurationen och återskapa ett litet, identifierbart försök. Läs felsökningsutdata på den konfigurerade cache_log-destinationen tillsammans med åtkomstloggen.
| Bevis att leta efter | Vilken fråga det besvarar |
|---|---|
| Det erbjudna Proxy-Authenticate-schemat | Vad bad denna proxy klienten att använda? |
| Klientens autentiseringssvar | Fortsatte klienten det erbjudna utbytet? |
| Autentiseringsmekanismen eller hjälparens resultat | Godtogs, avvisades eller blockerades ett konto av ett bearbetningsfel? |
| Squids beslut om åtkomstpolicy | Vad hände med förfrågan efter det autentiseringstillståndet? |
Vissa scheman kräver flera utmaningsomgångar. Upprepade 407-poster ensamma bevisar inte att webbläsaren ignorerade uppmaningen eller att det angivna lösenordet var fel.
Vid hjälparfel, undersök den konfigurerade hjälparen och dess schema specifika resultatprotokoll. En process som inte kan starta är ett annat fel än en körande hjälpare som avvisar ett konto. Om autentiseringen godtogs men Squid fortfarande nekar förfrågan, följ motsvarande åtkomstregler.
Återställ den ursprungliga felsökningsnivån när sekvensen är förstådd. Fullständig utdata på nivå 9 kan vara mycket stor; autentiseringsdiagnostik kräver också begränsad hantering eftersom kontouppgifter och andra känsliga tillstånd kan förekomma.