支店ブラウザからプロキシへ：二つの接続、二つの経路

明示的なプロキシの背後にある支店のブラウザは二つの接続を開き、それぞれ別の理由で失敗します。一つ目はブラウザからプロキシのリスナーまでで、支店のVPNを通ります。二つ目はプロキシからウェブサイトまでで、プロキシ自身のリゾルバー、経路、出口ポリシーを使います。これを一つの流れとして扱うサポートチケットは、担当者を何時間も間違った機器へ送ります。それぞれを意図的に設定し、その順番でテストしてください。

ステップ 1: 二つの流れを書き出す

ブラウザの直接の宛先はプロキシのリスナーであり、利用者が最終的に訪れるすべてのサイトではありません。この一文が、この設計の混乱の大半を解消します。

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

送信元も経路も権限も異なります。スケッチは変更記録に残してください。後続の確認はすべて、その二つの半分のどちらかを参照するからです。

ステップ 2: ブラウザにリスナーへの経路を与える

プロキシのホスト名、リスナーのポート、認証要件、許可された支店の送信元を記録します。この一覧が最初の流れの受け入れ基準であり、トンネル経路だけでなく内部の名前解決も含めるべきです。

無制限のプロキシをインターネットに公開するのではなく、目的のサービスに狭いネットワークルールを適用します。想定するクライアントにサポートされた経路があれば、プロキシは内部ネットワークに置いたままにできます。

ステップ 3: 経路表だけでなくブラウザを設定する

ブラウザのプロキシ設定、PACファイル、または組織の管理された検出機構を使います。通常のウェブサイトのパケットを経路でプロキシのアドレスへ送っても、ブラウザがプロキシプロトコルを話すようにはなりません。それは透過的な傍受であり、別のゲートウェイ設計に属します。

どのアプリケーションが設定に従うかを書き留めます。メールクライアント、更新プログラム、ゲームは従わないことが多く、単純な経路を使い続けます。

ステップ 4: プロキシの先方接続を証明する

プロキシには独自のリゾルバーとウェブサイトへの許可された経路、さらにインターネット境界が要求するファイアウォールや変換のポリシーが必要です。リスナーに到達するブラウザは、そのどれも証明しません。二つ目の流れはプロキシ自身から、利用者が報告した同じ宛先とポートでテストします。

HTTPSでは、CONNECTが要求された宛先へのトンネルを開きます。通常の転送では復号されたページがプロキシに渡らず、検査を間に合わせるために証明書の検証を無効にすることは解決策ではありません。

ステップ 5: 四つの障害を区別する

プロキシの認証要求はリスナーからの 407 です。拒否された CONNECT はプロキシ上のポリシー判断で、通常は独自のステータスとログ行を持ちます。先方接続の失敗は、プロキシが宛先に対して記録するタイムアウトやリセットのように見えます。ウェブサイトの応答は、両方の接続が機能し、問題が送信元にあることを意味します。

VPNが失敗したという要約ではなく、観察した境界を報告してください。

ステップ 6: 範囲を定め、代替を計画する

プロキシまたはトンネルが利用できないときに何が起きるかを決め、この設計がどのトラフィックを対象とするかを明確に述べます。プロキシ設定に従うクライアントからのウェブアクセスを運びますが、メール、任意のデバイスプロトコル、設定を無視するソフトウェアは運びません。

設計をより多くのクライアントへ広げる前に、承認された計画の下で必要なブラウザ操作と一つの必要な拒否を検証します。