SSL プロキシ負荷分散の概要

SSL トラフィックに Google Cloud SSL プロキシ負荷分散を使用すると、負荷分散層でユーザーの SSL(TLS)接続を終端し、SSL(推奨)または TCP プロトコルを使用してバックエンド インスタンス全体で接続を分散できます。サポートされているバックエンドのタイプについては、バックエンドをご覧ください。

SSL プロキシ負荷分散は、HTTP(S) 以外のトラフィックを対象としています。HTTP(S) トラフィックの場合は、HTTP(S) 負荷分散の使用をおすすめします。

Google Cloud ロードバランサとの相違点については、次のドキュメントをご覧ください。

SSL 負荷分散は、IPv4 アドレスと IPv6 アドレスのクライアント トラフィックに対応しています。クライアントの IPv6 リクエストは負荷分散層で終端され、IPv4 経由で VM にプロキシされます。

SSL プロキシ負荷分散は、グローバルにデプロイできる負荷分散サービスです。複数のリージョンにバックエンドをデプロイできます。また、負荷分散によって、容量のある最も近いリージョンにトラフィックが自動的に転送されます。最も近いリージョンが容量に達すると、ロードバランサは使用可能な容量を持つ別のリージョンに新しい接続を自動的に転送します。既存のユーザー接続は現在のリージョンにそのまま残ります。

グローバル負荷分散には、Network Service Tiers のうちデフォルトの階層であるプレミアム階層を使用する必要があります。それ以外の場合は、負荷分散はリージョン単位で処理されます。

利点

SSL プロキシ負荷分散には次のメリットがあります。

  • インテリジェント ルーティング。ロードバランサは、処理能力があるバックエンドのロケーションにリクエストをルーティングできます。L3/L4 ロードバランサの場合は、利用可能な処理能力にかかわらず、常にリージョンのバックエンドにルーティングされます。より高度なルーティングを使用すると、x*N ではなく、N+1 または N+2 でプロビジョニングできるようになります。

  • バックエンド使用率の向上。使用されている暗号の CPU 効率が良くない場合、SSL の処理によって CPU に多大な負荷がかかる可能性があります。CPU のパフォーマンスを最大化するには、ECDSA SSL 証明書と TLS 1.2 を使用し、ロードバランサとインスタンス間の SSL に ECDHE-ECDSA-AES128-GCM-SHA256 暗号スイートを使用します。

  • 証明書管理。顧客向けの SSL 証明書は、デベロッパーが自分で取得および管理する証明書(セルフマネージド証明書)か、Google が取得して管理する証明書(Google マネージド証明書のいずれかです。Google マネージド SSL 証明書の場合、1 つの証明書で最大 100 個までのドメインがサポートされます。Google マネージド証明書では、複数のドメインがサポートされます。証明書は、ロードバランサにのみプロビジョニングする必要があります。VM インスタンスでは、自己署名証明書を使用して管理を簡素化できます。

  • セキュリティ パッチ。SSL または TCP スタックで脆弱性が見つかると、VM の安全性を維持するため、ロードバランサで自動的にパッチが適用されます。

  • SSL プロキシ負荷分散でサポートされるポート: 25、43、110、143、195、443、465、587、700、993、995、1883、3389、5222、5432、5671、5672、5900、5901、6379、8085、8099、9092、9200、9300。Google マネージド SSL 証明書を SSL プロキシの負荷分散に使用する場合、Google マネージド SSL 証明書のプロビジョニングと更新を行うには、トラフィックのフロントエンド ポートを 443 に設定する必要があります。

  • SSL ポリシーSSL ポリシーによって、SSL プロキシのロードバランサがクライアントとネゴシエートする SSL の機能を制御できます。

  • 暗号化されていない TCP を介して負荷分散層とバックエンド インスタンス間でトラフィックを送信すると、バックエンドから SSL 処理をオフロードできます。ただし、その場合、セキュリティの強度が弱くなります。そのため、この方法はおすすめしません。

  • SSL プロキシの負荷分散は HTTPS を処理できますが、これもおすすめしません。HTTPS の場合は、代わりに HTTP(S) 負荷分散を使用してください。詳しくは、よくある質問をご覧ください。

  • SSL ポリシーを作成するには、gcloud コマンドライン ツールを使用します。

  • SSL プロキシ ロードバランサは、クライアント証明書ベースの認証(別名: 相互 TLS 認証)をサポートしていません。

  • 各 SSL プロキシ ロードバランサには、単一のバックエンド サービス リソースが含まれます。バックエンド サービスに対する変更は即時に行われるわけではありません。変更が Google Front End(GFE)に反映されるまでに数分かかる場合があります。

ここでは、SSL プロキシ負荷分散の仕組みについて説明します。

使用例

SSL プロキシ負荷分散を使用すると、SSL 接続は負荷分散層で終端し、最も近いバックエンドにプロキシされます。

この例では、アイオワとボストンのユーザーからのトラフィックが負荷分散層で停止し、選択したバックエンドとの接続が確立されます。

Cloud Load Balancing と SSL 終端処理(クリックして拡大)
Cloud Load Balancing と SSL 終端処理(クリックして拡大)

ネットワーク サービス階層でのロードバランサの動作

SSL プロキシ負荷分散はプレミアム階層のグローバル サービスです。バックエンド サービスは 1 つだけですが、複数のリージョンにバックエンドを配置できます。トラフィックは次のようにバックエンドに割り当てられます。

  1. クライアントがリクエストを送信すると、負荷分散サービスは送信元 IP アドレスからリクエストの大まかな送信元を特定します。
  2. 負荷分散サービスは、バックエンド サービスが所有するバックエンドのロケーション、全体の容量、現在の総使用量を確認します。
  3. ユーザーに最も近いバックエンド インスタンスに使用可能な容量がある場合、このバックエンドのセットにリクエストが転送されます。
  4. 指定されたリージョンに届いたリクエストは、そのリージョン内で使用可能なすべてのバックエンド インスタンスに均等に分散されます。ただし、負荷が非常に小さい場合は分散が不均等に見える場合もあります。
  5. 指定されたリージョン内に使用可能な容量を持つ正常なインスタンスがない場合、ロードバランサは代替手段として、使用可能な容量を持つ次に近いリージョンにリクエストを送信します。

スタンダード階層では、TCP プロキシ負荷分散はリージョン サービスです。バックエンドはすべて、ロードバランサの外部 IP アドレスと転送ルールで使用されるリージョンに配置する必要があります。

送信元 IP アドレス

各バックエンド仮想マシン(VM)インスタンスまたはコンテナから見たパケットの送信元 IP アドレスは、次の範囲の IP アドレスです。

  • 35.191.0.0/16
  • 130.211.0.0/22

実際の負荷分散トラフィックの送信元 IP アドレスは、ヘルスチェック プローブ IP 範囲と同じです。

バックエンドから見たトラフィックの送信元 IP アドレスは、ロードバランサの Google Cloud の外部 IP アドレスではありません。つまり、2 つの HTTP、SSL、または TCP セッションがあります。

  • セッション 1: 元のクライアントからロードバランサ(GFE)へのもの。

    • 送信元 IP アドレス: オリジナルのクライアント(クライアントが NAT の背後にある場合は外部 IP アドレス)。
    • 宛先 IP アドレス: ロードバランサの IP アドレス。
  • セッション 2: ロードバランサ(GFE)からバックエンド VM またはコンテナへのもの。

    • 送信元 IP アドレス: 35.191.0.0/16 または 130.211.0.0/22 いずれかの範囲の IP アドレス。

      実際の送信元アドレスは予測できません。

    • 宛先 IP アドレス: Virtual Private Cloud(VPC)ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。

TLS の終端ロケーションに対する地理的制御

SSL プロキシ ロードバランサは、クライアントとロードバランサ間のレイテンシを最小限に抑えるため、グローバルに分散するロケーションで TLS を終了します。どこで TLS を終端するかを地理的に制御する必要がある場合は、ネットワーク負荷分散を代わりに使用し、ニーズに適したリージョンにあるバックエンドで TLS を終端する必要があります。

ポートを開く

SSL プロキシ ロードバランサはリバース プロキシのロードバランサです。ロードバランサによって受信接続が終端され、ロードバランサからバックエンドへの新しい接続が開かれます。リバース プロキシ機能は、Google Front Ends(GFE)が提供します。

ファイアウォール ルールの設定では、GFE からバックエンド インスタンスへのトラフィックをブロックしますが、GFE への受信トラフィックはブロックしません。

SSL プロキシのロードバランサには、同じアーキテクチャで実行される他の Google サービスをサポートする多数のオープンポートが含まれます。ロードバランサの外部 IP アドレスに対してセキュリティ スキャンまたはポートスキャンを実行すると、他のポートも開いているように見えます。

このことは、SSL プロキシのロードバランサには影響しません。SSL ロードバランサの定義で使用される外部の転送ルールでは、TCP ポート 25、43、110、143、195、443、465、587、700、993、995、1883、3389、5222、5432、5671、5672、5900、5901、6379、8085、8099、9092、9200、9300 だけが参照可能です。これ以外の TCP 宛先ポートのトラフィックは、ロードバランサのバックエンドには転送されません。

ファイアウォール ルール

バックエンド インスタンスは、ロードバランサの GFE / ヘルスチェック範囲からの接続を許可する必要があります。つまり、130.211.0.0/2235.191.0.0/16 からのトラフィックがバックエンド インスタンスまたはエンドポイントに到達することを許可するファイアウォール ルールを作成する必要があります。これらの IP アドレス範囲は、ヘルスチェック パケットと、バックエンドに送信されるすべての負荷分散されたパケットのソースとして使用されます。

このファイアウォール ルールに構成するポートは、以下のバックエンド インスタンスまたはエンドポイントへのトラフィックを許可する必要があります。

  • 各転送ルールで使用されるポートを許可する
  • それぞれのバックエンド サービスに構成された各ヘルスチェックで使用されるポートを許可する

ファイアウォール ルールは、Google Front End(GFE)プロキシではなく、VM インスタンス レベルで実装されます。Google Cloud ファイアウォール ルールを使用して、トラフィックがロードバランサに到達しないようにすることはできません。

ヘルスチェック プローブの詳細と、130.211.0.0/2235.191.0.0/16 からのトラフィックを許可する必要がある理由については、プローブ IP 範囲とファイアウォール ルールをご覧ください。

分散モード

バックエンド サービスにバックエンドを追加するときは、負荷分散モードを設定します。

SSL プロキシ負荷分散の場合、分散モードは connection または backend utilization に設定できます。

負荷分散モードが connection に設定されている場合、バックエンドで処理できる同時接続数に基づいて負荷が分散されます。次のパラメータ(maxConnections(リージョン マネージド インスタンス グループを除く)、maxConnectionsPerInstancemaxConnectionsPerEndpoint)のいずれかも指定する必要があります。

負荷分散モードが backend utilization に設定されている場合、インスタンス グループ内のインスタンスの使用率に基づいて負荷が分散されます。

ロードバランサのタイプとサポートされている分散モードの比較については、負荷分散の方法をご覧ください。

SSL 証明書

ターゲット SSL プロキシに 1 つ以上のSSL 証明書をインストールする必要があります。

これらの証明書は、Google Front End(GFE)とクライアント間の通信を保護するために、ターゲット SSL プロキシによって使用されます。この証明書は、セルフマネージド SSL 証明書または Google マネージド SSL 証明書のいずれかとなります。

SSL 証明書の制限と割り当てについては、負荷分散割り当てページのSSL 証明書をご覧ください。

最高レベルのセキュリティを実現するには、SSL プロキシ ロードバランサのデプロイに、エンドツーエンドの暗号化を使用します。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

Google がユーザートラフィックを暗号化する方法に関する一般的な情報については、Google Cloud での転送中の暗号化ホワイトペーパーをご覧ください。

よくある質問

SSL プロキシ負荷分散ではなく HTTP(S) 負荷分散の使用が必要になるのは、どのような場合ですか。

SSL プロキシ負荷分散でも HTTPS トラフィックを処理できますが、HTTP(S) 負荷分散にはたいていの場合に選択したほうがよい追加機能が備わっています。

HTTP(S) 負荷分散には、次の追加機能が備わっています。

  • HTTP/2 と SPDY/3.1 をネゴシエーションします。
  • 無効な HTTP リクエストまたはレスポンスを拒否します。
  • URL ホストとパスに基づいて、別の VM にリクエストを転送します。
  • Cloud CDN と統合します。
  • バックエンド インスタンス間でリクエストの負荷をより均等に分散し、バックエンドをより効率的に使用できます。HTTPS では各リクエストは別個に負荷分散されますが、SSL プロキシ負荷分散では同じ SSL または TCP 接続からのすべてのバイトが同じバックエンド インスタンスに送信されます。

SSL プロキシ負荷分散は、WebSockets や IMAP over SSL など、SSL を使用する他のプロトコルでも使用できます。

負荷分散層との接続で使用された元の IP アドレスを確認できますか。

○。PROXY プロトコル バージョン 1 ヘッダーを先頭に付けて、元の接続情報が維持されるようにロードバランサを設定できます。詳細については、プロキシの PROXY プロトコル ヘッダーの更新をご覧ください。

次のステップ