Application Gateway のバックエンドの正常性に関する問題のトラブルシューティング

概要

既定では、Azure Application Gateway は、バックエンド サーバーに対して probe を実行して、その正常性状態を確認すると共に、バックエンド サーバーが要求を処理する準備ができているかどうかを確認します。 ユーザーは、カスタム probe を作成して、ホスト名、probe の対象となるパス、および正常として受け入れられる状態コードを指定することもできます。 どちらのケースでも、バックエンド サーバーが正常に応答しない場合、Application Gateway はそのサーバーを "異常" とマークし、サーバーへの要求の転送を停止します。 サーバーが正常に応答し始めると、Application Gateway は要求の転送を再開します。

バックエンドの正常性を確認する方法

バックエンド プールの正常性を確認するには、Azure portal の [バックエンド正常性] ページを使用できます。 また、Azure PowerShell、CLI、または REST API を使用することもできます。

これらのいずれかの方法で取得される状態は、次のいずれかになります。

• Healthy
• 異常
• Unknown

バックエンド プールのサーバーが正常な状態の場合、Application Gateway はそれに要求を転送します。 バックエンド プール内のすべてのサーバーが異常または不明な場合は、クライアントでバックエンド アプリケーションへのアクセスに関する問題が発生する可能性があります。 以降では、バックエンド正常性によって報告されるさまざまなメッセージ、その原因、および解決策について詳しく説明します。

バックエンドの正常性状態: 異常

バックエンドの正常性状態が異常の場合、ポータルの表示は次のスクリーンショットのようになります。

Azure PowerShell、CLI、または Azure REST API のクエリを使っている場合は、次の例のような応答を受け取ります。

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

バックエンド プール内のすべてのサーバーについて、バックエンド サーバーの状態として "異常" が返される場合、要求はサーバーに転送されず、Application Gateway は 502 "ゲートウェイが不適切です" というエラーを要求元のクライアントに返します。 この問題のトラブルシューティングを行うには、[バックエンド正常性] タブの [詳細] 列を確認します。

[詳細] 列に表示されるメッセージは問題に関する詳細な分析情報を示すため、それらの詳細に基づいて、問題のトラブルシューティングを開始できます。

エラー メッセージ

バックエンド サーバーのタイムアウト

メッセージ: Time taken by the backend to respond to application gateway's health probe is more than the timeout threshold in the probe setting. (バックエンドがアプリケーション ゲートウェイの正常性 probe に応答するのにかかる時間が、probe 設定のタイムアウトしきい値を超えています。)

原因: Application Gateway は、HTTP(S) probe 要求をバックエンド サーバーに送信した後、構成された期間にわたってバックエンド サーバーからの応答を待ちます。 バックエンド サーバーが、この期間 (タイムアウト値) 内に応答しない場合は、構成されたタイムアウト期間内に応答するまで、"異常" とマークされます。

解決策: 構成されたタイムアウト期間内にバックエンド サーバーまたはアプリケーションが応答しない理由を確認し、アプリケーションの依存関係も確認します。 たとえば、応答の遅延を引き起こす可能性がある問題がデータベースにあるかどうかを確認します。 アプリケーションの動作を把握したうえでアプリケーションがタイムアウト値の経過後にのみ応答するようにする必要がある場合は、カスタム probe 設定でタイムアウト値を引き上げます。 タイムアウト値を変更するには、カスタム probe が必要です。 カスタム probe を構成する方法については、こちらのドキュメントのページを参照してください。

タイムアウト値を引き上げるには、次の手順に従います。

1. バックエンド サーバーに直接アクセスし、そのページでサーバーが応答するまでにかかった時間を確認します。 開発者ツールを使用するブラウザーなど、任意のツールを使用してバックエンド サーバーにアクセスできます。
2. アプリケーションが応答するまでの時間を把握したら、[正常性プローブ] タブを選んでから、対象の HTTP 設定に関連付けられているプローブを選びます。
3. アプリケーションの応答時間を超える任意のタイムアウト値を秒単位で入力します。
4. カスタム probe 設定を保存し、バックエンドの正常性が [正常] と表示されるかどうかを確認します。

DNS の解決エラー

メッセージ: Application Gateway could not create a probe for this backend. (Application Gateway でこのバックエンドに対するプローブを作成できませんでした。) This usually happens when the FQDN of the backend has not been entered correctly. (これは、通常、バックエンドの FQDN が正しく入力されていない場合に発生します。) 

原因: バックエンド プールの種類が IP アドレス、FQDN (完全修飾ドメイン名)、または App Service の場合、Application Gateway は DNS を通して入力された FQDN の IP アドレスに解決します (カスタムまたは Azure の既定値)。 その後、アプリケーション ゲートウェイは、HTTP の設定で指定されている TCP ポートでサーバーへの接続を試みます。 ただし、このメッセージが表示された場合は、Application Gateway が入力された FQDN の IP アドレスを正常に解決できなかったことを示しています。

解決策:

1. バックエンド プールに入力された FQDN が正しいことと、それがパブリック ドメインであることを確認し、ローカル コンピューターから解決を試みます。
2. IP アドレスを解決できる場合は、仮想ネットワークの DNS 構成に問題がある可能性があります。
3. 仮想ネットワークがカスタム DNS サーバーで構成されているかどうかを確認してください。 そのようになっている場合は、DNS サーバーが指定された FQDN の IP アドレスに解決されない理由を確認します。
4. Azure の既定の DNS を使用している場合は、ドメイン名レジストラーで、適切な A レコードまたは CNAME レコード マッピングが完了していることを確認します。
5. ドメインがプライベートまたは内部の場合は、同じ仮想ネットワーク内の VM から解決を試みます。 解決できる場合は、Application Gateway を再起動して、もう一度確認してください。 Application Gateway を再起動するには、次のリンク先のリソースで説明されている PowerShell コマンドを使用して、停止および起動する必要があります。

TCP 接続エラー

メッセージ: Application Gateway could not connect to the backend. (Application Gateway がバックエンドに接続できませんでした。) Check that the backend responds on the port used for the probe. (バックエンドがプローブに使用されるポートで応答することを確認してください。) Also check whether any NSG/UDR/Firewall is blocking access to the Ip and port of this backend. (また、NSG、UDR、またはファイアウォールによってこのバックエンドの IP とポートへのアクセスがブロックされているかどうかも確認してください。)

原因: DNS 解決フェーズの後、アプリケーション ゲートウェイは、HTTP 設定で構成されている TCP ポートでバックエンド サーバーへの接続を試行します。 Application Gateway が指定されたポートで TCP セッションを確立できない場合、probe はこのメッセージで "異常" とマークされます。

解決策: このエラーが発生した場合は、次のステップを実行します。

1. ブラウザーまたは PowerShell を使用して、HTTP 設定に指定されているポートでバックエンド サーバーに接続できるかどうかを確認します。 たとえば、Test-NetConnection -ComputerName www.bing.com -Port 443 コマンドを実行します。

2. 指定されているポートが目的のポートではない場合は、Application Gateway がバックエンド サーバーに接続するための適切なポート番号を入力します。

3. そのポート経由でローカル コンピューターからも接続できない場合は、次のようにします。

   a. バックエンド サーバーのネットワーク アダプターとサブネットのネットワーク セキュリティ グループ (NSG) 設定を調べて、構成されているポートへのインバウンド接続が許可されているかどうかを確認します。 許可されていない場合は、接続を許可する新しい規則を作成します。 NSG 規則の作成方法については、こちらのドキュメント ページを参照してください。

   b. Application Gateway サブネットの NSG 設定で、接続を確立できるようにパブリックおよびプライベートのアウトバウンド トラフィックが許可されているかどうかを確認します。 NSG 規則を作成する方法の詳細については、手順 3a に示されているドキュメントのページを参照してください。

           $vnet = Get-AzVirtualNetwork -Name "vnetName" -ResourceGroupName "rgName"
           Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
   

   c. Application Gateway およびバックエンド サーバーのサブネットのユーザー定義ルート (UDR) 設定でルーティングの異常の有無を確認します。 UDR によってトラフィックがバックエンド サブネットの外へ送信される設定になっていないことを確認します。 たとえば、ネットワーク仮想アプライアンスへのルートや、Azure ExpressRoute および VPN 経由で Application Gateway サブネットにアドバタイズされる既定のルートを確認します。

   d. ネットワーク アダプターの有効なルートと規則を確認するために、次の PowerShell コマンドを使用できます。

           Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
           Get-AzEffectiveRouteTable -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
   

4. NSG または UDR で問題が見つからない場合は、構成されているポートでクライアントが TCP セッションを確立するのを妨げるようなアプリケーション関連の問題がないかどうかを、バックエンド サーバーで確認します。 いくつかの確認事項を次に示します。

   a. コマンド プロンプトを開き (Win + R キー -> 「cmd」と入力)、「netstat」と入力して、Enter キーを押します。

   b. 構成されているポートでサーバーがリッスンしているかどうかを確認します。 次に例を示します。

           Proto Local Address Foreign Address State PID
           TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
   

   c. 構成されているポートでリッスンしていない場合は、Web サーバーの設定を確認します。 たとえば、IIS のサイト バインド、NGINX のサーバー ブロック、Apache の仮想ホストなどです。

   d. OS のファイアウォール設定を調べて、ポートへの受信トラフィックが許可されていることを確認します。

HTTP 状態コードの不一致

メッセージ: Status code of the backend's HTTP response did not match the probe setting. (バックエンドの HTTP 応答の状態コードが probe 設定と一致しませんでした。) Expected:{HTTPStatusCode0} Received:{HTTPStatusCode1}. (必要: {HTTPStatusCode0} 受信: {HTTPStatusCode1}。)

原因: TCP 接続が確立され、TLS ハンドシェイクが完了すると (TLS が有効な場合)、アプリケーション ゲートウェイはプローブを HTTP GET 要求としてバックエンド サーバーに送信します。 前に説明したように、既定のプローブの対象は <protocol>://127.0.0.1:<port>/ であり、200 から 399 の範囲の応答状態コードが正常と見なされます。 サーバーがそれ以外の状態コードを返した場合、それはこのメッセージで "異常" とマークされます。

解決策: バックエンド サーバーの応答コードに応じて、次のステップを実行できます。 一般的な状態コードをいくつか次に示します。

または、応答が正当なものであると判断したうえで、Application Gateway が他の状態コードを正常として受け入れるようにする場合は、カスタム probe を作成できます。 この方法は、バックエンド Web サイトで認証が必要な場合に役立ちます。 プローブ要求にはユーザーの資格情報が含まれないため、これらの要求は失敗し、バックエンド サーバーから HTTP 401 状態コードが返されます。

カスタム probe を作成するには、こちらの手順に従います。

HTTP 応答本文の不一致

メッセージ: バックエンドの HTTP 応答の本文がプローブ設定と一致しませんでした。 Received response body does not contain {string}. (受信した応答本文に {string} が含まれていません。)

原因: カスタム プローブを作成するときに、応答本文の文字列と一致させることによってバックエンド サーバーを正常とマークできます。 たとえば、一致する文字列として "unauthorized" を受け入れるように Application Gateway を構成できます。 プローブ要求に対するバックエンド サーバーの応答に文字列 unauthorized が含まれている場合、それは "正常" とマークされます。 それ以外の場合は、示されたメッセージで "異常" とマークされます。

解決策: この問題を解決するには、次のステップに従ってください。

1. バックエンド サーバーにローカルでアクセスするか、probe パス上のクライアント マシンからアクセスして、応答本文を確認します。
2. Application Gateway のカスタム probe 構成で、応答本文が構成内容と一致するかどうかを確認します。
3. それらが一致しない場合は、受け入れる正しい文字列値を持つように probe 構成を変更します。

Application Gateway の probe の一致の詳細を確認します。

共通名 (CN) が一致しません

メッセージ: (V2 の場合) バックエンド サーバーによって提示されるリーフ証明書の共通名が、アプリケーション ゲートウェイのプローブまたはバックエンド設定のホスト名と一致しません。
(V1 の場合) バックエンド証明書の共通名 (CN) が一致しません。

原因: (V2 の場合) これは、バックエンド設定で HTTPS プロトコルを選する場合で、かつカスタム プローブやバックエンド設定のホスト名が (この順番で) バックエンド サーバー証明書の共通名 (CN) と一致しない場合に発生します。
(V1 の場合) バックエンド プール ターゲットの FQDN が、バックエンド サーバーの証明書の共通名 (CN) と一致しません。

解決策: ホスト名情報は、その値が TLS ハンドシェイク中に Server Name Indication (SNI) の設定で使用されるため、バックエンド HTTPS 接続では重要です。 この問題は、ゲートウェイの構成に応じて次のいずれかの方法で修正できます。

V2 の場合、

• 既定のプローブを使用している場合 – アプリケーション ゲートウェイの関連付けられているバックエンド設定でホスト名を指定できます。 [バックエンド設定] で [特定のホスト名でオーバーライドする] または [バックエンド ターゲットからホスト名を選択する] を選択できます。
• カスタム プローブを使用している場合 - カスタム プローブの場合、[ホスト] フィールドを使用して、バックエンド サーバーの証明書の共通名を指定できます。 または、[バックエンド設定] で既に同じホスト名が構成されている場合、プローブ設定で [バックエンド設定からホスト名を選択する] を選択できます。

V1 の場合、バックエンド プール ターゲットの FQDN が共通名 (CN) と同じであることを確認します。

ヒント: バックエンド サーバーの証明書の共通名 (CN) を確認するには、次のいずれかの方法を使用できます。 また、RFC 6125 に従って、SAN が存在する場合は、SNI の検証はそのフィールドに対してのみ行われることに注意してください。 証明書に SAN がない場合は、共通名フィールドが照合されます。

• ブラウザーまたは任意のクライアントを使用する: バックエンド サーバーに直接 (App Gateway を介さずに) アクセスし、アドレス バーの証明書南京錠をクリックして証明書の詳細を表示します。 [発行先] セクションに共通名が表示されます。

• バックエンド サーバーにログインする (Windows):

  1. 対象のアプリケーションがホストされているマシンにサインインします。
  2. Win + R キーを押すか、[スタート] を右クリックして [実行] を選択します。
  3. 「certlm.msc」と入力し、Enter キーを押します。 [スタート] メニューで証明書マネージャーを検索することもできます。
  4. 証明書を見つけ (通常は、証明書 - ローカル コンピューター\個人\証明書内にあります)、証明書を開きます。
  5. [詳細] タブで、証明書の [サブジェクト] を確認します。

• バックエンド サーバーにログインする (Linux): 適切な証明書ファイル名を指定して、OpenSSL コマンド openssl x509 -in certificate.crt -subject -noout を実行します

バックエンドの有効期限が切れています

メッセージ: Backend certificate is invalid. (バックエンド証明書が無効です。) 現在の日付が、証明書の "有効期間開始日" と "有効期間終了日" の範囲内ではありません。

原因: 期限切れの証明書は安全でないと見なされるため、アプリケーション ゲートウェイはバックエンド サーバーに期限切れの証明書を異常としてマークします。

解決策: 解決策は、バックエンド サーバーの証明書チェーンのどの部分が期限切れであるかによって異なります。

V2 SKU の場合、

• リーフ (ドメインまたはサーバーとも呼ばれます) 証明書の期限切れ - 証明書プロバイダーでサーバー証明書を更新し、新しい証明書をバックエンド サーバーにインストールします。 Leaf (topmost) > Intermediate(s) > Root で構成される完全な証明書チェーンをインストールしてください。 証明機関 (CA) の種類によっては、お使いのゲートウェイに対して次のアクションを実行する必要があります。

  • 一般に知られている CA: 証明書の発行者が既知の CA である場合は、アプリケーション ゲートウェイに対して何も行う必要はありません。
  • プライベート CA: リーフ証明書がプライベート CA によって発行された場合は、署名ルート CA 証明書が変更されたかどうかを確認する必要があります。 このような場合、お使いのゲートウェイの関連付けられたバックエンド設定に新しいルート CA 証明書 (.CER) をアップロードする必要があります。

• 中間証明書またはルート証明書の期限切れ – 通常、これらの証明書の有効期間は比較的長くなっています (10 から 20 年)。 ルートまたは中間証明書の有効期限が切れた場合、更新された証明書ファイルについて証明書プロバイダーに確認することをお勧めします。 バックエンド サーバーに、Leaf (topmost) > Intermediate(s) > Root で構成される更新済みの完全な証明書チェーンがインストールされていることを確認します。

  • ルート証明書が変更されていない場合、または発行者が既知の CA である場合は、アプリケーション ゲートウェイに対して何も行う必要はありません。
  • プライベート CA を使用しており、ルート CA 証明書自体または更新された中間証明書のルートが変更された場合は、新しいルート証明書をアプリケーション ゲートウェイのバックエンド設定にアップロードする必要があります。

V1 SKU の場合、

• 期限切れのリーフ (ドメインまたはサーバーとも呼ばれます) 証明書を CA で更新し、同じリーフ証明書 (.CER) を、お使いのアプリケーション ゲートウェイの関連付けられているバックエンド設定にアップロードします。

中間証明書が見つかりませんでした

メッセージ: バックエンド サーバーによって提示された証明書チェーンに中間証明書がありません。 証明書チェーンが完全で、バックエンド サーバーで正しく順序付けされていることを確認します。

原因: 中間証明書がバックエンド サーバーの証明書チェーンにインストールされていません。

解決策: 中間証明書はリーフ証明書に署名するために使用されます。そのため、チェーンを完了するには、この証明書が必要です。 必要な中間証明書を認証局 (CA) に確認し、バックエンド サーバーにインストールしてください。 このチェーンは、リーフ証明書で始まり、次に中間証明書、最後はルート CA 証明書の順である必要があります。 ルート CA 証明書を含め、バックエンド サーバーに完全なチェーンをインストールすることをお勧めします。 参考までに、「リーフはチェーンの最上位である必要があります」の証明書チェーンの例を確認してください。

以下の画像は、自己署名証明書の違いを示しています。

リーフまたはサーバー証明書が見つからない

メッセージ: バックエンド サーバーによって提示された証明書チェーンにリーフ証明書がありません。 チェーンが完全で、バックエンド サーバーで正しく順序付けされていることを確認します。

原因: バック エンド サーバーの証明書チェーンにリーフ (ドメインまたはサーバーと呼ばれます) 証明書がありません。

解決策: 証明機関 (CA) からリーフ証明書を取得できます。 このリーフ証明書とそのすべての署名証明書 (中間 CA 証明書とルート CA 証明書) をバックエンド サーバーにインストールします。 このチェーンは、リーフ証明書で始まり、次に中間証明書、最後はルート CA 証明書の順である必要があります。 ルート CA 証明書を含め、バックエンド サーバーに完全なチェーンをインストールすることをお勧めします。 参考までに、「リーフはチェーンの最上位である必要があります」の証明書チェーンの例を確認してください。

サーバーまたは中間証明書が一般に知られている CA によって発行されていない

メッセージ: The backend Server certificate isn't signed by a well-known Certificate Authority (CA). (バックエンド サーバー証明書が、既知の証明機関 (CA) によって署名されていません。) 不明な CA 証明書を使用するには、そのルート証明書をアプリケーション ゲートウェイのバックエンド設定にアップロードする必要があります。

原因: バックエンドの設定で [well-known CA certificate] (既知の CA 証明書) を選びましたが、バックエンド サーバーから提示されたルート証明書は公に既知のものではありません。

解決策: プライベートの証明機関 (CA) によって発行されたリーフ証明書の場合、署名ルート CA 証明書をアプリケーション ゲートウェイの関連付けられたバックエンド設定にアップロードする必要があります。 こうすることで、アプリケーション ゲートウェイはそのバックエンド サーバーとの信頼された接続を確立できます。 これを解決するには、関連付けられたバックエンド設定に移動し、[not a well-known CA] (既知ではない CA) を選び、ルート CA 証明書 (.CER) をアップロードします。 ルート証明書を特定してダウンロードするには、「信頼されたルート証明書の不一致」に記載されているものと同じ手順を実行します。

中間証明書が一般に知られている CA によって署名されていない

メッセージ: The Intermediate certificate isn't signed by a well-known Certificate Authority (CA). (中間証明書が、既知の証明機関 (CA) によって署名されていません。) 証明書チェーンが完全で、バックエンド サーバーで正しく順序付けされていることを確認します。

原因: バックエンドの設定で [well-known CA certificate] (既知の CA 証明書) を選びましたが、バックエンド サーバーから提示された中間証明書は公に既知の CA ではありません。

解決策: プライベートの証明機関 (CA) によって発行された証明書の場合、署名ルート CA 証明書をアプリケーション ゲートウェイの関連付けられたバックエンド設定にアップロードする必要があります。 こうすることで、アプリケーション ゲートウェイはそのバックエンド サーバーとの信頼された接続を確立できます。 これを修正するには、プライベート CA に問い合わせて適切なルート CA 証明書 (.CER) を取得し、[not a well-known CA] (既知ではない CA) を選んでその CER ファイルをアプリケーション ゲートウェイのバックエンド設定にアップロードします。 また、簡単に検証できるように、ルート CA 証明書を含め、バックエンド サーバーに完全なチェーンをインストールすることをお勧めします。

信頼されたルート証明書が一致しない (バックエンド サーバーにルート証明書がない)

メッセージ: 中間証明書が、アプリケーション ゲートウェイにアップロードされたルート証明書によって署名されていません。 証明書チェーンが完全で、バックエンド サーバーで正しく順序付けされていることを確認します。

原因: 関連付けられたバックエンド設定にアップロードされたルート CA 証明書のいずれも、バックエンド サーバーにインストールされた中間証明書に署名していません。 バックエンド サーバーには、リーフ証明書と中間証明書のみがインストールされています。

解決策: リーフ証明書を中間証明書で署名し、中間証明書をルート CA 証明書で署名します。 プライベート証明機関 (CA) の証明書を使う場合は、対応するルート CA 証明書をアプリケーション ゲートウェイにアップロードする必要があります。 プライベート CA に問い合わせて適切なルート CA 証明書 (.CER) を取得し、その CER ファイルをアプリケーション ゲートウェイのバックエンド設定にアップロードします。

信頼されたルート証明書が一致しない (ルート証明書はバックエンド サーバーで使用できる)

メッセージ: The root certificate of the server certificate used by the backend doesn't match the trusted root certificate added to the application gateway. (バックエンドによって使用されるサーバー証明書のルート証明書が、アプリケーション ゲートウェイに追加されている信頼されたルート証明書と一致しません。) Ensure that you add the correct root certificate to allowlist the backend. (バックエンドを許可リストに登録するために適切なルート証明書を追加していることを確認してください)

原因: このエラーが発生するのは、アプリケーション ゲートウェイのバックエンド設定にアップロードされたルート証明書のいずれも、バックエンド サーバーに存在するルート証明書と一致しない場合です。

解決策: これは、プライベート証明機関 (CA) によって発行されたバックエンド サーバー証明書、または自己署名証明書に適用されます。 正しいルート CA 証明書を特定し、関連付けられたバックエンド設定にアップロードします。

ヒント: ルート証明書を特定してダウンロードするには、次のいずれかの方法を使用できます。

• ブラウザーを使用する: バックエンド サーバーに直接 (Application Gateway を介さずに) アクセスし、アドレス バーの証明書南京錠をクリックして証明書の詳細を表示します。

  1. チェーンでルート証明書を選択し、[エクスポート] をクリックします。 既定では、これは .CRT ファイルです。
  2. .CRT ファイルを開きます。
  3. [詳細] タブに移動し、[ファイルにコピー] をクリックします。
  4. 証明書のエクスポート ウィザード ページで、[次へ] をクリックします。
  5. [Base-64 エンコード X.509 (.CER)] を選択し、[次へ] をクリックします。
  6. 新しいファイル名を付け、[次へ] をクリックします。
  7. [完了] をクリックして .CER ファイルを取得します。
  8. プライベート CA のこのルート証明書 (.CER) をアプリケーション ゲートウェイのバックエンド設定にアップロードします。

• バックエンド サーバーにログインする (Windows)

  1. 対象のアプリケーションがホストされているマシンにサインインします。
  2. Win + R キーを押すか、[スタート] を右クリックして [実行] を選択します。
  3. 「certlm.msc」と入力し、Enter キーを押します。 [スタート] メニューで証明書マネージャーを検索することもできます。
  4. 証明書を見つけ (通常は、証明書 - ローカル コンピューター\個人\証明書内にあります)、それを開きます。
  5. ルート証明書を選択し、[証明書の表示] を選択します。
  6. 証明書のプロパティで、[詳細] タブを選択し、[ファイルにコピー] をクリックします。
  7. 証明書のエクスポート ウィザード ページで、[次へ] をクリックします。
  8. [Base-64 エンコード X.509 (.CER)] を選択し、[次へ] をクリックします。
  9. 新しいファイル名を付け、[次へ] をクリックします。
  10. [完了] をクリックして .CER ファイルを取得します。
  11. プライベート CA のこのルート証明書 (.CER) をアプリケーション ゲートウェイのバックエンド設定にアップロードします。

リーフはチェーンの最上位である必要がある

メッセージ: The Leaf certificate isn't the topmost certificate in the chain presented by the backend server. (リーフ証明書が、バックエンド サーバーで提示されたチェーンの最上位証明書ではありません。) 証明書チェーンがバックエンド サーバーで正しく順序付けされていることを確認します。

原因: リーフ (ドメインまたはサーバーとも呼ばれます) 証明書がバックエンド サーバーに正しい順序でインストールされていません。

解決策: バックエンド サーバーへの証明書のインストールには、リーフ証明書とそのすべての署名証明書 (中間およびルート CA 証明書) で構成される順序付き証明書リストが含まれている必要があります。 このチェーンは、リーフ証明書で始まり、次に中間証明書、最後はルート CA 証明書の順である必要があります。 ルート CA 証明書を含め、バックエンド サーバーに完全なチェーンをインストールすることをお勧めします。

たとえば、サーバー証明書とその中間およびルート CA 証明書のインストールを OpenSSL で深さ (0、1、2 など) として示す場合、 次の OpenSSL コマンドを使用して、バックエンド サーバーの証明書についても同じであることを確認できます。
s_client -connect <FQDN>:443 -showcerts
または
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

証明書の検証の失敗

メッセージ: The validity of the backend certificate could not be verified. (バックエンド証明書の有効性を検証できませんでした。) To find out the reason, check OpenSSL diagnostics for the message associated with error code {errorCode} (理由を調べるには、エラー コード {errorCode} に関連付けられたメッセージの OpenSSL 診断を確認してください)

原因: このエラーは、Application Gateway が証明書の有効性を確認できない場合に発生します。

解決策: この問題を解決するには、サーバー上の証明書が適切に作成されていることを確認します。 たとえば、OpenSSL を使用して、証明書とそのプロパティを確認し、Application Gateway の HTTP 設定への証明書の再アップロードを試行できます。

バックエンドの正常性状態: 不明

バックエンド プールの DNS エントリの更新

メッセージ: The backend health status could not be retrieved. (バックエンドの正常性状態を取得できませんでした。) This happens when an NSG/UDR/Firewall on the application gateway subnet is blocking traffic on ports 65503-65534 in case of v1 SKU, and ports 65200-65535 in case of the v2 SKU or if the FQDN configured in the backend pool could not be resolved to an IP address. (これは、v1 SKU の場合はポート 65503 から 65534、v2 SKU の場合はポート 65200 から 65535 のトラフィックがアプリケーション ゲートウェイ サブネット上の NSG/UDR/Firewall によってブロックされている場合、またはバックエンド プールで構成された FQDN を IP アドレスに解決できない場合に発生します。) To learn more visit - https://aka.ms/UnknownBackendHealth. (詳細については、次にアクセスしてください。)

原因: FQDN (完全修飾ドメイン名) ベースのバックエンド ターゲットの場合、Application Gateway では、後続の DNS ルックアップに対する応答を取得できなかった場合、正常であることが既知の最後の IP アドレスをキャッシュして使用します。 この状態でゲートウェイに対して PUT 操作を行うと、DNS キャッシュが完全にクリアされます。 その結果、ゲートウェイが到達できる宛先アドレスが存在しなくなります。

解決策: DNS サーバーが、特定の FDQN の DNS ルックアップに対する応答を提供しているかどうかを確認し、そうでなければ修正します。 また、アプリケーション ゲートウェイの Virtual Network を介して DNS サーバーに到達できるかどうかを確認する必要もあります。

その他の理由。

バックエンドの正常性状態が [不明] の場合、ポータル ビューは次のスクリーンショットのようになります。

この動作は、次の 1 つ以上の理由で発生することがあります。

1. Application Gateway サブネット上の NSG によって、ポート 65503 から 65534 (v1 SKU) または 65200 から 65535 (v2 SKU) への "インターネット" からのインバウンド アクセスがブロックされている。
2. Application Gateway サブネット上の UDR が既定のルート (0.0.0.0/0) に設定され、次ホップが "インターネット" として指定されていない。
3. Virtual Network への BGP 経由の ExpressRoute/VPN 接続によって、既定のルートがアドバタイズされる。
4. パブリック ドメイン名を解決できない Virtual Network 上にカスタム DNS サーバーが構成されている。
5. Application Gateway が異常な状態である。

解決方法:

1. NSG によって、ポート 65503 から 65534 (v1 SKU) または 65200 から 65535 (v2 SKU) へのインターネットからのアクセスがブロックされているかどうかを確認します。

   a. Application Gateway の [概要] タブで、[仮想ネットワーク/サブネット] リンクを選択します。 b. お使いの仮想ネットワークの [サブネット] タブで、アプリケーション ゲートウェイがデプロイされているサブネットを選択します。 c. NSG が構成されているかどうかを確認します。 d. NSG が構成されている場合は、[検索] タブまたは [すべてのリソース] でその NSG リソースを検索します。 e. [受信規則] セクションで、[ソース] が GatewayManager サービス タグに設定されている、65503 から 65534 (v1 SKU の場合) または 65200 から 65535 (v2 SKU の場合) の宛先ポート範囲を許可するインバウンド規則を追加します。 f. [保存] を選択し、バックエンドが正常として表示されることを確認します。 または、PowerShell または CLI を使用してこれを行うこともできます。

2. 次ホップが [インターネット] に設定されていない既定のルート (0.0.0.0/0) が UDR にあるかどうかを確認します。

   a. 手順 1a および 1b に従って、目的のサブネットを判別します。 b. UDR が構成されているかどうかを確認します。 構成されている場合は、検索バーまたは [すべてのリソース] でそのリソースを検索します。 c. 次ホップが [インターネット] に設定されていない既定のルート (0.0.0.0/0) があるかどうかを確認します。 設定が [仮想アプライアンス] または [Virtual Network ゲートウェイ] の場合は、仮想アプライアンスまたはオンプレミスのデバイスによって、パケットが変更されることなくインターネットの宛先に適切に戻されるようにする必要があります。 プローブが仮想アプライアンスを経由でルーティングされ、変更された場合、バックエンド リソースには状態コード 200 が表示され、アプリケーション ゲートウェイの正常性状態が [不明] として表示されることがあります。 これはエラーを示すものではありません。 トラフィックは引き続き問題なく Application Gateway 経由でルーティングされます。 d. それ以外の場合は、次ホップを [インターネット] に変更し、[保存] を選択した後、バックエンドの正常性を確認します。

3. 仮想ネットワークへの BGP (Border Gateway Protocol) 経由の ExpressRoute または VPN 接続によってアドバタイズされる既定のルート:

   a. BGP 経由で仮想ネットワークへの ExpressRoute または VPN 接続を使用していて、既定のルートをアドバタイズしている場合は、パケットが変更されることなくインターネットの宛先に戻されるようにする必要があります。 Application Gateway ポータルの [接続のトラブルシューティング] オプションを使用して確認できます。 b. 1.1.1.1 などの任意のインターネット ルーティング可能な IP アドレスとして宛先を手動で選択します。 任意の宛先ポートを選択して、接続を確認します。 c. 次ホップが仮想ネットワーク ゲートウェイの場合、ExpressRoute または VPN 経由でアドバタイズされる既定のルートが存在する可能性があります。

4. 仮想ネットワークにカスタム DNS サーバーが構成されている場合は、サーバーがパブリック ドメインを解決できるかどうかを確認します。 パブリック ドメイン名の解決は、Application Gateway が OCSP (オンライン証明書状態プロトコル) サーバーなどの外部ドメインにアクセスする必要があるシナリオや、証明書の失効状態などを確認する必要があるシナリオで必要になる場合があります。

5. Application Gateway が正常で実行中であることを確認するには、ポータルで [リソース正常性] オプションに移動し、状態が [正常] であることを確認します。 [異常] または [デグレード] 状態が表示される場合は、サポートにお問い合わせください。

6. インターネットとプライベートのトラフィックが、(Azure Virtual WAN ハブを使用して) セキュリティ保護付き仮想ハブでホストされた Azure Firewall を通過している場合:

   a. アプリケーション ゲートウェイがトラフィックをインターネットに直接送信できるようにするには、次のユーザー定義ルートを構成します。

   アドレス プレフィックス:0.0.0.0/0
   次ホップ:インターネット

   b. アプリケーション ゲートウェイが Virtual WAN のハブの Azure Firewall 経由でバックエンド プールにトラフィックを送信できるようにするには、次のユーザー定義ルートを構成します。

   アドレス プレフィックス: バックエンド プール サブネット
   ネクスト ホップ: Azure Firewall のプライベート IP アドレス

次のステップ

Application Gateway の診断とログの詳細を確認します。