深入探讨Forward Proxy是什么

私たちは一般的に、外部ネットワークトラフィックがこのソフトウェアを介して内部ネットワーク内の実際のサービスに転送される場合でも、NGINXやApacheをロードバランサーやリバースプロキシサーバーとして利用します。リバースプロキシが存在する一方で、フォワードプロキシも存在します。それらの機能について詳しく見ていきましょう。

リバースプロキシ

OSIモデルからプロキシサーバーへ

インターネットサービスにアクセスする際、私たちは通常、OSIモデルの第7層で動作するHTTPプロトコルを使用します。このプロトコルのよく知られたコンポーネントであるホスト名、パス、クエリパラメータなどは、この層の一部です。HTTPプロトコルは、OSIモデルの第4層で動作するTCPまたはUDPプロトコルに基づいて構築されており、サービスアクセス時に使用されるポートの概念はこれらのプロトコル内に存在します。さらに、TCPとUDPはどちらもインターネットプロトコル（IP）に基づいており、OSIモデルの第3層で動作し、IPアドレスはインターネットの「住所」として機能します。

IPネットワークを使用してインターネットにアクセスする場合、IPプロトコルはターゲットのアドレス指定を担当し、データパケットをルールに従ってカプセル化し、IPネットワーク内の送信元アドレスから宛先アドレスに転送します。たとえば、ネットワークトラフィックは訪問者のローカルネットワークからISP提供のゲートウェイデバイスを経由してISPのネットワークに接続し、リソースプロバイダーのサービスにアクセスします。

この時点で、私たちはゲートウェイを使用してインターネットにアクセスします。プロキシサーバーについて議論する際、IPネットワークとの類似点を描くことができます。プロキシサーバーはゲートウェイとして機能し、クライアントがサービスにアクセスするのを支援する橋渡し役を果たします。それらは本質的にOSIモデルの第4層と第7層の間に位置し、実際にはOSIモデルの第5層に属します。

API7-OSIモデル

プロキシサーバーの目的

プロキシサーバーは通常、以下の目的で使用されます：

内部ネットワークアクセスの集中出口

企業はしばしば、アクセス制御やトラフィックロギングなどの情報セキュリティ要件を持っています。HTTPSのような暗号化トラフィックが普及しているため、ネットワークトラフィックをパスワードの下に隠すことで、ネットワーク境界での記録と監査が難しくなり、漏洩のリスクが高まります。プロキシサーバーの存在は、統一されたトラフィック出口として機能し、トラフィック監査タスクを処理する仲介役として働きます。

人間向けの目的に加えて、プロキシサービスは外部ネットワークにアクセスするプログラムサービスの出口としても機能します。たとえば、サービスプロバイダーがwebhook機能を提供する場合、固定出口を通じてトラフィックをチャネル化し、単一の固定IPアドレスまたは固定IPアドレスの範囲を使用する必要があります。これにより、webhook呼び出しの受信者がファイアウォールで正しくホワイトリストに登録することが容易になります。これを行わないと、webhook呼び出しの両側が潜在的なセキュリティリスクにさらされます。

訪問者の身元を隠す

時には、インターネットユーザーが自分のIPアドレスなどの身元を隠したい場合があります。そのような場合、透過プロキシサーバーが役立ちます。クライアントは最初にプロキシサーバーに接続し、接続する実際のサービスアドレスを指定し、HTTPSプロトコルを使用してプロキシサーバー経由でターゲットサービスにアクセスします。プロキシサーバーの存在により、クライアントの身元が隠され、暗号化プロトコルの使用により、プロキシサーバーがこのプロセス中にデータを盗むことができないことが保証されます。

フォワードプロキシ

HTTPベースのプロキシ

プロキシサーバーでは、通常、HTTPベースのHTTPプロキシとバイナリベースのプロトコルであるSOCKS 4/5プロトコルに出会います。それらは同様の機能を実行しますが、実装方法が異なります。HTTPベースのプロキシに焦点を当てましょう。

プロトコル実装の初期段階では、HTTP上のトラフィックは主に平文でした。この透明性により、クライアントとサービスの間に位置するプロキシサーバーはURLとリクエストペイロードを簡単に解析できました。DNS解決と同様のプロセスを通じて、プロキシは自身のネットワークアドレスを使用してサービスに接続し、クライアントを隠すことができました。

このような呼び出しの例は次のとおりです：

GET http://example.com/resource HTTP/1.1
Proxy-Authorization: Basic encoded-credentials

プロキシサーバーはクライアントがアクセスしようとしているアドレスを理解し、サービスにリクエストを送信してレスポンスを取得し、それをクライアントに返します。

HTTP/1.1 200 OK
Content-Type: text/html
...
body blahblah
...

これはHTTPプロキシサーバーの最も単純な実装形態です。しかし、欠点も観察されます：プロキシサーバーはクライアントのトラフィックを平文で処理するため、転送中にユーザートラフィックを記録する可能性があり、セキュリティリスクが生じます。したがって、セキュリティを確保するために暗号化方法を検討する必要があります。

HTTPSトラフィックとプロキシサーバーの複雑な動作

すべてのHTTPトラフィック内でHTTPS暗号化トラフィックの割合が増加するにつれて、プロキシサーバーはこのシナリオに適応する必要があります。

しかし、課題が生じます：クライアントがサービスプロバイダーに送信するトラフィックは暗号化されています。プロキシサーバーは、クライアントがアクセスしているリソースを復号化して理解することができません。これは、トラフィックがクライアントとサービスプロバイダー間の非対称暗号化アルゴリズムに基づく鍵ネゴシエーションメカニズムによって保護されており、その後の暗号化トラフィックは通信中に中間者によって取得できない対称鍵を使用するためです。TLSの基本的な目的は、中間者攻撃の可能性を防ぐことです。

では、プロキシサーバーはこの場合どのように機能するのでしょうか？

これは以前の平文リクエスト解析方法と比較してより複雑です。HTTPプロトコルは専用のリクエストメソッドCONNECTを導入しました。クライアントはこのメソッドを使用してプロキシサーバーに初期リクエストを送信します：

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: Basic encoded-credentials

クライアントはプロキシサーバーにCONNECTリクエストを送信し、接続したいドメインまたはIPアドレスとポートを含めます。プロキシサーバーはリクエストを受信すると、ターゲットサービスとのTCP接続を確立し、クライアントとサービスの間のポートマッピングを保存します。その後、クライアントはプロキシサーバーに正しいリクエストを送信でき、プロキシサーバーはデータを解析しようとせずにトラフィックをサービスに転送します。したがって、HTTPSの暗号化通信は信頼性があります。

このメカニズムは、平文HTTPプロキシと比較して、より汎用性があります。最初のHTTPリクエストがプロキシサーバーに接続を確立するための情報を通知すると、それは本質的に透過プロキシチャネルになります。プロキシサーバーを介してHTTPSおよびTCPバイナリトラフィック（SSHなど）の通信を容易にすることができます。