次の方法で共有

Azure NAT Gateway 接続のトラブルシューティング

  • [アーティクル]

この記事では、NAT ゲートウェイでの一般的なアウトバウンド接続の問題のトラブルシューティングを行って解決する方法について説明します。 また、この記事では、送信接続を効率的に使用するようにアプリケーションを設計する方法に関するベスト プラクティスも示します。

接続エラーがある NAT ゲートウェイでのデータパスの可用性の低下

シナリオ

NAT ゲートウェイのデータパスの可用性が低下しているときは、接続エラーが同時に発生しています。

考えられる原因

  • 送信元ネットワーク アドレス変換 (SNAT) ポートの枯渇。

  • 同時 SNAT 接続の制限。

  • 接続タイムアウト。

トラブルシューティングの手順

SNAT ポートの枯渇または同時接続制限への到達に関して考えられる解決策

  • NAT ゲートウェイにパブリック IP アドレスを最大 16 個まで追加して、アウトバウンド接続をスケーリングします。 各パブリック IP では、64,512 個の SNAT ポートが提供され、NAT ゲートウェイの一意の接続先エンドポイントごとに最大 50,000 の同時接続がサポートされます。

  • アプリケーション環境を複数のサブネットに分散し、各サブネットに NAT ゲートウェイ リソースを提供します。

  • TCP アイドル タイムアウト タイマーの値を小さくして、SNAT ポート インベントリを解放します。 TCP アイドル タイムアウト タイマーを 4 分より短く設定することはできません。

  • 非同期ポーリング パターンを使って、他の操作のために接続リソースを解放することを検討します。

  • Private Link を使って、Azure バックボーン経由で Azure PaaS サービスに接続します。 Private Link を使うと、インターネットへのアウトバウンド接続用の SNAT ポートが解放されます。

  • 調べてもわからない場合は、サポート ケースを開いてさらに詳細なトラブルシューティングを行います。

Note

SNAT ポートの枯渇が発生する理由を把握することが重要です。 スケーラブルで信頼性の高いシナリオに適したパターンを使っていることを確認します。 需要の原因を理解できないままさらに多くの SNAT ポートをシナリオに追加することは最後の手段にする必要があります。 現在のシナリオで SNAT ポート インベントリに負荷がかかっている理由を把握できない場合、IP アドレスを追加することで SNAT ポートを追加しても、アプリケーションをスケーリングしたときに同じ枯渇の障害が発生するのを遅らせるだけです。 他の非効率性やアンチパターンを隠すことになります。 詳細については、「送信接続を効率的に使用するためのベスト プラクティス」を参照してください。

TCP 接続タイムアウトの考えられる解決策

TCP キープアライブまたはアプリケーション層キープアライブを使って、アイドル フローを更新し、アイドル タイムアウト タイマーをリセットします。 例については、.NET の例に関する記事をご覧ください。

TCP キープアライブは、片側の接続から有効にするだけで、両側からの接続が維持されます。 接続の一方の側から TCP キープアライブが送信されると、もう一方の側は肯定応答 (ACK) パケットを自動的に送信します。 その後、アイドル タイムアウト タイマーが、接続の両側でリセットされます。

Note

TCP アイドル タイムアウトを増やすことは最後の手段であり、問題の根本原因が解決されるとは限りません。 タイムアウトが長いと遅延が発生し、タイムアウトが切れると必要のない低速エラーが発生する可能性があります。

ユーザー データグラム プロトコル (UDP) 接続タイムアウトの考えられる解決策

UDP アイドル タイムアウト タイマーは 4 分に設定されており、構成できません。 接続フローの両方向で UDP キープアライブを有効にして、長い接続を維持します。 UDP キープアライブを有効にすると、接続の一方向に対してのみアクティブになります。 接続はアイドル状態になり、接続の反対側でタイムアウトになる可能性があります。 UDP 接続がアイドル タイムアウトにならないようにするには、UDP キープアライブを接続フローの両方向に対して有効にする必要があります。

アプリケーション レイヤーのキープアライブを使用して、アイドル フローを更新し、アイドル タイムアウトをリセットすることもできます。 サーバー側で、アプリケーション固有のキープアライブのどのようなオプションが存在するかを確認します。

接続エラーがない NAT ゲートウェイでのデータパスの可用性の低下

シナリオ

NAT ゲートウェイのデータパスの可用性は低下しますが、接続がエラーになることはありません。

考えられる原因

データパスのノイズによって発生するデータパスの可用性の一時的な低下。

トラブルシューティングの手順

アウトバウンド接続に影響を与えずにデータパスの可用性が低下する場合は、NAT ゲートウェイがデータパスの一時的なノイズを拾っていることが原因である可能性があります。

データパスの可用性低下に対するアラートを設定するか、Azure Resource Health を使って NAT Gateway の正常性イベントを通知します。

インターネットへの送信接続がない

シナリオ

NAT ゲートウェイでアウトバウンド接続が検出されません。

考えられる原因

  • NAT ゲートウェイの構成の誤り。

  • インターネット トラフィックが NAT ゲートウェイ外にリダイレクトされ、VPN または ExpressRoute によって仮想アプライアンスまたはオンプレミスの接続先に強制的にトンネリングされています。

  • ネットワーク セキュリティ グループ (NSG) の規則が、インターネット トラフィックをブロックするように構成されています。

  • NAT ゲートウェイのデータパスの可用性が低下しています。

  • ドメイン ネーム システム (DNS) の構成の誤り。

トラブルシューティングの手順

  • NAT ゲートウェイが少なくとも 1 つのパブリック IP アドレスまたはプレフィックスを使って構成され、サブネットにアタッチされていることを調べます。 NAT ゲートウェイは、パブリック IP とサブネットがアタッチされるまで動作しません。 詳しくは、「AT ゲートウェイ構成の基本」をご覧ください。

  • NAT ゲートウェイにアタッチされているサブネットのルーティング テーブルを調べます。 ネットワーク仮想アプライアンス (NVA)、ExpressRoute、または VPN Gateway に強制的にトンネリングされるすべての 0.0.0.0/0 トラフィックは、NAT ゲートウェイよりも優先されます。 詳しくは、「Azure がルートを選択するしくみ」をご覧ください。

  • お使いの仮想マシンで、インターネット アクセスをブロックする NSG 規則がネットワーク インターフェイスに対して構成されているかどうかを調べます。

  • NAT ゲートウェイのデータパスの可用性が低下した状態になっているかどうかを調べます。 NAT ゲートウェイの状態が低下している場合は、接続エラーのトラブルシューティング ガイダンスを参照してください。

  • DNS が正しく解決されていない場合は、DNS の設定を調べます。

アウトバウンド接続が失われる場合の考えられる解決策

  • パブリック IP アドレスまたはプレフィックスを NAT ゲートウェイにアタッチします。 また、NAT ゲートウェイが同じ仮想ネットワークのサブネットにアタッチされていることを確認します。 NAT ゲートウェイがアウトバウンドに接続できることを検証します。

  • 仮想ネットワークのトラフィック ルートを変更する前に、トラフィック ルーティングの要件を慎重に検討します。 仮想アプライアンスまたは仮想ネットワーク ゲートウェイに 0.0.0.0/0 トラフィックを送信するユーザー定義ルート (UDR) は、NAT ゲートウェイをオーバーライドします。 カスタム ルートがネットワーク トラフィックのルーティングに与える影響について詳しくは、「カスタム ルート」をご覧ください。

    サブネット ルーティング テーブルのトラフィック ルートの更新に関するオプションを調べるには、以下を参照してください。

  • いずれかの VM のインターネット アクセスをブロックしている NSG セキュリティ規則を更新します。 詳しくは、ネットワーク セキュリティ グループの管理に関する記事をご覧ください。

  • DNS は、さまざまな理由で正しく解決されない可能性があります。 DNS の解決が失敗する理由の調査については、DNS トラブルシューティング ガイドに関する記事をご覧ください。

NAT ゲートウェイのパブリック IP がアウトバウンド接続に使用されない

シナリオ

NAT ゲートウェイは Azure 仮想ネットワークにデプロイされていますが、予期しない IP アドレスがアウトバウンド接続に使われます。

考えられる原因

  • NAT ゲートウェイの構成の誤り。

  • Azure Load Balancer や仮想マシン上のインスタンス レベルのパブリック IP など、別の Azure アウトバウンド接続方法でのアクティブな接続。 アクティブな接続フローでは、接続の確立時に割り当てられた以前のパブリック IP アドレスが引き続き使われます。 NAT ゲートウェイがデプロイされると、新しい接続によってすぐに NAT ゲートウェイが使われ始めます。

  • プライベート IP が、サービス エンドポイントまたは Private Link によって Azure サービスに接続するために使われています。

  • 接続元の仮想マシンと同じリージョンから、ストレージ アカウントへの接続が行われています。

  • インターネット トラフィックが NAT ゲートウェイから外にリダイレクトされて、NVA またはファイアウォールに強制的にトンネリングされています。

トラブルシューティングの方法

  • NAT ゲートウェイに、少なくとも 1 つのパブリック IP アドレスまたはプレフィックスが関連付けられていて、少なくとも 1 つのサブネットがあることを確認します。

  • パブリック ロード バランサーなど、以前のアウトバウンド接続方法が、NAT ゲートウェイのデプロイ後もまだアクティブになっているかどうかを確認します。

  • 他の Azure サービスへの接続が、自分の Azure 仮想ネットワーク内のプライベート IP アドレスから行われているかどうかを調べます。

  • 他の Azure サービスへの接続で Private Link またはサービス エンドポイントが有効になっているかどうかを調べます。

  • Azure Storage に接続するときに、仮想マシンがストレージと同じリージョンにあることを確認します。

  • 接続に使われるパブリック IP アドレスが、ネットワーク仮想アプライアンス (NVA) など、Azure 仮想ネットワーク内の別の Azure サービスからのものかどうかを確認します。

NAT ゲートウェイのパブリック IP がアウトバウンド接続に使用されない場合の考えられる解決策

  • パブリック IP アドレスまたはプレフィックスを NAT ゲートウェイにアタッチします。 NAT ゲートウェイが同じ仮想ネットワークのサブネットにアタッチされていることを確認します。 NAT ゲートウェイがアウトバウンドに接続できることを検証します。

  • VM が別のアウトバウンド接続方法からの古い SNAT IP アドレスを保持している問題を、次の方法でテストして解決します。

    • 新しい接続を確立していることと、既存の接続が OS で再利用されていないこと、またはブラウザーが接続をキャッシュしていることを確認します。 たとえば、PowerShell で curl を使用する場合は、新しい接続を強制するために -DisableKeepalive パラメーターを必ず指定します。 ブラウザーを使っている場合は、接続がプールされている可能性もあります。

    • NAT ゲートウェイに構成されたサブネット内の仮想マシンを再起動する必要はありません。 しかし、仮想マシンが再起動されると、接続状態がフラッシュされます。 接続の状態がフラッシュされると、すべての接続が NAT ゲートウェイ リソースの 1 つまたは複数の IP アドレスを使い始めます。 この動作は仮想マシンの再起動の副作用であり、再起動が必要であることを示すインジケーターではありません。

    • 調べてもわからない場合は、サポート ケースを開いてさらに詳細なトラブルシューティングを行います。

  • 0.0.0.0/0 トラフィックを NVA に転送するカスタム ルートは、トラフィックをインターネットにルーティングする NAT ゲートウェイより優先されます。 NAT ゲートウェイにトラフィックを NVA ではなくインターネットにルーティングさせるには、0.0.0.0/0 トラフィックを仮想アプライアンスに送るカスタム ルートを削除します。 0.0.0.0/0 トラフィックはインターネットへの既定のルートの使用を再開し、代わりに NAT ゲートウェイが使われます。

重要

トラフィックのルーティング方法を変更する前に、クラウド アーキテクチャのルーティング要件を慎重に検討してください。

  • Azure ストレージ アカウントと同じリージョンにデプロイされたサービスでは、プライベート Azure IP アドレスが通信に使われます。 特定の Azure サービスへのアクセスを、そのパブリック アウトバウンド IP アドレスの範囲に基づいて制限することはできません。 詳しくは、「IP ネットワーク規則の制限」をご覧ください。
  • Private Link とサービス エンドポイントは、NAT ゲートウェイのパブリック IP ではなく、仮想ネットワーク内の仮想マシン インスタンスのプライベート IP アドレスを使って、Azure Platform サービスに接続します。 インターネットと NAT ゲートウェイを経由するのではなく、Azure バックボーン経由で他の Azure サービスに接続するには、Private Link を使います。

Note

プライベート リンクは、Azure でホストされるサービスへのプライベート アクセスにおいて、サービス エンドポイントよりも推奨されるオプションです。

パブリック インターネット宛先での接続障害

シナリオ

インターネットの接続先への NAT ゲートウェイ接続が失敗するか、タイムアウトします。

考えられる原因

  • 宛先側のファイアウォールやその他のトラフィック管理コンポーネント。

  • 宛先側によって課される API レート制限。

  • Volumetric DDoS の軽減策やトランスポート層のトラフィック シェイプ。

  • 接続先エンドポイントが、断片化されたパケットで応答します。

トラブルシューティングの方法

  • 同じリージョン (または比較のために他のリージョン) のエンドポイントとの接続を確認します。

  • 接続元側と接続先側からパケット キャプチャを実行します。

  • 接続元と接続先のパケット数 (ある場合) を調べて、接続が試みられた回数を確認します。

  • ドロップされたパケットを調べて、NAT ゲートウェイによってドロップされたパケットの数を確認します。

  • パケットを分析します。 断片化された IP プロトコル パケットを含む TCP パケットは、IP の断片化を示します。 NAT ゲートウェイでは IP の断片化はサポートされていないため、断片化されたパケットを含む接続は失敗します。

  • ファイアウォールまたは他のトラフィック管理コンポーネントを使うパートナーの接続先で、NAT ゲートウェイのパブリック IP アドレスが許可リストに登録されていることを確認します。

インターネットの接続先での接続エラーについて考えられる解決策

  • NAT ゲートウェイのパブリック IP アドレスが、接続先で許可リストに登録されていることを確認します。

  • 大容量または高トランザクション速度のテストを実施している場合、速度を落とすことでエラーの頻度が下がるかどうかを調べます。

  • 接続速度を下げるとエラーの発生が減る場合は、接続先が API の速度制限または他の制約に達したかどうかを調べます。

アクティブまたはパッシブ モードの FTP サーバーでの接続エラー

シナリオ

アクティブまたはパッシブの FTP モードで NAT ゲートウェイを使うと、FTP サーバーで接続エラーが発生します。

考えられる原因

  • アクティブ FTP モードが有効になっています。

  • パッシブ FTP モードが有効になっており、NAT ゲートウェイがで複数のパブリック IP アドレスを使っています。

アクティブ FTP モードについて考えられる解決策

FTP では、クライアントとサーバーの間で 2 つの独立したチャネル (コマンド チャネルとデータ チャネル) が使用されます。 各チャネルは別々の TCP 接続で通信します。1 つはコマンドを送信するための接続で、もう 1 つはデータを転送するための接続です。

アクティブ FTP モードでは、クライアントではコマンド チャネルを確立し、サーバーではデータ チャネルを確立します。

NAT ゲートウェイは、アクティブ FTP モードと互換性がありません。 アクティブ FTP では、FTP クライアントから PORT コマンドを使用することで、クライアントに接続する目的でサーバーがデータ チャネルで使用する IP アドレスとポートを FTP サーバーに通知します。 PORT コマンドではクライアントのプライベート IP アドレスを使用しますが、これは変更できません。 クライアント側のトラフィックはインターネット ベースの通信のために NAT ゲートウェイにより SNAT 変換されます。そのため、PORT コマンドは FTP サーバーによって無効と見なされます。

アクティブ FTP モードの代替ソリューションは、代わりにパッシブ FTP モードを使うことです。 ただし、パッシブ FTP モードで NAT ゲートウェイを使用するには、いくつかの事項を考慮する必要があります。

パッシブ FTP モードについて考えられる解決策

パッシブ FTP モードの場合、クライアントでは、コマンド チャネルとデータ チャネルの両方で接続を確立します。 クライアントは、クライアントに戻る接続を確立するのではなく、サーバーがポートで応答するように要求します。

FTP サーバーの構成によっては、複数のパブリック IP アドレスを持つ NAT ゲートウェイでは、アウトバウンド パッシブ FTP は機能しません。 複数のパブリック IP アドレスがある NAT ゲートウェイは、送信トラフィックを送信するときに、ソース IP アドレスとしてパブリック IP アドレスの 1 つをランダムに選択します。 FTP サーバーの構成によっては、データ チャネルとコントロール チャネルで使われている接続元 IP アドレスが異なると、FTP が失敗します。

発生する可能性があるパッシブ FTP 接続エラーを防ぐには、次の手順を行ってください。

  1. NAT ゲートウェイが、複数の IP アドレスまたはプレフィックスではなく、1 つのパブリック IP アドレスに接続されていることを確認します。

  2. NAT ゲートウェイのパッシブ ポート範囲が、接続先エンドポイントでファイアウォールの通過を許可されていることを確認します。

Note

NAT ゲートウェイでパブリック IP アドレスの量を減らすと、送信接続に利用できる SNAT ポート インベントリが減り、SNAT ポートが枯渇するリスクが高まる可能性があります。 NAT ゲートウェイからパブリック IP アドレスを削除する前に、SNAT 接続の必要性を検討してください。 コントロール プレーンとデータ プレーンで異なる接続元 IP アドレスからのトラフィックを受け入れるように、FTP サーバーの設定を変更することはお勧めしません。

ポート 25 のアウトバウンド接続がブロックされる

シナリオ

簡易メール転送プロトコル (SMTP) トラフィックの場合、ポート 25 で NAT ゲートウェイとアウトバウンド接続することはできません。

原因

Azure プラットフォームでは、デプロイされている VM の TCP ポート 25 上のアウトバウンド SMTP 接続がブロックされます。 このブロックは、Microsoft のパートナーと顧客のセキュリティの強化、Microsoft の Azure プラットフォームの保護、業界標準への準拠を確実に行うためです。

Azure VM または Azure App Service からメールを送信するには、認証済みの SMTP リレー サービスを使います。 詳しくは、アウトバウンド SMTP 接続の問題のトラブルシューティングに関する記事をご覧ください。

その他の トラブルシューティングのガイダンス

その他のネットワーク キャプチャ

調査で結論が出ない場合は、さらにトラブルシューティングを行うためにサポート ケースを開き、迅速に解決するために次の情報を収集します。 NAT ゲートウェイが構成されているサブネットで 1 つの仮想マシンを選び、次のテストを行います。

  • 仮想ネットワーク内のいずれかのバックエンド VM から ps ping を使ってプローブ ポートの応答をテストし、結果を記録します (例: ps ping 10.0.0.4:3389)。

  • この ping テストで応答を受信しない場合は、PsPing を実行しながら、バックエンド仮想マシンと仮想ネットワーク テスト仮想マシンで同時 netsh トレースを実行し、その後、netsh トレースを停止します。

送信接続のベスト プラクティス

Azure では、そのインフラストラクチャが慎重に監視され、運用されます。 ただし、それでもデプロイされたアプリケーションから一時的な障害が発生する可能性はあり、無損失の転送は保証されません。 Azure のデプロイから信頼性と回復性の高いアウトバウンド接続を確立するには、NAT ゲートウェイが推奨されるオプションです。 アプリケーションの接続効率の最適化については、後で示すガイダンスを参照してください。

接続プールの使用

接続をプールすると、同じアドレスとポートへの呼び出しに対して、新しいネットワーク接続を開かないようにすることができます。 アプリケーションでは接続プーリング スキームを実装できます。この場合、要求は、固定された接続セットに内部的に分散され、可能な場合に再利用されます。 このようにセットアップすると、使用中の SNAT ポートの数が制限され、環境が予測可能になります。 接続プーリングを使用すると、待機時間とリソース使用率が減り、最終的にはアプリケーションのパフォーマンスを向上できます。

HTTP 接続のプールの詳細については、HttpClientFactory による HTTP 接続のプールに関するページを確認してください。

接続を再利用する

要求ごとに個々のアトミック TCP 接続を生成するのではなく、接続を再利用するようにアプリケーションを構成してください。 接続の再利用により、TCP トランザクションのパフォーマンスが向上します。また、これは、接続の再利用が既定である HTTP/1.1 などのプロトコルに特に適しています。 この再利用は、REST などのトランスポートとして HTTP を使用する他のプロトコルに適用されます。

あまり積極的でない再試行ロジックを使用する

SNAT ポートが不足している場合、またはアプリケーションのエラーが発生している場合は、遅延やバックオフ ロジックを使わず単純に再試行を繰り返すと、ポート不足が発生したり持続したりします。 SNAT ポートの需要は、再試行の頻度を抑えたロジックを使用することで減らすことができます。

構成されているアイドル タイムアウトによっては、再試行が積極的すぎると、接続が再利用のために SNAT ポートを閉じて解放するのに十分な時間がありません。

その他のガイダンスや例については、再試行パターンに関する記事を参照してください。

キープアライブを使用して送信アイドル タイムアウトをリセットする

キープアライブについて詳しくは、「TCP アイドル タイムアウト」をご覧ください。

可能であれば、SNAT ポートへの需要を減らすために、プライベート リンクを使用して、仮想ネットワークから Azure Platform サービスに直接接続する必要があります。 SNAT ポートへの需要を減らすことで、SNAT ポートの枯渇のリスクを軽減することができます。

プライベート リンクを作成するには、次のクイックスタート ガイドを参照して作業を開始してください。

次のステップ

Microsoft は常に、お客様のエクスペリエンスの向上に努めています。 この記事を参照しても対処または解決できない NAT ゲートウェイの問題が発生した場合は、このページの下部にある GitHub からフィードバックを提供してください。

NAT ゲートウェイの詳細については、次の記事を参照してください。