構成のトラブルシューティング

このガイドは、Cloud NAT の一般的な問題の解決に役立ちます。

一般的な問題

Cloud NAT なしで VM が予期せずにインターネットに接続することがある

Cloud NAT を使用せずに仮想マシン（VM）インスタンスまたはコンテナ インスタンスがインターネットに接続可能で、このような接続を行いたくない場合は、次の問題を確認してください。

  • VM のネットワーク インターフェースに外部 IP アドレスがあるかどうかを確認します。ネットワーク インターフェースに外部 IP アドレスが割り当てられている場合、Google Cloud は、インターフェースのプライマリ内部 IP アドレスに一致するパケットに 1 対 1 の NAT を自動的に実行します。詳細については、Cloud NAT の仕様をご覧ください。

    VM に外部 IP アドレスがあるかどうかを判断するには、既存のインスタンスに対する外部 IP アドレスの変更または割り当てをご覧ください。

  • Google Kubernetes Engine（GKE）クラスタが限定公開クラスタであることを確認します。非限定公開クラスタの各ノード VM には外部 IP アドレスがあるため、各ノードは、Cloud NAT に依存することなく、ネクストホップはデフォルト インターネット ゲートウェイである Virtual Private Cloud（VPC）ネットワーク内のルートを使用できます。非限定公開クラスタと Cloud NAT ゲートウェイとのやり取りなどの詳細については、Compute Engine の相互作用をご覧ください。

  • Virtual Private Cloud ネットワーク内のルートをリストアップして、デフォルトのインターネット ゲートウェイとは異なるネクストホップ経由でインターネット接続を提供できるルートを探します。次のような例が挙げられます。

    • ネクストホップが VM、内部パススルー ネットワーク ロードバランサ、または Cloud VPN トンネルであるカスタム静的ルートは、インターネット接続を間接的に提供する場合があります。たとえば、内部パススルー ネットワーク ロードバランサのネクストホップ VM またはバックエンド VM 自体が外部 IP アドレスを持つ場合や、Cloud VPN トンネルがインターネット アクセスを提供するネットワークに接続する場合です。

    • VPC ネットワーク内の Cloud Router によってオンプレミス ネットワークから学習されたカスタム動的ルートは、インターネット アクセスを提供するネットワークに接続する場合があります。

  • VPC ネットワーク内の他のカスタムルートの優先度は、ネクストホップがデフォルトのインターネット ゲートウェイであるルートより優先されます。Google Cloud によるルートの評価方法については、適用範囲と順序をご覧ください。

ログが生成されない

  • NAT ロギングが有効になっていることを確認します。

  • 探しているログがフィルタで除外されていない非表示になっていないかどうか再度確認します。手順については、ログの表示をご覧ください。

  • ファイアウォール ルールによってトラフィックがブロックされていないことを確認します。トラフィックが NAT ゲートウェイに送信される前に、下り（外向き）トラフィックをブロックするファイアウォール ルールが適用されます。ファイアウォール ルール ロギングを使用すると、カスタムの下り（外向き）ルールが送信トラフィックをブロックしているかどうかを確認できます。

  • Cloud NAT の種類を確認してください。トラフィックの宛先を NAT が処理しない場合があります。

一部のログが除外される

  • NAT ロギングが有効であり、保持対象のログがログフィルタで除外されていないことを確認します。ログフィルタを消去すると、除外対象をなくすことができます。

  • Cloud NAT により、すべてのイベントが記録されるわけではありません。下り（外向き）トラフィックが多い間は、NAT のロギングは VM のマシンタイプに応じて抑制されます。変換またはエラーログが破棄される可能性があり、抑制中に何が省略されるかは特定できません。

リソース不足によってパケットがドロップされる

Cloud NAT を使用する VM からのパケットロスが発生している場合、パケットロスの発生時に VM が使用できる NAT 送信元 IP アドレスと送信元ポートのタプルが十分でない可能性があります（ポートの枯渇）。TCP TIME_WAIT タイムアウトの間、5 タプル（NAT 送信元 IP アドレス、送信元ポート、宛先 3 タプル）は再利用できません。

使用可能な NAT タプルが十分でない場合、dropped_sent_packets_count の理由は OUT_OF_RESOURCES です。指標の詳細については、VM インスタンスの指標の使用をご覧ください。

ポートの使用量を減らす方法については、ポートの使用量を削減するをご覧ください。

動的ポート割り当てを使用している場合に、動的ポート割り当て使用時のパケットのドロップを減らす方法については、次のセクションをご覧ください。

動的ポート割り当てが構成されているときにパケットがドロップされる

動的ポート割り当ては、VM がポートを使い切りそうになるタイミングを検出し、VM に割り当てられるポートの数を 2 倍に増やします。この動作によりポートが無駄になることはありませんが、割り当てられるポート数が増加している間にパケットがドロップされる場合があります。

ドロップされるパケット数を削減するために、次の点を考慮してください。

  • 接続を徐々に増やせる場合は、Cloud NAT は、追加ポートの割り当てにより多くの時間を使用します。

  • VM が TCP 接続を行っている場合は、tcp_syn_retries により大きな値を持つ VM を構成できます。これにより、システムが接続を確立するまでに与えられる時間が長くなり、接続が成功する可能性が高くなります。

    たとえば、Linux VM の場合、次のコマンドで現在の設定を表示できます。

      sysctl net.ipv4.tcp_syn_retries

    必要に応じて、設定値を増やします。

      sudo sysctl -w net.ipv4.tcp_syn_retries=NUM

  • ワークロードが急増し、より多くのポートをすばやく割り当てる必要がある場合、VM あたりの最小ポート数の調整が必要になることがあります。ポートの使用量を表示し、VM あたりの適切な最小ポート数を決定します。

エンドポイントに依存しない競合によってパケットがドロップされる

Public NAT を使用する VM からのパケットロスが発生し、エンドポイントに依存しないマッピングが有効になっている場合、このパケットロスの原因はエンドポイントに依存しない競合である可能性があります。その場合、dropped_sent_packets_count の理由は ENDPOINT_INDEPENDENT_CONFLICT です。指標の詳細については、VM インスタンスの指標の使用をご覧ください。

エンドポイントに依存しない競合が発生する可能性を減らすには、次の方法があります。

  • エンドポイントに依存しないマッピングを無効にします。これにより、特定の送信元 IP アドレスとポートからの新しい接続で、以前使用したことのない別の NAT 送信元 IP アドレスとポートを使用できます。エンドポイントに依存しないマッピングを無効または有効にしても、確立済みの接続は中断されません。

  • VM インスタンスあたりの NAT ポートのデフォルトの最小数を増やして、ポート予約手順で、より多くの NAT 送信元 IP アドレスと送信元ポートのタプルが各クライアント VM に割り当てられるようにします。これにより、クライアント IP アドレスとエフェメラル送信元ポートの 2 つ以上のタプルが同じ NAT 送信元 IP アドレスと送信元ポートのタプルに割り当てられる可能性を減らすことができます。

  • 使用されているエフェメラル送信元ポートの数を確認します。

    • Linux VM の場合:

      netstat -an | egrep 'ESTABLISHED|TIME_WAIT|CLOSE_WAIT' | wc -l

    • Windows VM の場合:

      netstat -tan | findstr "ESTABLISHED TIME_WAIT CLOSE_WAIT" | find /c /v ""

  • 使用可能なエフェメラル送信元ポートを増やすように VM インスタンスを構成します。

    • Linux VM の場合:

      • 次のコマンドを使用すると、構成されているポート範囲を表示できます。

        cat /proc/sys/net/ipv4/ip_local_port_range

      • 次のコマンドを使用すると、ip_local_port_range を、エフェメラル送信元ポートの最大数（64,512）に設定できます。

        echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range

    • Windows VM の場合:

      • 次のコマンドを使用すると、構成されているポート範囲を表示できます。

        netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp

      • 次のコマンドを使用すると、エフェメラル送信元 TCP ポートと UDP ポートの数を最大数（64,512）に設定できます。

        netsh int ipv4 set dynamicport tcp start=1024 num=64512
netsh int ipv4 set dynamicport udp start=1024 num=64512

      • Google Kubernetes Engine ノードでは、特権 DaemonSet を使用してこの構成を自動化できます。

  • GKE クラスタの場合、特定の宛先に送信されるパケットに対して各ノードで実行される送信元 NAT を無効にできます。これは、次の 2 つのうちのいずれかの方法で行うことができます。

追加の IP アドレスを割り振る必要がある

NAT IP アドレスが不足しているため、VM がインターネットに接続できない場合があります。この問題は、さまざまな要因で発生する可能性があります。詳しくは以下の表をご覧ください。

根本原因 症状 解決策
手動でアドレスを割り振りましたが、現在のポートの使用量を考慮すると、十分なアドレスが割り振られていません。
  • Google Cloud コンソールに「すべてのインスタンスがインターネットにアクセスできるようにするには、IP アドレスを少なくとも X 個割り当てる必要があります」というエラーが表示されます。
  • nat_allocation_failed 指標の値が true です。

次のいずれかを行います。
NAT IP アドレスのハードリミットを超過しました。

IP アドレスの不足に起因する障害をモニタリングするには、nat_allocation_failed 指標のアラートを作成します。Google Cloud が NAT ゲートウェイ内の VM に十分な IP アドレスを割り振ることができない場合、この指標は true に設定されます。アラート ポリシーの詳細については、アラート ポリシーの定義をご覧ください。

ポートの使用量を削減する

NAT IP アドレスの割り振りが不可能か、望ましくない場合は、各 VM が使用するポート数を最小限に抑えることができます。

ポートの使用量を削減するには、次の手順を行います。

  1. エンドポイントに依存しないマッピングを無効にします。

  2. 動的ポートの割り当てを有効にします。動的ポートの割り当てを使用するには、VM あたりの最小ポート数と VM あたりの最大ポート数を設定します。Cloud NAT は、ポートの最小数から最大数までの間で、いくつかの NAT 送信元 IP アドレスと送信元ポートのタプルを自動的に割り当てます。最小ポート数に小さい数を使用すると、アクティブな接続の少ない VM で NAT の送信元 IP アドレスと送信元ポートのタプルの無駄が少なくなります。ポートの割り当て中に接続タイムアウトが発生した場合は、動的ポートの割り当てによるパケットのドロップを減らすをご覧ください。

  3. ニーズを満たす最小のポート数を決定します。この方法はいくつかありますが、ほとんどの場合、使用されるポート（compute.googleapis.com/nat/port_usage）の数を確認して行います。ポートの使用量を確認する方法については、ポートの使用量を表示するをご覧ください。ポートの最小数を決める方法を 2 つ紹介します。

    • 代表的な VM 数に対する代表的な期間の compute.googleapis.com/nat/port_usage の平均値を検討します。
    • 代表的な VM 数に対する代表的な期間で、最も頻繁に発生している compute.googleapis.com/nat/port_usage の値を検討します。

  4. ニーズを満たす最大のポート数を決定します。もう一度、判断材料として compute.googleapis.com/nat/port_usage を確認します。最大ポート数を判断する出発点として、代表的な VM 数に対する代表的な期間の compute.googleapis.com/nat/port_usage の最大値を検討します。最大数を大きくしすぎると、他の VM が NAT の送信元 IP アドレスと送信元ポートのタプルを受信できなくなる可能性があります。

  5. 適切なポートの最小値と最大値を見つけるには、反復テストが必要です。最小ポート数と最大ポート数を変更する手順については、動的ポート割り当てが構成されている場合に最小ポート数または最大ポート数を変更するをご覧ください。

  6. NAT タイムアウトとその意味、デフォルト値を確認します。同じ宛先 3 タプルに対する一連の TCP 接続を迅速に作成する必要がある場合は、Cloud NAT が NAT の送信元 IP アドレスと送信元ポートのタプルをより迅速に再利用できるように、TCP の待機時間を短縮することを検討してください。 これにより、Cloud NAT は、送信元 VM ごとに NAT の送信元 IP アドレスと送信元ポートのタプルを追加で割り当てる必要がある一意の 5 タプルを使用する代わりに、同じ 5 タプルを迅速に使用できます。NAT タイムアウトを変更する手順については、NAT タイムアウトを変更するをご覧ください。

よくある質問

Cloud NAT のリージョン制限

複数のリージョンで同じ Cloud NAT ゲートウェイを使用できますか？

いいえ。1 つの Cloud NAT ゲートウェイを複数のリージョン、VPC ネットワーク、Cloud Router に関連付けることはできません。

他のリージョンや VPC ネットワークに接続する必要がある場合は、追加の Cloud NAT ゲートウェイを作成します。

Cloud NAT ゲートウェイが使用する外部 NAT IP アドレスはグローバルまたはリージョナルのどちらですか？

Cloud NAT ゲートウェイは、NAT IP アドレスとしてリージョン外部 IP アドレスを使用します。これはリージョン リソースですが、ルーティングで利用可能です。NAT IP アドレスのさまざまな割り振り、割り当て方法については、NAT IP アドレスをご覧ください。

Cloud NAT を使用できる場合と、使用できない場合について

GKE ノード VM などの外部 IP アドレスを持つインスタンスに Cloud NAT は適用されますか？

通常は適用されません。VM のネットワーク インターフェースに外部 IP アドレスが割り振られている場合、Google Cloud は Cloud NAT を使用せず、ネットワーク インターフェースのプライマリ内部 IP アドレスから送信されたパケットに対して 1 対 1 の NAT を実行します。ただし、同じネットワーク インターフェースのエイリアス IP アドレス範囲から送信されたパケットに対しては、Cloud NAT からが NAT サービスを提供できます。詳細については、Cloud NAT の仕様と Compute Engine の相互作用をご覧ください。

VPC ネットワークの VM 間の通信に Cloud NAT を使用できますか？

いいえ。Cloud NAT はインターネットのみに接続できるように設計されています。

Cloud NAT を使用して VPC ネットワークを別のネットワークに接続し、IP アドレスの重複を回避できますか？

いいえ。ネクストホップがデフォルトのインターネット ゲートウェイではないカスタムルートに Cloud NAT を適用できません。たとえば、宛先がルーティング可能な IP アドレスであっても、ネクストホップの Cloud VPN トンネルに送信されるトラフィックに Cloud NAT を適用することはできません。

送信元と宛先が同じ VPC ネットワーク内にある場合でも、Cloud NAT を使用して、ネットワーク インターフェースに外部 IP アドレスのない送信元 VM から宛先の VM または外部 IP アドレスを持つロードバランサにトラフィックを送信できますか？

はい。トラフィックは、VPC ネットワークからデフォルトのインターネット ゲートウェイを経由して同じネットワーク内の宛先に届きます。

送信元の VM が宛先にパケットを送信すると、Cloud NAT は送信元 NAT（SNAT）を実行してから、2 番目のインスタンスにパケットを配信します。2 番目のインスタンスから最初のインスタンスへのレスポンスに対して、Cloud NAT は、宛先 NAT（DNAT）を実行します。詳しい手順の例については、基本的な Public NAT の構成とワークフローをご覧ください。

未承諾の受信接続の未サポートについて

Cloud NAT で、外部 IP アドレスのないインスタンスへの受信接続（SSH など）は許可されていますか？

いいえ、Cloud NAT は未承諾の受信接続をサポートしていません。詳細については、Cloud NAT の仕様をご覧ください。

外部 IP アドレスが設定されていない VM に接続する必要がある場合は、内部専用 VM の接続オプションを選択するをご覧ください。たとえば、Compute Engine で Cloud NAT を設定する例では、Identity-Aware Proxy を使用して外部 IP アドレスなしで VM に接続します。

Cloud NAT とポート

VM のポート数が固定（デフォルトで 64）されているのはなぜですか？

Cloud NAT ゲートウェイが VM に NAT を提供するときに、ポート予約手順に従って送信元アドレスと送信元ポートのタプルを予約するためです。

詳細については、ポート予約の例をご覧ください。

VM に予約されているポートの最小数を変更できますか？

はい。新しい Cloud NAT ゲートウェイを作成するとき、または後で編集することにより、VM ごとの最小ポート数を変更できます。Cloud NAT ゲートウェイは、ポート予約手順に従って送信元アドレスと送信元ポートのタプルを予約します。

ポートの最小数を減らす場合については、減少についての詳細は、次の質問をご覧ください。

Cloud NAT ゲートウェイを作成した後、VM あたりの最小ポート数を減らすことはできますか？

はい。ただし、ポートの最小数を減らすと、ポート予約手順で予約される VM あたりのポート数が少なくなります。この場合、既存の TCP 接続はリセットされる可能性があり、リセットされた場合は再確立する必要があります。

NAT マッピングをプライマリ範囲とセカンダリ範囲からプライマリ範囲のみに切り替えると、各インスタンスに追加で割り当てられているポートは直ちに解放されますか？

いいえ。セカンダリ範囲で使用される追加のポートは、VM あたりの最小ポートの設定を小さくするまでインスタンスによって保持されます。Cloud NAT がサブネットのセカンダリ（エイリアス）範囲をマッピングするように構成されている場合、Cloud NAT はポート予約手順に基づいてインスタンスごとに最小の 1,024 ポートを割り当てます。

プライマリ範囲のみに切り替えることで、Cloud NAT は、これらのポートが割り当てられているインスタンスの追加ポートを保護します。Cloud NAT の適用範囲をプライマリのみに変更した後、VM あたりの最小ポート数の設定を小さくするまで、そのインスタンスに割り当てられた実際のポート数は変更されません。

そうしたインスタンスに割り当てられるポート数を減らすには、プライマリ範囲に切り替えた後、VM あたりの最小ポート数の設定を小さくする必要があります。この値を小さくすると、Cloud NAT はインスタンスごとに割り当てられるポートの数を自動的に調整します。これにより、ポートの消費量が削減されます。

Cloud NAT とその他の Google サービス

Cloud NAT で Google API やサービスへのアクセスを有効にできますか？

サブネットのプライマリ IP 範囲に Cloud NAT を有効にすると、Google Cloud は自動的に限定公開の Google アクセスを有効にします。詳細については、限定公開の Google アクセスの相互作用をご覧ください。

次のステップ