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

このガイドは、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
    

  注: tcp_syn_retries の値を大きくすると、再試行が複数回行われた後も接続が成功するまでパケットが継続的にドロップされるため、レイテンシが生じる可能性があります。

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

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

注: このセクションは、Private NAT には適用されません。

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-masq-agent をデプロイし、目的の宛先を nonMasqueradeCIDRs のリストに追加する。

  • クラスタの作成時に --disable-default-snat フラグを使用し、マスカレード以外のデフォルトノ宛先に対して SNAT を無効にする。

ドロップした受信パケット数

Cloud NAT ゲートウェイは、接続トラッキング テーブルを維持して、アクティブな接続の詳細と、IP アドレスとポートのマッピング（VM の IP アドレスとポートを NAT IP アドレスとポートに変換する方法）を保存します。接続トラッキング テーブルに接続のエントリが含まれていない場合、Cloud NAT ゲートウェイは上り（内向き）データパケットを破棄します。

テーブルに接続エントリがない場合、次のいずれかの理由が考えられます。

• アクティブでないために TCP 確立済み接続のアイドル タイムアウトが期限切れとなったため、確立済みの TCP 接続がタイムアウトしました。
• TCP 一時接続のアイドル タイムアウトが期限切れになる前に、外部エンドポイントが新しい接続を確立できない。たとえば、Google Cloud リソースは TCP SYN との接続を開始しますが、外部エンドポイントは SYN ACK で応答しません。
• プローバーなどの外部エンドポイントが、NAT IP アドレスとポートへの接続を試みます。Cloud NAT は未承諾の受信接続を受け入れません。これらのタイプの接続のエントリは、接続テーブルに存在しません。そのため、受信パケットはすべて破棄されます。
• NAT 接続がアクティブなときにゲートウェイから NAT IP を削除すると、NAT マッピングは無効になり、これらの接続は接続トラッキング テーブルから直ちに削除され、戻りトラフィックが破棄されます。

上り（内向き）パケットのドロップに対処する前に、ドロップが実際にアプリケーションに影響を与えるかどうかを確認します。確認するには、破棄された上り（内向き）パケットが急増するたびにアプリケーションのエラーを確認します。

上り（内向き）パケットのドロップがアプリケーションに影響を与える場合は、次の方法で問題を解決してください。

• アプリケーションでキープアライブ メカニズムを使用して、長時間実行される接続を長期間開いたままにできるようにします。
• TCP 一時接続のアイドル タイムアウトの値を増やして、Cloud NAT ゲートウェイ経由で（Google Cloud リソースによって開始された）トラフィックを受信する外部エンドポイントが応答して接続を確立するまでの時間を長くします。
• デフォルト値を大幅に小さくした場合は、TCP 確立済み接続のアイドル タイムアウトの値を増やします。

注: TCP 一時接続のアイドル タイムアウトと TCP 確立済み接続のアイドル タイムアウトの値を大きくすると、Cloud NAT のポートの再利用方法に影響します。ゲートウェイは、接続を確立できない場合や、しばらくトラフィックを受信しない場合でも、接続にマッピングされたポートをより長期間保持します。

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

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

根本原因	症状	解決策
手動でアドレスを割り振りましたが、現在のポートの使用量を考慮すると、十分なアドレスが割り振られていません。	Google Cloud コンソールに「すべてのインスタンスがインターネットにアクセスできるようにするには、少なくとも X 個以上の IP アドレスを割り振る必要があります」というエラーが表示されます。 nat_allocation_failed 指標の値が true です。	次のいずれかを行います。 ポート使用量を削減するの説明に沿って、ポートの使用量を最小限にします。 NAT に関連付けられた外部 IP アドレスの変更の説明に沿って、手動で IP アドレスを追加します。
NAT IP アドレスのハードリミットを超過しました。	nat_allocation_failed 指標の値が true です。	ポート使用量を削減するの説明に沿って、ポートの使用量を最小限にします。

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

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

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

重要: エンドポイントに依存しないマッピングが必要な場合、このセクションの推奨事項は適用されません。NAT ゲートウェイに構成する、使用可能な NAT IP アドレスとポートのタプルを増やすか、複数の NAT ゲートウェイを使用する必要があります。

警告: 動的ポート割り当てを有効または無効にする場合や、VM あたりの最小ポート数を減らした場合は、確立済みの接続が中断されることがあります。詳細については、ポートの割り当て方法の切り替えと 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 ネットワーク内にある場合でも、Public NAT を使用して、ネットワーク インターフェースに外部 IP アドレスのない送信元 VM から宛先の VM または外部 IP アドレスを持つロードバランサにトラフィックを送信できますか？

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

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

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

いいえ、Private NAT は、同じ VPC ネットワーク内の VM 間のトラフィックに対して NAT を実行しません。

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

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

いいえ、Cloud NAT は未承諾の受信接続をサポートしていません。詳細については、Cloud NAT の仕様をご覧ください。 ただし、宛先 IP アドレスが 1 つ以上の VM インスタンスへの有効なポート マッピングを持つ Cloud NAT ゲートウェイの外部 IP アドレスである場合、Google Cloud のネットワーク エッジは ping に応答する可能性があります。Cloud NAT ゲートウェイに割り当てられた IP アドレスを確認するには、gcloud compute routers get-nat-ip-info コマンドを使用します。IN_USE とマークされた外部 IP アドレスは ping に応答する可能性があります。

外部 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 アクセスの相互作用をご覧ください。

次のステップ

• サポートを利用する