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 は次のルートを使用します。

  • Network Connectivity Center スポークの場合、Private NAT はサブネット ルートと動的ルートを使用します。
    • VPC スポークのみを含む Network Connectivity Center ハブに接続された 2 つの VPC スポーク間のトラフィックに、Private NAT は接続された VPC スポークによって交換されるサブネット ルートを使用します。VPC スポークの詳細については、VPC スポークの概要をご覧ください。
    • Network Connectivity Center ハブに VPC スポークとハイブリッド スポーク（Cloud Interconnect の VLAN アタッチメント、Cloud VPN トンネル、ルーター アプライアンス VM など）の両方が含まれている場合、プライベート NAT は、ハイブリッド スポークが BGP を介して学習した動的ルート、および接続された VPC スポークによって交換されたサブネット ルートを使用します。ハイブリッド スポークの詳細については、ハイブリッド スポークをご覧ください。
  • ハイブリッド NAT の場合、Private NAT は Cloud Interconnect または 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 ゲートウェイは、VPC ネットワーク ピアリングで接続された他の VPC ネットワーク内の VM に、NAT を提供できません。ピア ネットワーク内の VM がゲートウェイと同じプロジェクトに存在する場合も同様です。

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 で処理されません。ただし、次の条件がどちらも当てはまる場合、限定公開以外のクラスタ内の Pod から送信されたパケットは、Public NATゲートウェイで処理できます。

  • VPC ネイティブ クラスタの場合、Public NATゲートウェイがクラスタの Pod のセカンダリ IP アドレス範囲に適用されるように構成ます。

  • クラスタの IP マスカレード構成は、Pod からインターネットに送信されるパケットのクラスタ内で SNAT を実行するように構成されていません。

次の例は、Public NATと GKE の関係を示しています。

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

この例では、コンテナで 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 を実行できます。Cloud Run でPublic NATゲートウェイを使用できるようにするには、次の設定でPublic NATゲートウェイを構成します。

  • Cloud Run インスタンスに関連付けられているサブネットとサブネット IP アドレス範囲でPublic NATゲートウェイを使用できるように構成するには、--nat-all-subnet-ip-ranges フラグまたは --nat-custom-subnet-ip-ranges フラグを指定します。
    • リージョン内のすべてのサブネットのすべての IP アドレス範囲でPublic NATゲートウェイを使用できるようにするには、--nat-all-subnet-ip-ranges フラグを指定します。
    • 特定のサブネットとサブネット IP アドレス範囲のみがPublic NATゲートウェイを使用できるようにするには、--nat-custom-subnet-ip-ranges フラグで指定します。
  • --endpoint-types フラグの値を ENDPOINT_TYPE_VM に設定する。 この値により、VM と Direct VPC 下り（外向き）VM エンドポイントのみがPublic NATゲートウェイを使用できるようになります。
  • 静的ポートの割り当ての場合は、--min-ports-per-vm フラグの値を、単一の Cloud Run インスタンスに必要なポート数の 4 倍に設定します。
  • NAT IP アドレスの手動割り振りの場合は、Google Cloud インスタンスの数と VPC ネットワークにデプロイした Cloud Run インスタンスの数の合計を考慮して、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ゲートウェイを使用できないようにするには、次の手順を行います。

  • Public NATゲートウェイを --nat-custom-subnet-ip-ranges フラグで構成します。
  • --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 サービス、リビジョン、ジョブの名前は表示されません。

Direct 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 の概要とヘルスチェックの概要をご覧ください。

次のステップ