Cloud NAT プロダクトの相互作用

このページでは、Cloud NAT と他の Google Cloud プロダクトとの間の重要な相互作用について説明します。

ルートの相互作用

Public NAT ゲートウェイは、ネクストホップがデフォルトのインターネット ゲートウェイであるルートのみを使用できます。各 Virtual Private Cloud（VPC）ネットワークは、宛先が 0.0.0.0/0 で、そのネクストホップがデフォルトのインターネット ゲートウェイであるデフォルト ルートから始まります。重要な基本背景情報については、ルートの概要をご覧ください。

次の例では、Public NAT ゲートウェイが動作しなくなる原因を示します。

  • ネクストホップが他のタイプのカスタム静的ルートのネクストホップに設定されたカスタム静的ルートを作成すると、宛先 IP アドレスがルートの宛先と一致するパケットは、デフォルトのインターネット ゲートウェイではなく、そのネクストホップに送信されます。たとえば、NAT ゲートウェイ、ファイアウォール、プロキシ ソフトウェアを実行する仮想マシン（VM）インスタンスを使用する場合は、ネクストホップとして VM にトラフィックを転送するカスタム静的ルートを作成します。ネクストホップ VM には外部 IP アドレスが必要です。したがって、ネクストホップ VM やネクストホップ VM 自体に依存する VM からのトラフィックは、Public NAT ゲートウェイを使用できません。

  • ネクストホップが Cloud VPN トンネルのカスタム静的ルートを作成した場合、Public NAT はそのルートを使用しません。たとえば、宛先 0.0.0.0/0 を指定したカスタムの静的ルートとネクストホップ Cloud VPN トンネルは、デフォルトのインターネット ゲートウェイではなく、そのトンネルにトラフィックを転送します。そのため、Public NAT ゲートウェイはそのルートを使用できません。同様に、Public NAT ゲートウェイは、0.0.0.0/1 や 128.0.0.0/1 など、より具体的な宛先を持つカスタム静的ルートは使用できません。

  • オンプレミス ルーターが Cloud VPN トンネルまたは VLAN アタッチメントを管理する Cloud Router にカスタムの動的ルートをアドバタイズする場合、Public NAT ゲートウェイはそのルートを使用できません。たとえば、オンプレミス ルーターが宛先 0.0.0.0/0 のカスタム動的ルートをアドバタイズする場合、0.0.0.0/0 は Cloud VPN トンネルまたは VLAN アタッチメントに転送されます。この動作は、0.0.0.0/1 や 128.0.0.0/1 など、具体的な宛先でも同様です。

Private NAT は次のルートを使用します。

  • Inter-VPC NAT の場合、Private NAT は、Network Connectivity Center ハブに接続された 2 つの Network Connectivity Center VPC スポークによって交換されるサブネット ルートのみを使用します。Network Connectivity Center の VPC スポークの詳細については、VPC スポークの概要をご覧ください。
  • ハイブリッド NAT（プレビュー）の場合、Private NAT は Cloud VPN 上で Cloud Router によって学習された動的ルートを使用します。

限定公開の Google アクセスの相互作用

Public NAT ゲートウェイは、選択した Google API とサービスの外部 IP アドレスに送信されたトラフィックに対して NAT を実行しません。Public NAT ゲートウェイをプライマリまたはセカンダリのサブネット範囲に適用するように構成すると、Google Cloud によって、サブネット IP アドレス範囲での限定公開の Google アクセスが自動的に有効になります。ゲートウェイがサブネットの範囲に NAT を実施している限り、限定公開の Google アクセスはその範囲に対して有効であり、手動で無効にすることはできません。

Public NAT ゲートウェイは、限定公開の Google アクセスの動作を変更しません。詳細については、限定公開の Google アクセスをご覧ください。

Private NAT ゲートウェイは、限定公開の Google アクセスには適用されません。

共有 VPC の相互作用

共有 VPC を使用すると、1 つの組織内の複数のサービス プロジェクトで、ホスト プロジェクト内の共通の共有 VPC ネットワークを使用できます。共有 VPC ネットワークを使用するサービス プロジェクトで VM に NAT を実施するには、ホスト プロジェクトに Cloud NAT ゲートウェイを作成する必要があります。

VPC ネットワーク ピアリングの相互作用

Cloud NAT ゲートウェイは、単一のリージョンと単一 VPC ネットワーク内のサブネット IP アドレス範囲にと関連付けられています。1 つの VPC ネットワークで作成された Cloud NAT ゲートウェイは、ピアリングされたネットワーク内の VM がゲートウェイと同じリージョンにある場合でも、VPC ネットワーク ピアリングや Network Connectivity Center VPC スポークを使用して、接続された他の VPC ネットワーク内の VM に NAT を提供できません。

GKE の相互作用

Public NAT ゲートウェイは、限定公開クラスタのノードと Pod に対して NAT を実行できます。これは VPC ネイティブ クラスタの一種です。クラスタが使用するサブネットのために、少なくとも次のサブネット IP アドレス範囲に適用するように Public NAT ゲートウェイを構成する必要があります。

  • サブネットのプライマリ IP アドレス範囲（ノードで使用）
  • サブネット クラスタ内の Pod に使用されるセカンダリ IP アドレス範囲
  • クラスタ内のサービスに使用されるサブネット セカンダリ IP アドレス範囲

限定公開クラスタ全体に NAT を提供する最も簡単な方法は、クラスタのサブネットのすべてのサブネット IP アドレス範囲に適用するように Public NAT ゲートウェイを構成することです。

VPC ネイティブ クラスタでサブネット IP アドレス範囲を使用する方法に関する背景情報については、VPC ネイティブ クラスタの IP 範囲をご覧ください。

Public NAT ゲートウェイは、限定公開クラスタに対して NAT を実施するように構成されている場合、各ノード VM に NAT の送信元 IP アドレスと送信元ポートを予約します。Pod IP アドレスは各ノード VM に割り当てられたエイリアス IP 範囲として実装されるため、これらの NAT 送信元アドレスと送信元ポートは Pod で使用できます。

Google Kubernetes Engine（GKE）VPC ネイティブ クラスタは、複数の IP アドレス（/32 より小さいネットマスク）を含むエイリアス IP 範囲を各ノードに常に割り当てます。

  • 静的ポートの割り当てが構成されている場合、Public NAT のポート予約手順では、ノードあたり 1,024 個以上の送信元ポートが予約されます。VM あたりの最小ポート数に指定された値が 1,024 を超える場合は、その値が使用されます。

  • 動的ポートの割り当てが構成されている場合、VM あたりの最小ポート数に指定された値が、最初にノードごとに割り当てられます。割り当てられるポートの数は、必要に応じて VM あたりの最小ポート数と最大ポート数に指定された値の間で変わります。

Pod IP アドレス範囲と VPC ネイティブ クラスタについては、Pod のサブネット セカンダリ IP アドレス範囲をご覧ください。

Public NAT に関係なく、Google Kubernetes Engine は、クラスタのIP マスカレード構成を変更していない限り、Pod がインターネットにパケットを送信するときに各ノード上で実行されているソフトウェアを使用して、送信元ネットワーク アドレス変換（ソース NAT または SNAT）を実行します。Pod からの下り（外向き）トラフィックを細かく制御する必要がある場合は、ネットワーク ポリシーを使用できます。

一定の条件のもとでは、Public NAT は限定公開以外の VPC ネイティブ クラスタにも役立ちます。限定公開以外のクラスタ内のノードには外部 IP アドレスがあるため、ノードのプライマリ内部 IP アドレスから送信されたパケットは Cloud NAT で処理されません。ただし、一般公開クラスタで Public NAT ゲートウェイが提供する静的外部 IP アドレスを使用する場合は、次の手順を行います。

  • クラスタの Pod オブジェクトのセカンダリ IP アドレス範囲にのみ適用されるように Public NAT ゲートウェイを構成します。
  • デフォルトの SNAT を無効にするようにクラスタを構成して、インターネットに送信されるパケットの送信元 Pod オブジェクトの IP アドレスを GKE が保持するようにします。
  • IP マスカレード エージェントを構成するには、マスカレード以外の宛先として適切な CIDR を指定します。これにより、マスカレード以外の宛先に送信されるパケットがある場合、エージェントはこれらのパケットのソース Pod オブジェクトの IP アドレスを保持するようになります。

次の例では、Public NAT と GKE の一般的な関係を示します。

GKE での Public NAT。
GKE での Public NAT（クリックして拡大）

この例では、コンテナで NAT 変換を行います。すべてのコンテナと GKE ノードに対して NAT を有効にするには、NAT 候補として Subnet 1 のすべての IP アドレス範囲を選択する必要があります。

  • サブネットのプライマリ IP アドレス範囲: 10.240.0.0/24
  • Pod のサブネット セカンダリ IP アドレス範囲: 10.0.0.0/16

Pod1 または Pod2 に対してのみ NAT を有効にすることはできません。

Private NAT ゲートウェイは、限定公開クラスタと非限定公開クラスタ内のノードと Pod に対して NAT を実行できます。Private NAT ゲートウェイは、クラスタが使用するプライベート サブネットのすべてのサブネット IP アドレス範囲に自動的に適用されます。

ダイレクト VPC 下り（外向き）のインタラクション

Public NAT ゲートウェイは、ダイレクト VPC 下り（外向き）で構成された Cloud Run サービスまたはジョブに対して NAT を実行できます。ダイレクト VPC 下り（外向き）インスタンスで Public NAT ゲートウェイを使用できるようにするには、次の設定で Public NAT ゲートウェイを構成します。

  • リージョン内のすべてのサブネットのすべての IP アドレス範囲で Public NAT ゲートウェイを使用できるようにするには、--nat-all-subnet-ip-ranges フラグを指定します。
  • --endpoint-types フラグの値を ENDPOINT_TYPE_VM に設定します。この値により、VM（ダイレクト VPC 下り（外向き）VM を含む）のみが Public NAT ゲートウェイを使用できるようになります。
  • 静的ポートの割り当ての場合は、--min-ports-per-vm フラグの値を、単一の Cloud Run インスタンスに必要なポート数の 4 倍に設定します。
  • NAT IP アドレスの手動割り当ての場合は、Google Cloud インスタンスの数と VPC ネットワークにデプロイしたダイレクト VPC 下り（外向き）インスタンスの数の合計を考慮して、Public NAT ゲートウェイに適切な数の IP アドレスを割り当てます。

ゲートウェイ構成に加えて、Cloud Run サービスまたはジョブから下り（外向き）トラフィックを送信するには、サービスまたはジョブを作成する際に --vpc-egress フラグを all-traffic に設定する必要があります。

--vpc-egress フラグを private-ranges-only に設定して Cloud Run サービスまたはジョブを構成した場合、サービスまたはジョブは内部 IP アドレスにのみトラフィックを送信します。内部の宛先にトラフィックをルーティングするために Public NAT ゲートウェイは必要ありません。

--vpc-egress フラグが private-ranges-only に設定されている Cloud Run サービスまたはジョブが Public NAT ゲートウェイを使用できないようにするには、次の手順を行います。

  • --nat-custom-subnet-ip-ranges フラグを使用して Public NAT ゲートウェイを構成します。
  • --nat-custom-subnet-ip-ranges フラグの値を、--vpc-egress フラグを all-traffic に設定して Cloud Run サービスまたはジョブをデプロイしたサブネット名に設定します。

Public NAT ゲートウェイを使用する Cloud Run サービスとジョブには、次の制限が適用されます。

  • ダイレクト VPC 下り（外向き）エンドポイントの Cloud NAT 指標は、Cloud Monitoring にエクスポートされません。
  • ダイレクト VPC 下り（外向き）の Cloud NAT ログには、Cloud Run サービス、リビジョン、ジョブの名前は表示されません。

ダイレクト VPC 下り（外向き）インスタンスで Private NAT ゲートウェイを使用することはできません。

接続テストの相互作用

接続テストを使用すると、Cloud NAT 構成を使用するネットワーク エンドポイント間の接続を確認できます。接続テストは、Public NAT ゲートウェイまたは Private NAT ゲートウェイのいずれか、または両方を使用するネットワークで実行できます。

NAT 構成の詳細は、[接続テストの詳細] ページの [構成分析トレース] ペインで確認できます。

Cloud Load Balancing の相互作用

Google Cloud のリージョン内部アプリケーション ロードバランサとリージョン外部アプリケーション ロードバランサは、複数のリージョン インターネット ネットワーク エンドポイント グループ（NEG）バックエンドとやり取りを行います。リージョン インターネット NEG に Cloud NAT ゲートウェイを構成することで、Google Cloud トラフィックの発信元となる独自の外部 IP アドレス範囲のセットを割り当てることができます。ヘルスチェックとデータプレーンのトラフィックは、割り振った NAT IP アドレスから送信されます。

その他の Google Cloud の外部ロードバランサとヘルスチェック システムは特別なルートを使用して VM と通信します。バックエンド VM は外部 IP アドレスを必要とせず、Cloud NAT ゲートウェイはロードバランサとヘルスチェックの通信を管理しません。詳細については、Cloud Load Balancing の概要とヘルスチェックの概要をご覧ください。

次のステップ