フォワードプロキシ vs リバースプロキシ

スクレイプレスプロキシは、クライアント起動のウェブトラフィックのためにフォワードプロキシルートを提供し、リバースプロキシはサーバー側のアプリケーション配信パスに属します。

定義

フォワードプロキシ vs リバースプロキシは、中間者が接続のどの側を表しているかを比較します。フォワードプロキシはクライアントによって選択され、そのクライアントの代理で外部宛先に到達します。リバースプロキシは、HTTP用語でゲートウェイとも呼ばれ、1つまたは複数のオリジンサーバーの代理としてリクエストを受け入れます。

パケットパスは似たように見えることがあります：1つの接続が中間者に到達し、もう1つがそれを離れます。違いは制御と意図です。フォワードプロキシでは、クライアントはアウトバウンド中間者を知っているか、従う必要があります。リバースプロキシでは、公共のクライアントは中間者をウェブサイト自体として扱うことができ、どのオリジンが応答を提供したかを決して学習することはありません。

この区別は、 HTTPセマンティクスで形式化されています。標準は、プロキシをクライアント選択の転送エージェント、ゲートウェイをオリジンの代理として行動する中間者として定義します。業界では一般的に、そのゲートウェイの役割にリバースプロキシを使用します。

リクエストパスを並べて表示

フォワードプロキシパスでは、ブラウザまたはスクリプトがターゲット宛先をプロキシに送信します。プロキシはクライアントを認証し、アウトバウンドルールを適用し、イーグレスアドレスを選択し、宛先接続を開きます。オリジンはプロキシパスからリクエストを受け取り、同じ中間者を通じて応答を返します。

リバースプロキシパスでは、公共サービスのDNSがクライアントをリバースプロキシに指し示します。プロキシは着信接続を終了し、ルーティングまたはヘルスルールに従ってオリジンを選択し、内部リクエストを作成します。オリジンはリバースプロキシに応答を返し、リバースプロキシは公共の応答をクライアントに送信します。

両方のパスはフォワーディングメタデータを追加できます。 RFC 7239 は、元のクライアント向けプロトコル、ホスト、およびアドレスなどの情報のためのForwardedフィールドを定義しています。展開は、このメタデータを利用する前に、どのホップが信頼されているかを決定する必要があります。なぜなら、信頼されていないクライアントが似たようなフィールドを送信できるからです。

1. クライアントはプロキシエンドポイントを選択し、認証します。
2. プロキシはプール、場所、セッション、およびアクセスルールを適用します。
3. プロキシは要求された宛先に向けてアウトバウンド接続を作成します。
4. 宛先からの応答はプロキシを通じてクライアントに返されます。

一目で比較

フォワードプロキシ vs リバースプロキシは、マーケティングラベルよりも観察可能なネットワークおよびセッションプロパティのバンドルとして最もよく理解されます。

一般的なユースケース

適切なユースケースは、プロキシルートが定義されたネットワークまたはローカリゼーションの要件に応答し、基盤となるアクセスが認可されている場所です。

どのプロキシが必要かを知る方法

仲介者を誰が制御しているかを尋ねます。クライアントまたはクライアントネットワークが無関係なインターネットの宛先に到達するために設定している場合、それはフォワードプロキシです。アプリケーションの所有者が内部オリジンに対するトラフィックを受信するために公共サービスのエンドポイントに配置した場合、それはリバースプロキシです。

次に、何を隠すべきか、または制御すべきかを尋ねます。フォワードプロキシはクライアントのイグレスを集中させ、アウトバウンド地域を選択するか、宛先に見えるアドレスを変更します。リバースプロキシはインバウンドポリシーを集中管理し、オリジントポロジーを保護し、アプリケーションサーバー間でリクエストをルーティングします。片方はもう片方の代わりにはなりません。なぜなら、彼らはアーキテクチャの反対側を解決するからです。

完全なシステムは両方を使用するかもしれません。内部クローラーはフォワードプロキシを通じて出て行き、そのサイトのリバースプロキシを介して配信されたサイトをリクエストできます。各仲介者は、別々の信頼の境界、ログ、認証情報、TLS構成、および障害の所有権を持つべきです。

• 作業の単位を定義する。 1つのリクエスト、1つのページグループ、または1つのブラウザジャーニーがネットワークアイデンティティを共有すべきかどうかを決定します。
• クライアント変数を安定させる。 同じターゲット、クッキー、ヘッダー、地域、および抽出ロジックを持つルートを比較します。
• 使用可能な出力を測定する。 正しいコンテンツと地域を追跡し、接続の成功または観測されたIPの数だけでなく。
• 認証情報を保護する。 プロキシのユーザー名、パスワード、およびトークンをソースコード、ドキュメント内のURL、および操作ログから除外します。

セキュリティとヘッダートラスト

転送されたクライアントアドレスヘッダーは、信頼できない入力を上書きする既知の仲介者から来る場合にのみ信頼できます。リバースプロキシは、自身の信頼できるメタデータを追加する前に、偽造可能なフィールドを削除または正規化するべきです。クライアントが提供する転送ヘッダーを受け入れるオリジンは、不正確なセキュリティ、ログ記録、またはレートの決定を行う可能性があります。

TLS終端も設計によって異なります。フォワードプロキシは、エンドツーエンドのCONNECTトンネルを運ぶか、明示的な信頼ポリシーの下で管理された検査を実行できます。リバースプロキシは通常、サービスのために公開TLS接続を終了し、オリジンへの別の保護された接続を作成します。証明書、鍵、およびプロトコルの所有権は、その役割と一致しているべきです。

自動フォワードプロキシ選択はクライアントの関心事です。 PACファイル は、URLによってプロキシを選択できますが、リバースプロキシ選択は通常DNSおよびサービスルーティングから来ます。これらの設定プレーンを混同すると、脆弱なデプロイメントと不明確なインシデントの所有権を生じさせます。

関連するプロキシタイプとセッションモデル

プロキシアーキテクチャは、アドレスオリジンとセッションの動作が独立して比較されると、理解しやすくなります。

運用と責任ある使用

プロキシレイヤーを測定されたインフラストラクチャとして扱います。選択されたリージョン、プロキシクラス、セッションポリシー、ターゲットホスト、応答ステータス、応答時間、および転送されたバイト数を記録しますが、認証情報や機密ペイロードはログしません。ネットワークの障害とアプリケーションの障害を分離します：到達可能なプロキシはターゲット側の拒否を返すことができますが、有効なページは解析に失敗することがあります。この分離により、キャパシティプランニングとインシデントレビューが単一の成功カウンターよりもはるかに有用になります。

プロキシはネットワークパスを変更しますが、データを収集や使用する権限を付与するものではありません。チームは、アクセスが許可されたデータに収集を制限し、ターゲットサービスの利用規約を読み、適用されるプライバシーおよびデータ保護要件を尊重し、プライベート、機密、または制限されたソースを避ける必要があります。収集ボリュームは、プロキシプールが送信できる最大トラフィックではなく、正当なビジネスニーズに一致する必要があります。

本番デザインは、トラフィックが始まる前にホストレベルの同時処理、リクエスト予算、認証情報の範囲、保持ルールを設定する必要があります。アクセスが許可されていないことを示す場合、収集を停止します。機密データはプロキシセッション識別子から除外し、ルート構成、インシデント応答、プロバイダーのレビューの所有者を文書化します。

結論

フォワードプロキシとリバースプロキシは、クライアントと宛先の間のパスの特定の部分を説明します。健全な実装は、その部分を正確に名前付けし、プロトコルおよびセッションポリシーから分離し、意図された公開ワークフローに対してテストし、プロキシを制御されたインフラストラクチャとして扱います。

検証された要件を満たす最も単純なルートから始めます。測定されたターゲットの挙動が変更を正当化する場合にのみ、地理的選択、回転、持続、または異なるIPオリジンを追加します。このアプローチでは、パフォーマンス、コスト、アイデンティティ、コンプライアンスの決定がワークフローを運用しているチームに可視化されます。