debug_options セクション29で Squid 7 の認証を追跡する
限定したセクション29のデバッグセッションで、チャレンジ、クライアントの応答、認証ヘルパー、アクセス ポリシーの判断を追跡します。
Squid の最初の 407 は認証の始まりである場合があります。試行がどこで止まるかを見つけるには、1 つのリクエストの流れをクライアント、認証機構、アクセス判断の順に追います。
Squid 7 の診断セッションでは、セクション 29 に認証のデバッグ メッセージが含まれます。一時的な構成で、全体の警告レベルを保ったままそのセクションを上げられます。
debug_options ALL,1 29,5
以前のデバッグ設定を記録し、診断用の構成を適用して、小さく特定可能な試行を再現します。デバッグ出力は構成済みの cache_log の出力先でアクセス ログと並べて読みます。
| 探す証拠 | 何に答えるか |
|---|---|
| 提示された Proxy-Authenticate スキーム | このプロキシはクライアントに何を使うよう求めたか |
| クライアントの認証応答 | クライアントは提示されたやり取りを続けたか |
| 認証機構またはヘルパーの結果 | アカウントは受理・拒否されたか、処理の失敗で遮断されたか |
| Squid のアクセス ポリシーの判断 | その認証状態の後、リクエストはどうなったか |
スキームによっては複数回のチャレンジが必要です。407 の記録が繰り返されるだけでは、ブラウザーがプロンプトを無視したことや、入力されたパスワードが誤っていたことを示しません。
ヘルパーの失敗では、構成済みのヘルパーとそのスキーム固有の結果プロトコルを確認します。起動できないプロセスは、稼働中のヘルパーがアカウントを拒否するのとは別の障害です。認証が受理されたのに Squid がなおリクエストを拒否する場合は、対応するアクセス ルールを追ってください。
流れを理解したら元のデバッグ レベルに戻します。レベル 9 の完全な出力は非常に大きくなる場合があります。認証の診断も、アカウントの詳細や他の機微な状態が現れうるため、限定的に扱う必要があります。