WPADプロキシ構成のエンタープライズ代替？
20か国以上に40以上のサイトがあります。出力フィルタリングを使用し、ほとんどのユーザーにWPAD経由のプロキシサーバーを強制します。
WPADは素晴らしく、99.9％機能します。ただし、WPADサポートの問題により、ブラウザ（MSIEのみ-まれに）またはサードパーティアプリ（WebEX voip）がローカルプロキシの場所を正しく認識しないために機能しなくなる場合がいくつかあります-直接試してください-そして失敗します。
それで、多数の出力ポイント/プロキシを持つ企業が、WPAD以外のすべてのブラウザ（つまり、MSIEだけでなく）や他のWebクライアントをサポートできるようにするための他のメカニズムはありますか？先に述べたように、WPADは実際には99.9％で機能しますが、その状況での問題は、人々が失敗を「見る」だけであり、グリズリングが始まることです...
PS：いいえ、「DHCPを使用する」は別のオプションではありません。これは、WPAD（プライマリはDNS）を配信するための単なる代替メカニズムです。他の誰かがする前に私がそれに答えると思っただけです;-)
ありがとう
ジェイソン
私が知っているあなたの唯一の選択肢は次のとおりです。
プロキシが「手動」である場所を「知る」ようにクライアントソフトウェアを構成します。すべての潜在的なクライアントソフトウェアを予測できるとは限らないため、これはおそらく敗戦です。スクリプトの混乱、レジストリのマージ、MSI変換、およびクライアントソフトウェアを事前構成するための接着テープのホスト全体が発生し、新しい何かがレーダーの下に潜り込んで機能しなくなります。
Windowsプロキシ自動検出（WPAD）などの標準の自動構成メカニズムを使用します。ご覧のとおり、これは100％信頼できるものではありません。
ISAサーバー用のMicrosoftの「ファイアウォールクライアント」など、TCP/IPスタックにクライアント側の「シム」を使用します。これを実行する唯一の製品はMicrosoftです。 ISAサーバー/ファイアウォールクライアント製品。これは非常にうまく機能しますが、非常に独自性があり、Windows固有です。
透過的なプロキシハードウェア/ソフトウェアを使用して、トラフィックをプロキシします。これは多くの場合うまく機能します（たとえば、Linuxでebtablesを使用すると、クライアントに対して完全に透過的なレイヤー2 HTTPプロキシを実際に作成できます）が、HTTPプロキシ認証の使用を妨げるという副作用があります（ブラウザー/クライアントのため）プロキシされていることを認識していません-適切に処理されません）。
これは「毒を選ぶ」タイプのシナリオです。