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

この記事では、送信接続できるように NAT ゲートウェイを構成する方法に関するガイダンスを提供します。 この記事では、NAT ゲートウェイに関してよくある構成と接続の問題を解決するための緩和手順についても説明します。

NAT ゲートウェイに関してよくある接続の問題

NAT ゲートウェイに関する構成の問題

NAT ゲートウェイ構成の基本

次の構成を確認して、NAT ゲートウェイを使用してトラフィックを送信できます。

  1. 少なくとも 1 つのパブリック IP アドレスまたは 1 つのパブリック IP プレフィックスが NAT ゲートウェイにアタッチされています。 少なくとも 1 つのパブリック IP アドレスが NAT ゲートウェイに関連付けられていて、送信接続を提供できなければなりません。
  2. 少なくとも 1 つのサブネットが NAT ゲートウェイに接続されています。 継続送信のため複数のサブネットを NAT ゲートウェイに接続できますが、それらのサブネットが同じ仮想ネットワーク内に存在する必要があります。 NAT ゲートウェイがひとつの仮想ネットワークを超えることはできません。
  3. NSG 規則または UDR で、NAT ゲートウェイからインターネットへのトラフィック送信をブロックしていません。

接続を検証する方法

Virtual Network NAT ゲートウェイでは、IPv4 UDP および TCP プロトコルがサポートされています。 ICMP はサポートされておらず、失敗する可能性があります。

NAT ゲートウェイのエンドツーエンド接続を検証するには、次の手順に従います。

  1. NAT ゲートウェイのパブリック IP アドレスが使用されていないことを確認します。
  2. TCP 接続テストと UDP 固有アプリケーション層のテストを行います。
  3. NSG フロー ログを見て、NAT ゲートウェイからの送信トラフィック フローを分析します。

NAT ゲートウェイの接続を検証するために使用するツールについては、次の表を参照してください。

オペレーティング システム 汎用 TCP 接続テスト TCP アプリケーション レイヤー テスト UDP
Linux nc (汎用接続テスト) curl (TCP アプリケーション レイヤー テスト) アプリケーション固有
Windows PsPing PowerShell Invoke-WebRequest アプリケーション固有

NAT ゲートウェイからの送信トラフィックを分析するには、NSG フロー ログを使用します。

NAT ゲートウェイを使用したサブネットと仮想ネットワークに関する構成の問題

Basic SKU リソースが NAT ゲートウェイと同じサブネットに存在することはできません

NAT ゲートウェイに基本的ロード バランサーや基本パブリック IP などの基本的リソースとの互換性はありません。 基本的リソースは、NAT ゲートウェイに関連付けられていないサブネットに置く必要があります。 基本的ロード バランサーと基本パブリック IP を Standard にアップグレードして、NAT ゲートウェイで使用することができます。

NAT ゲートウェイをゲートウェイ サブネットに接続することはできません

NAT ゲートウェイをゲートウェイ サブネットに デプロイすることはできません。 VPN ゲートウェイは、サイト間 Azure 仮想ネットワークとローカル ネットワーク間、または 2 つの Azure 仮想ネットワーク間の VPN 接続にゲートウェイ サブネットを使用します。 VPN ゲートウェイの概要に関するページで、ゲートウェイ サブネットを使用する方法の詳細をご覧ください。

IPv6 の共存

Virtual Network NAT ゲートウェイでは、IPv4 UDP および TCP プロトコルがサポートされています。 NAT ゲートウェイを、IPv6 パブリック IP アドレスまたは IPv6 パブリック IP プレフィックスに関連付けることはできません。 NAT ゲートウェイはデュアル スタック サブネットにデプロイできますが、送信トラフィックの送信には IPv4 パブリック IP アドレスのみを使用します。 IPv6 リソースが IPv4 リソースと同じサブネットに存在する必要がある場合は、NAT ゲートウェイをデュアル スタック サブネットにデプロイします。

NAT ゲートウェイの構成が原因の SNAT の枯渇

NAT ゲートウェイに関してよくある SNAT 枯渇の問題は、一般には NAT ゲートウェイでの構成と関係しています。 SNAT の枯渇に関してよくある問題は次のとおりです。

  • NAT ゲートウェイの送信接続が十分にスケールアウトされていない。
  • NAT ゲートウェイの構成可能な TCP アイドル タイムアウト タイマーが、既定値の 4 分よりも大きい値に設定されている。

送信接続が十分にスケールアウトされていない

各パブリック IP アドレスでは、NAT ゲートウェイに接続されているサブネットに 64,512 個の SNAT ポートが提供されます。 NAT ゲートウェイでは、それらの使用可能な SNAT ポートから同じ宛先エンドポイントへの最大 50,000 個のコンカレント接続をサポートできます。 送信接続が低下している理由が SNAT ポートが消耗しているためである場合は、NAT ゲートウェイがワークロードを処理できるほど十分にスケールアウトされない可能性があります。 さらなる SNAT ポートを送信接続に提供できるようにするために、NAT ゲートウェイへのパブリック IP アドレスの追加が必要になる場合があります。

次の表では、送信接続が十分にスケールアウトされていない可能性がある 2 つのよくあるシナリオと、これらの問題を検証して軽減する方法について説明しています。

シナリオ 証拠 対応策
使用率が高い期間に SNAT ポートの競合と SNAT ポートの枯渇が発生している。 次のメトリックを Azure Monitor で実行します: 合計 SNAT 接続数: "Sum" 集計は、接続ボリュームが大きいことを示します。 "失敗" 接続状態は、一時的な障害や永続的な障害が起きていることを示します。 破棄されたパケット: "Sum" 集計は、パケット破棄が高い接続ボリュームと一致していることを示します。 パブリック IP アドレスまたはパブリック IP プレフィックスをさらに追加できるかどうかを判断します。 この追加により、NAT ゲートウェイに対して合計で最大 16 個の IP アドレスを使用できるようになります。 この追加により、使用可能な SNAT ポートのインベントリが増え (IP アドレスあたり 64,000 個)、シナリオをさらにスケーリングできるようになります。
既に 16 個の IP アドレスを取得したが、SNAT ポートの枯渇が引き続き発生する。 さらに IP アドレスを追加しようとすると失敗します。 パブリック IP アドレス リソースまたはパブリック IP プレフィックス リソースからの IP アドレスの総数が合計 16 個を超えている。 アプリケーション環境を複数のサブネットに分散し、各サブネットに NAT ゲートウェイ リソースを提供します。

Note

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

TCP アイドル タイムアウト タイマーが既定値より大きい値に設定されている

NAT ゲートウェイの TCP アイドル タイムアウト タイマーは既定で 4 分に設定されますが、これは構成可能であり、120 分まで延長できます。 この設定を既定より大きい値に変更した場合、NAT ゲートウェイでフローを保持する時間が長くなり、SNAT ポート インベントリに対して追加の負荷が発生する可能性があります。 次の表は、長い TCP アイドル タイムアウトが原因で SNAT の枯渇が発生している可能性がある一般的なシナリオと、考えられる軽減手順を示しています。

シナリオ 証拠 対応策
TCP 接続がアイドル タイムアウトにならずに長時間アクティブになるように、TCP アイドル タイムアウト タイマーの設定を増やします。 しばらくすると、接続エラーがより多く発生することがわかります。 接続で SNAT ポートのインベントリがより長い時間保持されるため、それらが枯渇していることが疑われます。 SNAT ポートの枯渇が発生しているかどうかを判断するには、Azure Monitor で次の NAT ゲートウェイ メトリックを確認します。合計 SNAT 接続: "Sum" 集計は、高い接続ボリュームを示します。 "失敗" 接続状態は、一時的な障害や永続的な障害が起きていることを示します。 破棄されたパケット: "Sum" 集計は、パケット破棄が高い接続ボリュームと一致していることを示します。 SNAT ポートの枯渇を解決するために実行できる軽減手順がいくつかあります。- TCP アイドル タイムアウトを小さい値に減らして、SNAT ポートのインベントリをより早く解放します。 TCP アイドルタイムアウトタイマーを4分より短く設定することはできません。 - 非同期ポーリング パターンを使用して、他の操作のために接続リソースを解放することを検討します。 - 中間システムのタイムアウトを回避するために、TCP キープアライブまたはアプリケーション レイヤーのキープアライブを使用します。例については、.NET の例に関する記事を参照してください。 - Azure PaaS サービスに接続される場合は、プライベート リンクを使用します。 プライベート リンクを使用すると、NAT ゲートウェイのパブリック IP を使用する必要がなくなり、インターネットへの送信接続用の SNAT ポートがさらに解放されます。

アイドル タイムアウトによる接続エラー

TCP アイドル タイムアウト

上の TCP タイマーのセクションで説明したように、TCP キープアライブを代わりに使用し、アイドル フローを更新してアイドル タイムアウトをリセットする必要があります。 TCP キープアライブは、片側の接続から有効にするだけで、両側からの接続が維持されます。 片側の接続から TCP キープアライブが送信されると、もう一方の側によって ACK パケットが自動的に送信されます。 その後、アイドル タイムアウト タイマーが、接続の両側でリセットされます。 詳細については、タイマーの考慮事項に関する記事を参照してください。

注意

TCP アイドル タイムアウトを増やすことは最後の手段であり、根本原因が解決されるとは限りません。 タイムアウトが長いと、タイムアウトの終了時、低い率でエラーが発生し、遅延や不要な障害を引き起こす可能性があります。

UDP アイドル タイムアウト

UDP アイドル タイムアウト タイマーは 4 分に設定されます。 NAT ゲートウェイの TCP アイドル タイムアウト タイマーとは異なり、UDP アイドル タイムアウト タイマーは構成できません。 次の表は、UDP トラフィックのアイドル タイムアウトによる接続の切断が発生する一般的なシナリオと、この問題を軽減するための手順を示しています。

シナリオ 証拠 対応策
UDP トラフィックで、長時間保持する必要がある接続が切断されていることに気づきました。 Azure Monitor で次の NAT ゲートウェイ メトリック を確認します。破棄されたパケット: "Sum" 集計では、パケット破棄が高い接続ボリュームと一致していることが示されます。 実行可能な軽減手順がいくつかあります。- UDP キープアライブを有効にします。 UDP キープアライブを有効にした場合、接続の一方向に対してのみアクティブになることに注意してください。 これは、接続がもう一方の側でアイドル状態になってタイムアウトする可能性がまだあることを意味します。 UDP 接続がアイドル状態になってタイムアウトすることを回避するには、UDP キープアライブを接続フローの両方向に対して有効にする必要があります。 - アプリケーション レイヤーのキープアライブを使用して、アイドル フローを更新し、アイドル タイムアウトをリセットすることもできます。 サーバー側で、アプリケーション固有のキープアライブのどのようなオプションが存在するかを確認します。

NAT ゲートウェイと統合サービスに関する接続の問題

Azure App Service のリージョン仮想ネットワーク統合がオフになっている

NAT ゲートウェイを Azure App Service と共に使用して、アプリケーションが仮想ネットワークから送信呼び出しを行なえるようにすることができます。 この Azure App Services と NAT ゲートウェイの間の統合を使用するには、リージョン仮想ネットワーク統合を有効にする必要があります。 リージョン仮想ネットワーク統合の仕組みで詳細をご覧ください。

NAT ゲートウェイを Azure App Services で使用するには、次の手順に従います。

  1. アプリケーションに仮想ネットワーク統合が構成されていることを確認します。仮想ネットワーク統合の有効化に関するするページを参照してください。
  2. 仮想ネットワーク統合に対して [Route All](すべてルーティング) が有効であることを確認します。仮想ネットワーク統合のルーティングの構成に関するページを参照してください。
  3. NAT ゲートウェイ リソースを作成します。
  4. 新しいパブリック IP アドレスを作成するか、ネットワーク内の既存のパブリック IP アドレスを NAT ゲートウェイにアタッチします。
  5. 仮想ネットワークとアプリケーションの統合に使われているのと同じサブネットに NAT ゲートウェイを割り当てます。

仮想ネットワーク統合で NAT ゲートウェイを構成する方法の詳細な手順については、NAT ゲートウェイ統合の構成に関するページを参照してください。

NAT ゲートウェイと Azure App Services の統合に関する重要な注意事項を次に示します。

  • 仮想ネットワーク統合では、仮想ネットワークからアプリへの受信プライベート アクセスが提供されません。
  • 仮想ネットワーク統合の動作方法の性質のために、仮想ネットワーク統合からのトラフィックは Azure Network Watcher や NSG フロー ログには表示されません。

ポート 25 を NAT ゲートウェイとのリージョン VNet 統合に使用できません

ポート 25 は、電子メールを送信するために使用される SMTP ポートです。 Azure App Services のリージョン仮想ネットワーク統合では、設計上ポート 25 を使用できません。 アプリケーションを電子メール SMTP サーバーに接続するための NAT ゲートウェイでリージョン仮想ネットワーク統合が有効になっているシナリオで、トラフィックがポート 25 でブロックされるのですが、NAT ゲートウェイが送信トラフィックで他のすべてのポートと連携しています。 このポート 25 のブロックは削除できません。

回避策ソリューション:

  • ポート 25 にトラフィックをルーティングする Windows VM へのポート転送を設定します。

NAT ゲートウェイのパブリック IP が送信トラフィックに使用されていない

NAT ゲートウェイを VNet に追加した後で、VM がアクティブな接続を持つ以前の SNAT IP を保持します

Virtual Network NAT ゲートウェイが、サブネットで送信接続に取って代わります。 既定の SNAT またはロード バランサーの送信 SNAT から NAT ゲートウェイを使用するように切り替えると、新しい接続から NAT ゲートウェイ リソースに関連付けられた IP アドレスの使用が直ちに開始されます。 しかし、NAT ゲートウェイへの切り替え中に、仮想マシンの接続が引き続き確立されている場合、接続の確立時に割り当てられた古い SNAT IP アドレスを使用して接続が続行されます。

VM が古い SNAT IP アドレスを持ち続ける問題を、次の方法でテストして解決します。

  1. 実際に新しい接続を確立していることと、接続を再使用していないのは既に OS に存在していたため、あるいはブラウザーが接続を接続プールにキャッシュしていたためであることを確認します。 たとえば、PowerShell で curl を使用する場合は、新しい接続を強制するために -DisableKeepalive パラメーターを必ず指定します。 ブラウザーを使用している場合は、接続をプールすることもできます。
  2. NAT ゲートウェイに構成されたサブネット内の仮想マシンを再起動する必要はありません。 しかし、仮想マシンが再起動されると、接続状態がフラッシュされます。 接続状態がフラッシュされると、すべての接続で NAT ゲートウェイ リソースの IP アドレスの使用が開始されます。 しかし、これは再起動される仮想マシンの副作用であり、再起動が必要なインジケーターではありません。

それでも問題が解決しない場合は、さらにトラブルシューティングを行うためにサポート ケースを開いてください。

仮想アプライアンスの UDR と VPN の ExpressRoute によって、送信トラフィックをルーティングするための NAT ゲートウェイがオーバーライドされる

カスタム UDR を使用した強制トンネリングを有効にして、ExpressRoute 経由で仮想アプライアンスまたは VPN にトラフィックを送信する場合、インターネットに送信されるトラフィックの転送では UDR または ExpressRoute が NAT ゲートウェイよりも優先されます。 詳細については、カスタム UDR に関する記事を参照してください。

インターネット ルーティング構成の優先順位は、次のようになります。

仮想アプライアンスの UDR/VPN ExpressRoute >> NAT ゲートウェイ >> 既定のシステム

仮想アプライアンスの UDR または VPN ExpressRoute によって NAT ゲートウェイがオーバーライドされる問題をテストして解決するには、次の手順を実行します。

  1. NAT ゲートウェイのパブリック IP が送信トラフィックに使用されているかテストします。 別の IP が使用されている場合は、カスタム UDR が原因である可能性があります。カスタム UDR を調べて削除する方法に関する残りの手順に従ってください。
  2. 仮想ネットワークのルート テーブルで UDR を調べます。ルート テーブルの表示に関するページをご覧ください。
  3. Azure ルート テーブルを作成、変更、削除するに従って、UDR をルート テーブルから削除します。

カスタム UDR をルーティング テーブルから削除すると、送信トラフィックをインターネットにルーティングする場合に NAT ゲートウェイのパブリック IP が優先されるようになるはずです。

プライベート リンクでは、インターネット経由ではなく Azure のバックボーン ネットワーク経由で、Storage、SQL、Cosmos DB などの Azure PaaS サービスに Azure 仮想ネットワークがプライベートに接続されます。 プライベート リンクでは、NAT ゲートウェイのパブリック IP ではなく、仮想ネットワーク内の仮想マシン インスタンスのプライベート IP アドレスを使用して、これらの Azure Platform サービスに接続します。 そのため、これらの Azure サービスへの接続に使用されているソース IP アドレスを調べると、インスタンスのプライベート IP が使用されていることがわかります。 プライベート リンクでサポートされるすべてのサービスについては、こちらに一覧されている Azure サービスを参照してください。

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

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

プライベート リンクを使用して設定したプライベート エンドポイントを確認するには、次のようにします。

  1. Azure portal の検索ボックスで、「プライベート リンク」を検索します。
  2. プライベート リンク センターで、[プライベート エンドポイント] または [プライベート リンク サービス] を選択して、設定されている構成を確認します。 詳細については、プライベート エンドポイント接続の管理に関する記事を参照してください。

サービス エンドポイントを使用して、仮想ネットワークを Azure PaaS サービスに接続することもできます。 仮想ネットワーク用に構成されたサービス エンドポイントがあるかどうかを確認するには、次のようにします。

  1. Azure portal で、ご使用の仮想ネットワークに移動し、[設定] で [サービス エンドポイント] を選択します。
  2. 作成されたすべてのサービス エンドポイントが、それらが構成されているサブネットと共に一覧表示されます。 詳細については、サービス エンドポイントのログ記録とトラブルシューティングに関する記事を参照してください。

注意

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

Azure インフラストラクチャにおける接続障害

Azure では、そのインフラストラクチャが慎重に監視され、運用されます。 ただし、一時的な障害が発生する可能性があります。転送が無損失であるという保証はありません。 TCP アプリケーションには、SYN 再送を見込んだ設計パターンを使用してください。 SYN パケットの損失によって生じる一時的な影響を軽減するために、接続タイムアウトには、TCP SYN 再送ができるだけの十分な長さを確保します。

何を調べるか:

  • SNAT の枯渇が生じていないかチェックします。
  • SYN 再送の動作を制御する TCP スタックの構成パラメーターは、RTO (Retransmission Time-Out: 再送タイムアウト) と呼ばれます。 RTO の値は調整できますが、通常は 1 秒以上で、指数バックオフが既定で使用されます。 アプリケーションの接続タイムアウトが短すぎると (1 秒など)、接続タイムアウトが散発的に発生する可能性があります。 アプリケーションの接続タイムアウトを長くしてください。
  • 既定のアプリケーションの動作でタイムアウトが予想以上に長いと感じられる場合は、サポート ケースを開いて詳細なトラブルシューティングを行ってください。

人為的に TCP 接続タイムアウトを短縮したり、RTO パラメーターをチューニングしたりすることはお勧めしません。

Azure インフラストラクチャの外部における接続障害

パブリック インターネット トランジットに関する接続障害

宛先までのパスが長くなって中間システムが増えるほど、一時的な障害が発生する確率は高くなります。 Azure インフラストラクチャと比べ、一時的な障害の頻度は高くなることが予想されます。

前出の「Azure インフラストラクチャ」セクションと同じガイダンスに従ってください。

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

通信の確立に用いられるインターネット エンドポイントと共に、前のセクションが当てはまります。 その他、以下の要因も、接続の成功に影響を及ぼす可能性があります。

  • 宛先側でのトラフィック管理 (以下を含む)。
  • 宛先側によって課される API レート制限。
  • Volumetric DDoS の軽減策やトランスポート層のトラフィック シェイプ。
  • ファイアウォールなど、宛先側のコンポーネント。

Azure Monitor で NAT ゲートウェイ メトリックを使用して、接続の問題を診断します。

  • 送信元と宛先のパケット数 (ある場合) を見て、接続試行の数を確認します。
  • 破棄されたパケットを見て、NAT ゲートウェイによって破棄されたパケットがいくつあるか調べます。

他に調べること:

  • SNAT の枯渇が生じていないかチェックします。
  • 同じリージョン (または比較のために他のリージョン) のエンドポイントとの接続を確認します。
  • 大容量または高トランザクション速度のテストを実施している場合、速度を落とすことでエラーの頻度が下がるかどうかを調べます。
  • 速度を変えることでエラーの割合に変化が生じる場合は、API 速度制限など、宛先側の制約が上限に達しているかどうかを確認します。

調査しても結論が出ない場合は、サポート ケースを開いて詳細なトラブルシューティングを行ってください。

次の手順

Microsoft では、常にお客様のエクスペリエンスを改善することを目指しています。 この記事に記載されていない、または解決されていない NAT ゲートウェイの問題が発生している場合は、このページの下部から GitHub にアクセスしてフィードバックをお送りください。お客様からのフィードバックにはできるだけ早く対処します。

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