Squid の親プロキシに独立した認証情報を設定する
クライアントのプロキシパスワードを別の運用者に渡すと決めつけず、Squid 6.13 に専用の上流ログインを設定します。
ユーザーが Squid サービスにログインする認証情報と、Squid が親プロキシにログインする認証情報は別です。親は別の運用者に属したり、異なるアカウントデータベースを使ったりする可能性があります。クライアントのパスワードを受け付けたからといって、上流に渡すべきだと考えないでください。
Squid 6.13 では、親の定義に固定のログイン情報を付けられます。
cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream login=parentuser:ExampleOnly上のアドレスとパスワードは文書用の例です。誤って二つ目の peer を作らず、既存の親の定義にログイン情報を追加してください。どのリクエストがこの親を使う必要があるかを決める独立したルーティングポリシーも維持してください。
アカウントの適用範囲を分ける
下流の auth_param 設定はその Squid インスタンスのクライアントを検証します。peer の login オプションは別のホップの認証情報を提供します。一方を変えても他方は自動更新されません。
親の文書にある認証要件に合わせてください。この行は、あらゆる接続指向の認証方式に対する完全な設定ではありません。親が NTLM または Negotiate を要求する場合は、このフィールドのパスワードを繰り返し変えるのではなく、対応する peer の構成を確認してください。
Squid には PASS や PASSTHRU などの認証情報を引き渡すオプションもあります。専用の上流アカウントとは意味が異なり、クライアントの認証情報を peer に開示する可能性があります。独立したアカウントを使う設計なら、近道として選ばないでください。
設定を保護して正しいホップをテストする
固定の秘密情報は設定に保存されます。ファイルやバックアップへのアクセスを制限し、解析器やデバッグの出力は機密情報を除去してから共有してください。このオプション独自のエスケープ規則があり、文書では URL エスケープを認め、リテラルのパーセント記号を二重にするよう求めています。
クライアント認証に成功しても、転送リクエストが親で失敗する場合は、その上流のやり取りとアカウントを調べてください。クライアントから Squid、Squid から親への転送保護も分けて考えます。最初の接続を暗号化しても、二つ目は自動的には保護されません。