明示的プロキシのクライアントは、自分がプロキシと通信していることを知っています。インターセプトされたブラウザは、Web サイトに接続したと思い込んでいます。この違いが認証の核心です。

通常のプロキシ認証はプロキシチャレンジとプロキシ認可応答を使います。プロキシを選んでいないクライアントが、想定外の中間者にプロキシ資格情報を気軽に送るべきではありません。

そのため Squid のインターセプトの指針は、proxy_auth をインターセプトモードと単純に組み合わせることを支持していません。動作する Basic 認証ヘルパーがあっても、ブラウザがリモート端点を何だと思っているかは変わりません。

識別された利用者に通常の認証付きフォワードプロキシが必要なら、クライアントを明示的に設定してください。直接でも、適切に管理されたプロキシ設定経由でもかまいません。そのリスナーと認証ポリシーは、インターセプトリスナーとは分けておいてください。

認証ポータル、ネットワーク層の ID システム、TLS インターセプトの仕組みは、信頼と配備の要件が異なる別の設計です。失われた明示的プロキシのやり取りに対する一行の修正ではありません。

プロンプトがないことを、インターセプト対象のサービスを公開したり全クライアントを許可したりして解決しないでください。まず、要件が明示的な利用者認証なのか、プロキシ用に設定されたことのない通信のインターセプトなのかを決めてください。両者は前提が異なります。

関連記事