ファイアウォール ルール

通常、Google Cloud ロードバランサでは、クライアントからのトラフィックがバックエンドに到達するように、1 つ以上のファイアウォール ルールが必要です。

  • ほとんどのロードバランサは、バックエンド インスタンスのヘルスチェックを指定する必要があります。ヘルスチェック プローブがバックエンドに到達するには、上り（内向き）許可ファイアウォール ルールを作成して、ヘルスチェック プローブがバックエンド インスタンスに到達できるようにする必要があります。

  • Google Front End（GFE）に基づくロードバランサには、GFE プロキシからのトラフィックがバックエンド インスタンスに到達することを許可する上り（内向き）許可ファイアウォール ルールが必要です。ほとんどの場合、GFE プロキシはヘルスチェック プローブと同じ送信元 IP 範囲を使用するため、個別のファイアウォール ルールは必要ありません。次の表に例外を示します。

  • オープンソースの Envoy プロキシに基づくロードバランサには、プロキシ専用サブネットからのトラフィックがバックエンド インスタンスに到達できるように上り（内向き）ファイアウォール ルールを作成する必要があります。これらのロードバランサによって受信接続が終端され、ロードバランサからバックエンドへのトラフィックはプロキシ専用サブネットの IP アドレスから送信されます。

次の表は、各タイプのロードバランサに最低限必要なファイアウォール ルールをまとめたものです。

ロードバランサの種類 最小限必要な上り（内向き）許可のファイアウォール ルール 概要 例
グローバル外部アプリケーション ロードバランサ
  • ヘルスチェック範囲:
    • 35.191.0.0/16
    • 130.211.0.0/22

    バックエンドへの IPv6 トラフィックの場合:

    • 2600:2d00:1:b029::/64
    • 2600:2d00:1:1::/64
  • GFE プロキシの範囲:
    • バックエンドがインスタンス グループ、ゾーン NEG（GCE_VM_IP_PORT）、ハイブリッド接続 NEG（NON_GCP_PRIVATE_IP_PORT）の場合は、ヘルスチェックの範囲と同じです。
    • _cloud-eoips.googleusercontent.com DNS TXT レコードに設定されている IP アドレス範囲。グローバル インターネット NEG バックエンドの送信元 IP アドレスを抽出するには、Linux システムで次のようなコマンドを実行します。 dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
 概要 例
従来のアプリケーション ロードバランサ
  • ヘルスチェック範囲:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • GFE プロキシの範囲:
    • バックエンドがインスタンス グループ、ゾーン NEG（GCE_VM_IP_PORT）、ハイブリッド接続 NEG（NON_GCP_PRIVATE_IP_PORT）の場合は、ヘルスチェックの範囲と同じです。
    • _cloud-eoips.googleusercontent.com DNS TXT レコードに設定されている IP アドレス範囲。グローバル インターネット NEG バックエンドの送信元 IP アドレスを抽出するには、Linux システムで次のようなコマンドを実行します。 dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
 概要 例
リージョン外部アプリケーション ロードバランサ
  • ヘルスチェック範囲1、2:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • プロキシ専用サブネット2
 概要 例
クロスリージョン内部アプリケーション ロードバランサ
  • ヘルスチェック範囲1、2:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • プロキシ専用サブネット2
 概要 例
リージョン内部アプリケーション ロードバランサ
  • ヘルスチェック範囲1、2:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • プロキシ専用サブネット2
 概要 例
グローバル外部プロキシ ネットワーク ロードバランサ
  • ヘルスチェック範囲:
    • 35.191.0.0/16
    • 130.211.0.0/22

    バックエンドへの IPv6 トラフィックの場合:

    • 2600:2d00:1:b029::/64
    • 2600:2d00:1:1::/64
  • GFE プロキシの範囲: ヘルスチェック範囲と同じ
 概要 例
従来のプロキシ ネットワーク ロードバランサ
  • ヘルスチェック範囲:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • GFE プロキシの範囲: ヘルスチェック範囲と同じ
 概要 例
リージョン外部プロキシ ネットワーク ロードバランサ
  • ヘルスチェック範囲1、2:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • プロキシ専用サブネット2
 概要 例
リージョン内部プロキシ ネットワーク ロードバランサ
  • ヘルスチェック範囲1、2:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • プロキシ専用サブネット2
 概要 例
クロスリージョン内部プロキシ ネットワーク ロードバランサ
  • ヘルスチェック範囲1、2:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • プロキシ専用サブネット2
 概要 例
外部パススルー ネットワーク ロードバランサ
  • ヘルスチェック範囲

    バックエンドへの IPv4 トラフィックの場合:

    • 35.191.0.0/16
    • 209.85.152.0/22
    • 209.85.204.0/22

    バックエンドへの IPv6 トラフィックの場合:

    • 2600:1901:8001::/48

  • インターネット上のクライアントの外部ソース IP アドレス
    例: 0.0.0.0/0（すべての IPv4 クライアント）、::/0（すべての IPv6 クライアント）、または特定の IP アドレス範囲のセット。

    ターゲット プールベースのロードバランサは、メタデータ サーバーを介してヘルスチェックをプロキシする場合があります。この場合、ヘルスチェック プローブの送信元はメタデータ サーバーの IP アドレス 169.254.169.254 と一致します。ただし、メタデータ サーバーからのトラフィックは常に VM にアクセスできます。ファイアウォール ルールは必要ありません。

 概要
 例
内部パススルー ネットワーク ロードバランサ
  • ヘルスチェック範囲:

    バックエンドへの IPv4 トラフィックの場合:

    • 35.191.0.0/16
    • 130.211.0.0/22

    バックエンドへの IPv6 トラフィックの場合:

    • 2600:2d00:1:b029::/64
  • クライアントの内部ソース IP アドレス
 概要 シングルスタック デュアルスタック

1 ハイブリッド NEG では、Google のヘルスチェック プローブ範囲を許可リストに登録する必要はありません。ただし、1 つのバックエンド サービスでハイブリッド NEG とゾーン NEG の組み合わせを使用している場合は、ゾーン NEG の Google ヘルスチェック プローブ範囲を許可リストに登録する必要があります。

2 リージョン インターネット NEG の場合、ヘルスチェックは省略可能です。リージョン インターネット NEG を使用するロードバランサからのトラフィックは、プロキシ専用サブネットから発信されます。このトラフィックは、Cloud NAT により、手動または自動的に割り振られた NAT IP アドレスに NAT 変換されます。このトラフィックには、ヘルスチェック プローブと、ロードバランサからバックエンドへのユーザー リクエストの両方が含まれます。詳細については、リージョン NEG: 下り（外向き）に Cloud NAT を使用するをご覧ください。