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

この記事は、管理者が Virtual Network NAT を使用する際の接続の問題を診断および解決する場合に役立ちます。This article helps administrators diagnose and resolve connectivity problems when using Virtual Network NAT.

問題が発生した場合Problems

これらの問題を解決するには、次のセクションの手順に従ってください。To resolve these problems, follow the steps in the following section.

解像度Resolution

SNAT の枯渇SNAT exhaustion

1 つの NAT ゲートウェイ リソースで、64,000 から最大 100 万件の同時フローがサポートされます。A single NAT gateway resource supports from 64,000 up to 1 million concurrent flows. 各 IP アドレスでは、64,000 個の SNAT ポートが使用可能なインベントリに提供されます。Each IP address provides 64,000 SNAT ports to the available inventory. NAT ゲートウェイ リソースあたり最大 16 個の IP アドレスを使用できます。You can use up to 16 IP addresses per NAT gateway resource. SNAT のメカニズムについては、こちらで詳しく説明されています。The SNAT mechanism is described here in more detail.

多くの場合、SNAT が枯渇する根本的な原因は、アウトバウンド接続の確立方法と管理方法、または構成可能なタイマーの既定値に対する変更のアンチパターンです。Frequently the root cause of SNAT exhaustion is an anti-pattern for how outbound connectivity is established, managed, or configurable timers changed from their default values. このセクションの内容を慎重に検討してください。Review this section carefully.

手順Steps

  1. 既定のアイドル タイムアウトを 4 分より大きい値に変更したかどうかを確認します。Check if you have modified the default idle timeout to a value higher than 4 minutes.
  2. 対象のアプリケーションで送信接続をどのように作成しているかを調査します (たとえば、コード レビューやパケット キャプチャ)。Investigate how your application is creating outbound connectivity (for example, code review or packet capture).
  3. このアクティビティが予期される動作であるかどうか、またはアプリケーションが誤動作しているかどうかを判断します。Determine if this activity is expected behavior or whether the application is misbehaving. Azure Monitor でメトリックを使用して、調査結果を実証します。Use metrics in Azure Monitor to substantiate your findings. SNAT 接続メトリックの "失敗" カテゴリを使用してください。Use "Failed" category for SNAT Connections metric.
  4. 適切なパターンに従っているかどうかを評価します。Evaluate if appropriate patterns are followed.
  5. NAT ゲートウェイ リソースに割り当てられた追加の IP アドレスを使用して SNAT ポートの枯渇を軽減する必要があるかどうかを評価します。Evaluate if SNAT port exhaustion should be mitigated with additional IP addresses assigned to NAT gateway resource.

設計パターンDesign patterns

可能な場合は常に、接続の再利用と接続プールを利用してください。Always take advantage of connection reuse and connection pooling whenever possible. これらのパターンは、リソース枯渇の問題を回避し、予測可能な動作をもたらします。These patterns will avoid resource exhaustion problems and result in predictable behavior. これらのパターンのプリミティブは、多くの開発ライブラリとフレームワークに含まれています。Primitives for these patterns can be found in many development libraries and frameworks.

解決方法: 適切なパターンとベスト プラクティスを使用するSolution: Use appropriate patterns and best practices

  • NAT ゲートウェイのリソースの既定の TCP アイドルタイムアウトは 4 分です。NAT gateway resources have a default TCP idle timeout of 4 minutes. それよりも大きい値に変更した場合、NAT がフローを保持する時間が長くなり、SNAT ポート インベントリに対して不要な負荷が発生する可能性があります。If this setting is changed to a higher value, NAT will hold on to flows longer and can cause unnecessary pressure on SNAT port inventory.
  • アトミック要求 (接続ごとに 1 要求) は設計の選択肢として貧弱です。Atomic requests (one request per connection) are a poor design choice. そのようなアンチパターンにより規模が制限され、パフォーマンスと信頼性が低下されます。Such anti-pattern limits scale, reduces performance, and decreases reliability. 代わりに、HTTP/S 接続を再利用し、接続と関連付けられている SNAT ポートの数を減らします。Instead, reuse HTTP/S connections to reduce the numbers of connections and associated SNAT ports. TLS を利用すると、ハンドシェイク、オーバーヘッド、暗号化操作による代償が減り、アプリケーションのスケールとパフォーマンスが向上します。The application scale will increase and performance improve due to reduced handshakes, overhead, and cryptographic operation cost when using TLS.
  • DNS リゾルバーの結果がクライアントでキャッシュされないとき、DNS では個別フローを大量に導入できます。DNS can introduce many individual flows at volume when the client is not caching the DNS resolvers result. キャッシュを使用するUse caching.
  • UDP フロー (DNS 参照など) によって、アイドル時間中、SNAT ポートが割り当てられます。UDP flows (for example DNS lookups) allocate SNAT ports for the duration of the idle timeout. アイドル時間が長くなると、SNAT ポートにかかる圧力がそれだけ高くなります。The longer the idle timeout, the higher the pressure on SNAT ports. 短いアイドル タイムアウト (4 分など) を使用します。Use short idle timeout (for example 4 minutes).
  • 接続プールを使用し、接続ボリュームを形成します。Use connection pools to shape your connection volume.
  • 警告なしで TCP フローを破棄し、TCP タイマーに依存してフローを消去することは決してしないでください。Never silently abandon a TCP flow and rely on TCP timers to clean up flow. TCP で明示的に接続を閉じなかった場合、中間システムとエンドポイントで状態が割り当てられたままになり、他の接続に SNAT ポートを利用できなくなります。If you don't let TCP explicitly close the connection, state remains allocated at intermediate systems and endpoints and makes SNAT ports unavailable for other connections. このパターンによって、アプリケーション エラーと SNAT 枯渇がトリガーされる可能性があります。This pattern can trigger application failures and SNAT exhaustion.
  • OS レベルの TCP 終了関連のタイマー値は、影響が専門的にわからない場合、変更しないでください。Don't change OS-level TCP close related timer values without expert knowledge of impact. TCP スタックの復旧中、接続のエンドポイントで期待値が一致しないと、アプリケーション パフォーマンスに悪影響が出ることがあります。While the TCP stack will recover, your application performance can be negatively impacted when the endpoints of a connection have mismatched expectations. タイマーの変更が望まれるということは、通常、基礎的な設計に問題がある兆候です。The desire to change timers is usually a sign of an underlying design problem. 次の推奨事項をご確認ください。Review following recommendations.

SNAT 枯渇は、基礎となるアプリケーションのその他のアンチパターンによって増幅することもあります。SNAT exhaustion can also be amplified with other anti-patterns in the underlying application. ご自分のサービスの規模や信頼性を改善するため、こうした追加のパターンやベスト プラクティスをご確認ください。Review these additional patterns and best practices to improve the scale and reliability of your service.

  • SNAT ポート インベントリをもっと早く解放するために、TCP アイドル タイムアウトを、より小さい値 (既定のアイドル タイムアウトである 4 分など) に変更した場合の効果を詳しく調べます。Explore impact of reducing TCP idle timeout to lower values including default idle timeout of 4 minutes to free up SNAT port inventory earlier.
  • 実行時間の長い操作に対しては、非同期ポーリング パターンを使用して他の操作のために接続リソースを解放することを検討します。Consider asynchronous polling patterns for long-running operations to free up connection resources for other operations.
  • 有効期間の長いフロー (たとえば、再利用された TCP 接続) では、中間システムのタイムアウトを回避するために、TCP キープアライブまたはアプリケーション レイヤー キープアライブを使用する必要があります。アイドル タイムアウトを増やすことは最後の手段であり、根本原因が解決されるとは限りません。Long-lived flows (for example reused TCP connections) should use TCP keepalives or application layer keepalives to avoid intermediate systems timing out. Increasing the idle timeout is a last resort and may not resolve the root cause. タイムアウトが長いと、タイムアウトの終了時、低い率でエラーが発生し、遅延や不要な障害を引き起こす可能性があります。A long timeout can cause low rate failures when timeout expires and introduce delay and unnecessary failures.
  • 一時的な障害または障害復旧中の積極的な再試行またはバーストを回避するには、グレースフルな再試行パターンを使用する必要があります。Graceful retry patterns should be used to avoid aggressive retries/bursts during transient failure or failure recovery. すべての HTTP 操作に対して新しい TCP 接続を作成することはアンチパターンです ("アトミック接続" とも呼ばれます)。Creating a new TCP connection for every HTTP operation (also known as "atomic connections") is an anti-pattern. アトミック接続は、アプリケーションのスケーリングを妨げ、リソースを浪費します。Atomic connections will prevent your application from scaling well and waste resources. 常に複数の操作をパイプラインで同じ接続に渡してください。Always pipeline multiple operations into the same connection. アプリケーションにとっては、トランザクション速度とリソース コストの面でメリットがあります。Your application will benefit in transaction speed and resource costs. アプリケーションでトランスポート レイヤー暗号化 (TLS など) を使用する場合、新しい接続の処理に関連する多大なコストがかかります。When your application uses transport layer encryption (for example TLS), there's a significant cost associated with the processing of new connections. その他のベスト プラクティス パターンについては、Azure のクラウド設計パターンに関するページを確認してください。Review Azure Cloud Design Patterns for additional best practice patterns.

可能な追加の軽減策Additional possible mitigations

解決方法: アウトバウンド接続を次のようにスケーリングします。Solution: Scale outbound connectivity as follows:

シナリオScenario 証拠Evidence 対応策Mitigation
使用率が高い期間に SNAT ポートの競合と SNAT ポートの枯渇が発生している。You're experiencing contention for SNAT ports and SNAT port exhaustion during periods of high usage. Azure Monitor の SNAT 接続メトリックの "失敗" カテゴリに、一定期間にわたる一時的または永続的な失敗や、大量の接続が表示される。"Failed" category for SNAT Connections metric in Azure Monitor shows transient or persistent failures over time and high connection volume. パブリック IP アドレス リソースまたはパブリック IP プレフィックス リソースをさらに追加できるかどうかを判断します。Determine if you can add additional public IP address resources or public IP prefix resources. この追加により、NAT ゲートウェイに対して合計で最大 16 個の IP アドレスを使用できるようになります。This addition will allow for up to 16 IP addresses in total to your NAT gateway. この追加により、使用可能な SNAT ポートのインベントリが増え (IP アドレスあたり 64,000 個)、シナリオをさらにスケーリングできるようになります。This addition will provide more inventory for available SNAT ports (64,000 per IP address) and allow you to scale your scenario further.
既に 16 個の IP アドレスを取得したが、SNAT ポートの枯渇が引き続き発生する。You've already given 16 IP addresses and still are experiencing SNAT port exhaustion. 新たに IP アドレスを追加しようとすると失敗する。Attempt to add additional IP address fails. パブリック IP アドレス リソースまたはパブリック IP プレフィックス リソースからの IP アドレスの総数が合計 16 個を超えている。Total number of IP addresses from public IP address resources or public IP prefix resources exceeds a total of 16. アプリケーション環境を複数のサブネットに分散し、各サブネットに NAT ゲートウェイ リソースを提供します。Distribute your application environment across multiple subnets and provide a NAT gateway resource for each subnet. 設計パターンを再評価し、前述のガイダンスに基づいて最適化します。Reevaluate your design pattern(s) to optimize based on preceding guidance.

注意

SNAT の枯渇が発生する理由を理解することが重要です。It is important to understand why SNAT exhaustion occurs. スケーラブルで信頼性の高いシナリオに適したパターンを使用していることを確認してください。Make sure you are using the right patterns for scalable and reliable scenarios. 需要の原因を理解できないままさらに多くの SNAT ポートをシナリオに追加することは最後の手段にする必要があります。Adding more SNAT ports to a scenario without understanding the cause of the demand should be a last resort. 現在のシナリオで SNAT ポート インベントリに負荷がかかっている理由を理解できない場合、IP アドレスを追加することで SNAT ポートをインベントリに追加しても、アプリケーションをスケーリングしたときに同じ枯渇の障害が発生するのを遅らせるだけです。If you do not understand why your scenario is applying pressure on SNAT port inventory, adding more SNAT ports to the inventory by adding more IP addresses will only delay the same exhaustion failure as your application scales. 他の非効率性やアンチパターンを隠すことになります。You may be masking other inefficiencies and anti-patterns.

ICMP ping が失敗するICMP ping is failing

Virtual Network NAT では、IPv4 UDP および TCP プロトコルがサポートされています。Virtual Network NAT supports IPv4 UDP and TCP protocols. ICMP はサポートされておらず、失敗することが予想されます。ICMP isn't supported and expected to fail.

解決方法: 代わりに、TCP 接続テスト ("TCP ping" など) と UDP 固有のアプリケーション レイヤー テストを使用して、エンド ツー エンドの接続を検証します。Solution: Instead, use TCP connection tests (for example "TCP ping") and UDP-specific application layer tests to validate end to end connectivity.

次の表は、テストを開始するために使用するツールの出発点として使用できます。The following table can be used a starting point for which tools to use to start tests.

オペレーティング システムOperating system 汎用 TCP 接続テストGeneric TCP connection test TCP アプリケーション レイヤー テストTCP application layer test UDPUDP
LinuxLinux nc (汎用接続テスト)nc (generic connection test) curl (TCP アプリケーション レイヤー テスト)curl (TCP application layer test) アプリケーション固有application specific
WindowsWindows PsPingPsPing PowerShell Invoke-WebRequestPowerShell Invoke-WebRequest アプリケーション固有application specific

接続エラーConnectivity failures

Virtual Network NAT に関する接続の問題は、いくつかの異なる問題が原因で発生します。Connectivity issues with Virtual Network NAT can be caused by several different issues:

  • 構成の誤りによる永続的なエラー。permanent failures due to configuration mistakes.
  • NAT ゲートウェイの一時的または永続的な SNAT の枯渇transient or persistent SNAT exhaustion of the NAT gateway,
  • Azure インフラストラクチャにおける一時的な障害。transient failures in the Azure infrastructure,
  • Azure とパブリック インターネットの宛先との間のパスに生じた一時的な障害。transient failures in the path between Azure and the public Internet destination,
  • パブリック インターネットの宛先における一時的または永続的な障害。transient or persistent failures at the public Internet destination.

接続の検証には、次のようなツールを使用します。Use tools like the following to validation connectivity. ICMP はサポートされていませんICMP ping isn't supported.

オペレーティング システムOperating system 汎用 TCP 接続テストGeneric TCP connection test TCP アプリケーション レイヤー テストTCP application layer test UDPUDP
LinuxLinux nc (汎用接続テスト)nc (generic connection test) curl (TCP アプリケーション レイヤー テスト)curl (TCP application layer test) アプリケーション固有application specific
WindowsWindows PsPingPsPing PowerShell Invoke-WebRequestPowerShell Invoke-WebRequest アプリケーション固有application specific

構成Configuration

構成を確認します。Check your configuration:

  1. NAT ゲートウェイ リソースに少なくとも 1 つのパブリック IP リソースまたは 1 つのパブリック IP プレフィックス リソースがありますか?Does the NAT gateway resource have at least one public IP resource or one public IP prefix resource? アウトバウンド接続を提供できるようにするには、NAT ゲートウェイに少なくとも 1 つの IP アドレスが関連付けられている必要があります。You must at least have one IP address associated with the NAT gateway for it to be able to provide outbound connectivity.
  2. 仮想ネットワークのサブネットは NAT ゲートウェイを使用するように構成されていますか。Is the virtual network's subnet configured to use the NAT gateway?
  3. UDR (ユーザー定義ルート) を使用していて、宛先をオーバーライドしていますか。Are you using UDR (user-defined route) and are you overriding the destination? NAT ゲートウェイ リソースは、構成されたサブネット上の既定のルート (0/0) になります。NAT gateway resources become the default route (0/0) on configured subnets.

SNAT の枯渇SNAT exhaustion

この記事の「SNAT の枯渇」セクションを参照してください。Review section on SNAT exhaustion in this article.

Azure インフラストラクチャAzure infrastructure

Azure では、そのインフラストラクチャが慎重に監視され、運用されます。Azure monitors and operates its infrastructure with great care. 一時的な障害が発生する可能性があります。転送が無損失であるという保証はありません。Transient failures can occur, there's no guarantee that transmissions are lossless. TCP アプリケーションには、SYN 再送を見込んだ設計パターンを使用してください。Use design patterns that allow for SYN retransmissions for TCP applications. SYN パケットの損失によって生じる一時的な影響を軽減するために、接続タイムアウトには、TCP SYN 再送ができるだけの十分な長さを確保します。Use connection timeouts large enough to permit TCP SYN retransmission to reduce transient impacts caused by a lost SYN packet.

解決方法:Solution:

  • SNAT の枯渇が生じていないかチェックします。Check for SNAT exhaustion.
  • SYN 再送の動作を制御する TCP スタックの構成パラメーターは、RTO (Retransmission Time-Out: 再送タイムアウト) と呼ばれます。The configuration parameter in a TCP stack that controls the SYN retransmission behavior is called RTO (Retransmission Time-Out). RTO の値は調整できますが、通常は 1 秒以上で、指数バックオフが既定で使用されます。The RTO value is adjustable but typically 1 second or higher by default with exponential back-off. アプリケーションの接続タイムアウトが短すぎると (1 秒など)、接続タイムアウトが散発的に発生する可能性があります。If your application's connection time-out is too short (for example 1 second), you may see sporadic connection timeouts. アプリケーションの接続タイムアウトを長くしてください。Increase the application connection time-out.
  • 既定のアプリケーションの動作でタイムアウトが予想以上に長いと感じられる場合は、サポート ケースを開いて詳細なトラブルシューティングを行ってください。If you observe longer, unexpected timeouts with default application behaviors, open a support case for further troubleshooting.

人為的に TCP 接続タイムアウトを短縮したり、RTO パラメーターをチューニングしたりすることはお勧めしません。We don't recommend artificially reducing the TCP connection timeout or tuning the RTO parameter.

パブリック インターネット トランジットPublic Internet transit

宛先までのパスが長くなって中間システムが増えるほど、一時的な障害が発生する確率は高くなります。The chances of transient failures increases with a longer path to the destination and more intermediate systems. Azure インフラストラクチャと比べ、一時的な障害の頻度は高くなることが予想されます。It's expected that transient failures can increase in frequency over Azure infrastructure.

前出の「Azure インフラストラクチャ」セクションと同じガイダンスに従ってください。Follow the same guidance as preceding Azure infrastructure section.

インターネット エンドポイントInternet endpoint

通信の確立に用いられるインターネット エンドポイントと共に、前のセクションが当てはまります。The previous sections apply, along with the Internet endpoint that communication is established with. その他、以下の要因も、接続の成功に影響を及ぼす可能性があります。Other factors that can impact connectivity success are:

  • 宛先側でのトラフィック管理 (以下を含む)traffic management on destination side, including
  • 宛先側によって課される API レート制限API rate limiting imposed by the destination side
  • Volumetric DDoS の軽減策やトランスポート層のトラフィック シェイプVolumetric DDoS mitigations or transport layer traffic shaping
  • ファイアウォールなど、宛先側のコンポーネントfirewall or other components at the destination

通常、発生している事象を調査するためには、送信元と宛先 (可能な場合) でのパケット キャプチャが必要です。Usually packet captures at the source and the destination (if available) are required to determine what is taking place.

解決方法:Solution:

  • SNAT の枯渇が生じていないかチェックします。Check for SNAT exhaustion.
  • 同じリージョン (または比較のために他のリージョン) のエンドポイントとの接続を確認します。Validate connectivity to an endpoint in the same region or elsewhere for comparison.
  • 大容量または高トランザクション速度のテストを実施している場合、速度を落とすことでエラーの頻度が下がるかどうかを調べます。If you're creating high volume or transaction rate testing, explore if reducing the rate reduces the occurrence of failures.
  • 速度を変えることでエラーの割合に変化が生じる場合は、API 速度制限など、宛先側の制約が上限に達しているかどうかを確認します。If changing rate impacts the rate of failures, check if API rate limits or other constraints on the destination side might have been reached.
  • 調査しても結論が出ない場合は、サポート ケースを開いて詳細なトラブルシューティングを行ってください。If your investigation is inconclusive, open a support case for further troubleshooting.

TCP リセットの受信TCP Resets received

NAT ゲートウェイでは、進行中として認識されないトラフィックに対して、送信元 VM で TCP がリセットされます。The NAT gateway generates TCP resets on the source VM for traffic that isn't recognized as in progress.

考えられる原因の 1 つは、TCP 接続のアイドル タイムアウトです。アイドル タイムアウトは、4 分から最大 120 分までの範囲で調整できます。One possible reason is the TCP connection has idle timed out. You can adjust the idle timeout from 4 minutes to up to 120 minutes.

TCP リセットが NAT ゲートウェイ リソースのパブリック側で生成されることはありません。TCP Resets aren't generated on the public side of NAT gateway resources. 宛先側の TCP リセットは、NAT ゲートウェイ リソースではなく、送信元 VM で生成されます。TCP resets on the destination side are generated by the source VM, not the NAT gateway resource.

解決方法:Solution:

  • 設計パターンの推奨事項を確認します。Review design patterns recommendations.
  • 必要であれば、サポート ケースを開いて詳細なトラブルシューティングを行ってください。Open a support case for further troubleshooting if necessary.

IPv6 の共存IPv6 coexistence

Virtual Network NAT は IPv4 の UDP および TCP プロトコルをサポートしており、IPv6 プレフィックスを使用したサブネットへのデプロイはサポートされませんVirtual Network NAT supports IPv4 UDP and TCP protocols and deployment on a subnet with an IPv6 prefix isn't supported.

解決方法: IPv6 プレフィックスが使用されていないサブネットに NAT ゲートウェイをデプロイしてください。Solution: Deploy NAT gateway on a subnet without IPv6 prefix.

追加機能のご要望は、Virtual Network NAT の UserVoice までお寄せください。You can indicate interest in additional capabilities through Virtual Network NAT UserVoice.

NAT ゲートウェイ IP から接続が行われないConnection doesn't originate from NAT gateway IP(s)

NAT ゲートウェイ、使用する IP アドレス、NAT ゲートウェイ リソースを使用するサブネットを構成します。You configure NAT gateway, IP address(es) to use, and which subnet should use a NAT gateway resource. しかし、NAT ゲートウェイが展開される前から存在していた仮想マシン インスタンスからの接続では、その IP アドレスは使用されません。However, connections from virtual machine instances that existed before the NAT gateway was deployed don't use the IP address(es). NAT ゲートウェイ リソースで使用されていない IP アドレスを使用しているようです。They appear to be using IP address(es) not used with the NAT gateway resource.

解決方法:Solution:

Virtual Network NAT によって、構成されているサブネットの送信接続が置き換えられます。Virtual Network NAT replaces the outbound connectivity for the subnet it is configured on. 既定の SNAT またはロード バランサーの送信 SNAT から NAT ゲートウェイを使用するように切り替えると、新しい接続から NAT ゲートウェイ リソースに関連付けられた IP アドレスの使用が直ちに開始されます。When transitioning from default SNAT or load balancer outbound SNAT to using NAT gateways, new connections will immediately begin using the IP address(es) associated with the NAT gateway resource. しかし、NAT ゲートウェイ リソースへの切り替え中に、仮想マシンの接続が引き続き確立されている場合、接続の確立時に割り当てられた古い SNAT IP アドレスを使用して接続が続行されます。However, if a virtual machine still has an established connection during the switch to NAT gateway resource, the connection will continue using the old SNAT IP address that was assigned when the connection was established. OS またはブラウザーが接続プール内の接続をキャッシュしていたため、既に存在する接続を再利用するのではなく、新しい接続を実際に確立していることを確認してください。Make sure you are really establishing a new connection rather than reusing a connection that already existed because the OS or the browser was caching the connections in a connection pool. たとえば、PowerShell で curl を使用する場合は、新しい接続を強制するために -DisableKeepalive パラメーターを必ず指定します。For example, when using curl in PowerShell, make sure to specify the -DisableKeepalive parameter to force a new connection. ブラウザーを使用している場合は、接続をプールすることもできます。If you're using a browser, connections may also be pooled.

NAT ゲートウェイ リソースのサブネットを構成する仮想マシンを再起動する必要はありません。It's not necessary to reboot a virtual machine configuring a subnet for a NAT gateway resource. しかし、仮想マシンが再起動されると、接続状態がフラッシュされます。However, if a virtual machine is rebooted, the connection state is flushed. 接続状態がフラッシュされると、すべての接続で NAT ゲートウェイ リソースの IP アドレスの使用が開始されます。When the connection state has been flushed, all connections will begin using the NAT gateway resource's IP address(es). しかし、これは再起動される仮想マシンの副作用であり、再起動が必要なインジケーターではありません。However, this is a side effect of the virtual machine being rebooted and not an indicator that a reboot is required.

それでも問題が解決しない場合は、さらにトラブルシューティングを行うためにサポート ケースを開いてください。If you are still having trouble, open a support case for further troubleshooting.

次のステップNext steps