Application Gateway의 백 엔드 상태 문제 해결

아티클
09/30/2024

개요

기본적으로 Azure Application Gateway는 백 엔드 서버를 검색하여 상태를 확인하고 요청을 처리할 준비가 되었는지 여부를 확인합니다. 사용자는 호스트 이름, 검색할 경로 및 정상으로 허용할 상태 코드를 언급하는 사용자 지정 프로브를 만들 수도 있습니다. 각 경우에 백 엔드 서버가 성공적으로 응답하지 않으면 Application Gateway는 서버를 비정상으로 표시하고 요청을 서버로 전달하는 것을 중지합니다. 서버 응답이 성공적으로 시작되면 Application Gateway에서 요청 전달을 다시 시작합니다.

백 엔드 상태를 확인하는 방법

백 엔드 풀의 상태를 확인하기 위해 Azure Portal에서 백 엔드 상태 페이지를 사용할 수 있습니다. 또는 Azure PowerShell, CLI 또는 REST API를 사용할 수 있습니다.

이러한 방법으로 검색되는 상태는 다음 상태 중 하나일 수 있습니다.

정상
비정상
Unknown

Application Gateway는 상태가 정상인 경우 백 엔드 풀에서 서버로 요청을 전달합니다. 백 엔드 풀의 모든 서버가 비정상이거나 알 수 없는 경우 클라이언트는 백 엔드 애플리케이션에 액세스하는 데 문제가 발생할 수 있습니다. 백 엔드 Health에서 보고한 다양한 메시지, 원인 및 해결 방법을 자세히 알아보려면 자세히 읽어보십시오.

참고 항목

사용자에게 백 엔드 상태를 볼 수 있는 권한이 없는 경우 출력 No results. 이 표시됩니다.

백 엔드 상태: 비정상

백 엔드 상태가 비정상 상태인 경우 포털 보기는 다음 스크린샷과 유사합니다.

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 잘못된 게이트웨이” 오류를 반환합니다. 이 문제를 해결하려면 백 엔드 상태 탭에서 세부 정보 열을 확인합니다.

세부 정보 열에 표시되는 메시지는 문제에 대한 보다 자세한 인사이트를 제공하고, 이에 해당 세부 정보에 따라 문제 해결을 시작할 수 있습니다.

참고 항목

기본 프로브 요청은 <프로토콜>://127.0.0.1:<포트> 형식으로 전송됩니다. 예를 들어 포트 80에 대한 HTTP 프로브의 경우 http://127.0.0.1:80입니다. 200~399의 HTTP 상태 코드만 정상으로 간주됩니다. 프로토콜 및 대상 포트는 HTTP 설정에서 상속됩니다. Application Gateway가 다른 프로토콜, 호스트 이름 또는 경로를 검색하고 다른 상태 코드를 정상으로 인식하기를 원하면 사용자 지정 프로브를 구성하고 HTTP 설정과 연결합니다.

오류 메시지

백 엔드 서버 시간 초과

메시지: 백 엔드가 Application Gateway의 상태 검색에 응답하는 데 걸리는 시간이 프로브 설정의 제한 시간 임계값보다 깁니다.

원인: Application Gateway는 백 엔드 서버에 대한 HTTP(S) 프로브 요청을 보낸 후 구성된 기간 동안 백 엔드 서버의 응답을 기다립니다. 백 엔드 서버가 이 기간(시간 제한 값) 내에 응답하지 않으면 구성된 시간 제한 기간 내에 다시 응답할 때까지 비정상으로 표시됩니다.

해결 방법: 구성된 제한 시간 기간 내에 백 엔드 서버 또는 애플리케이션이 응답하지 않는 이유를 확인하고 애플리케이션 종속성도 확인합니다. 예를 들어 데이터베이스에 응답 지연을 트리거할 수 있는 문제가 있는지 여부를 확인합니다. 애플리케이션의 동작을 알고 있으며 시간 제한 값 이후에만 응답해야 하는 경우 사용자 지정 프로브 설정에서 시간 제한 값을 늘입니다. 시간 제한 값을 변경하려면 사용자 지정 프로브가 있어야 합니다. 사용자 지정 프로브를 구성하는 방법에 대한 자세한 내용은 설명서 페이지를 참조하세요.

제한 시간 값을 늘리려면 다음 단계를 수행합니다.

백 엔드 서버에 직접 액세스하여 서버가 해당 페이지에서 응답하는 데 걸린 시간을 확인합니다. 개발자 도구를 사용하는 브라우저를 비롯한 모든 도구를 사용하여 백 엔드 서버에 액세스할 수 있습니다.
애플리케이션이 응답하는 데 걸린 시간을 파악한 후 상태 프로브 탭을 선택한 다음, HTTP 설정과 연결된 프로브를 선택합니다.
애플리케이션 응답 시간(초)보다 큰 제한 시간 값을 입력합니다.
사용자 지정 프로브 설정을 저장하고 백 엔드 상태가 지금 정상으로 표시되는지 확인합니다.

DNS 확인 오류

메시지: Application Gateway에서 이 백 엔드에 대한 프로브를 만들 수 없습니다. 일반적으로 백 엔드의 FQDN이 올바르게 입력되지 않은 경우에 발생합니다.

원인: 백 엔드 풀이 IP 주소, FQDN(정규화된 도메인 이름) 또는 App Service 유형인 경우 Application Gateway는 DNS(사용자 지정 또는 Azure 기본값)를 통해 입력된 FQDN의 IP 주소로 확인됩니다. 그런 다음, 애플리케이션 게이트웨이는 HTTP 설정에 언급된 TCP 포트의 서버에 연결을 시도합니다. 그러나 이 메시지가 표시되는 경우는 Application Gateway에서 입력한 FQDN의 IP 주소를 성공적으로 확인할 수 없다는 것을 나타냅니다.

해결 방법:

백 엔드 풀에 입력한 FQDN이 올바르고 공용 도메인인지 확인한 다음 로컬 컴퓨터에서 확인합니다.
IP 주소를 확인할 수 있는 경우 가상 네트워크의 DNS 구성에 문제가 있을 수 있습니다.
가상 네트워크가 사용자 지정 DNS 서버로 구성되어 있는지 확인합니다. 이 경우 지정된 FQDN의 IP 주소로 확인할 수 없는 이유에 대해 DNS 서버에서 확인합니다.
Azure 기본 DNS를 사용하는 경우 도메인 이름 등록 기관에서 적절한 A 레코드 또는 CNAME 레코드 매핑이 완료되었는지 확인합니다.
도메인이 개인 또는 내부인 경우 동일한 가상 네트워크의 VM에서 확인해 보세요. 확인이 가능한 경우 Application Gateway를 다시 시작하고 다시 확인합니다. Application Gateway를 다시 시작하려면 연결된 이들 리소스에 설명된 PowerShell 명령을 사용하여 중지하고 시작해야 합니다.

TCP 연결 오류

메시지: Application Gateway가 백 엔드에 연결할 수 없습니다. 프로브에 사용되는 포트에서 백 엔드가 응답하는지 확인합니다. 또한 NSG/UDR/방화벽이 이 백 엔드의 IP 및 포트에 대한 액세스를 차단하는지 여부도 확인해야 합니다.

원인: DNS 확인 단계 후 Application Gateway는 HTTP 설정에 구성된 TCP 포트의 백 엔드 서버에 연결을 시도합니다. Application Gateway가 지정된 포트에서 TCP 세션을 설정할 수 없는 경우 프로브는 이 메시지와 함께 비정상으로 표시됩니다.

솔루션: 이 오류가 표시되면 다음 단계를 수행합니다.

브라우저 또는 PowerShell을 사용하여 HTTP 설정에 설명된 포트에서 백 엔드 서버에 연결할 수 있는지 여부를 확인합니다. 예를 들어 다음 명령을 실행합니다. Test-NetConnection -ComputerName www.bing.com -Port 443
언급된 포트가 원하는 포트가 아닌 경우 Application Gateway가 백 엔드 서버에 연결할 올바른 포트 번호를 입력합니다.
로컬 컴퓨터에서 포트에 연결할 수 없는 경우 다음을 수행합니다.

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"
```
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. 구성된 포트에서 수신 대기하고 있지 않으면 웹 서버 설정을 확인합니다. 예: IIS의 사이트 바인딩, NGINX의 서버 블록 및 Apache의 가상 호스트

d. OS 방화벽 설정을 점검하여 포트에 들어오는 트래픽이 허용되는지 확인합니다.

HTTP 상태 코드 불일치

메시지: 백 엔드의 HTTP 응답의 상태 코드가 프로브 설정과 일치하지 않습니다. Expected:{HTTPStatusCode0} Received:{HTTPStatusCode1}.

원인: TCP 연결이 설정되고 TLS 핸드셰이크가 수행된 후(TLS를 사용하는 경우) Application Gateway는 프로브를 HTTP GET 요청으로 백 엔드 서버에 보냅니다. 앞에서 설명한 대로 기본 프로브는 정상으로 설정 <protocol>://127.0.0.1:<port>/되며 200~399 범위의 응답 상태 코드를 정상으로 간주합니다. 서버가 다른 상태 코드를 반환하는 경우 이 메시지와 함께 비정상으로 표시됩니다.

솔루션: 백 엔드 서버의 응답 코드에 따라 다음 단계를 수행할 수 있습니다. 몇 가지 일반적인 상태 코드는 다음과 같습니다.

오류	actions
프로브 상태 코드 불일치: 401 수신	백 엔드 서버에서 인증이 필요한지 여부를 확인합니다. Application Gateway 프로브는 인증을 위해 자격 증명을 전달할 수 없습니다. 프로브 상태 코드 일치에서 “HTTP 401”을 허용하거나 서버가 인증을 요구하지 않는 경로를 검색합니다.
프로브 상태 코드 불일치: 403 수신	액세스가 금지되었습니다. 백 엔드 서버에서 경로에 대한 액세스가 허용되는지 여부를 확인합니다.
프로브 상태 코드 불일치: 404 수신	페이지를 찾을 수 없습니다. 백 엔드 서버에서 호스트 이름 경로에 액세스할 수 있는지 여부를 확인합니다. 호스트 이름 또는 경로 매개 변수를 액세스할 수 있는 값으로 변경합니다.
프로브 상태 코드 불일치: 405 수신	Application Gateway에 대한 프로브 요청은 HTTP GET 메서드를 사용합니다. 서버에서 이 메서드를 허용하는지 여부를 확인합니다.
프로브 상태 코드 불일치: 500 수신	내부 서버 오류입니다. 백 엔드 서버의 상태와 서비스가 실행 중인지 여부를 확인합니다.
프로브 상태 코드 불일치: 503 수신	서비스를 사용할 수 없습니다. 백 엔드 서버의 상태와 서비스가 실행 중인지 여부를 확인합니다.

또는 응답이 합법적인 것으로 생각하고 Application Gateway가 다른 상태 코드를 정상으로 허용하기를 원하는 경우 사용자 지정 프로브를 만들 수 있습니다. 이 방법은 백 엔드 웹 사이트에 인증이 필요한 경우에 유용합니다. 프로브 요청은 사용자 자격 증명을 전달하지 않으므로 실패하고 백 엔드 서버에서 HTTP 401 상태 코드를 반환합니다.

사용자 지정 프로브를 만들려면 다음 단계를 수행합니다.

HTTP 응답 본문 불일치

메시지: 백 엔드의 HTTP 응답 본문이 프로브 설정과 일치하지 않습니다. 받은 응답 본문에 {string}이(가) 없습니다.

원인: 사용자 지정 프로브를 만들 때 응답 본문의 문자열을 일치시켜 백 엔드 서버를 정상으로 표시할 수 있습니다. 예를 들어 '권한 없음'을 일치시킬 문자열로 허용하도록 Application Gateway를 구성할 수 있습니다. 프로브 요청에 대한 백 엔드 서버 응답에 권한이 없는 문자열이 포함되어 있으면 정상으로 표시됩니다. 그렇지 않으면 지정된 메시지와 함께 비정상으로 표시됩니다.

솔루션: 이 문제를 해결하려면 다음 단계를 수행합니다.

검색 경로에서 로컬로 또는 클라이언트 컴퓨터에서 백 엔드 서버에 액세스하고 응답 본문을 확인합니다.
Application Gateway 사용자 지정 프로브 구성의 응답 본문이 구성된 내용과 일치하는지 확인합니다.
일치하지 않는 경우 허용되는 올바른 문자열 값을 갖도록 프로브 구성을 변경합니다.

Application Gateway 프로브 일치에 대해 자세히 알아봅니다.

참고 항목

모든 TLS 관련 오류 메시지의 경우, SNI 동작 및 v1과 v2 SKU 간의 차이점에 대한 자세한 내용을 보려면 TLS 개요 페이지를 확인하세요.

CN(일반 이름)이 일치하지 않음

메시지: (V2의 경우) 백 엔드 서버에서 제공하는 리프 인증서의 일반 이름이 애플리케이션 게이트웨이의 프로브 또는 백 엔드 설정 호스트 이름과 일치하지 않습니다.
(V1의 경우) 백 엔드 인증서의 CN(일반 이름)이 일치하지 않습니다.

원인: (V2의 경우) 백 엔드 설정에서 HTTPS 프로토콜을 선택하고 사용자 지정 프로브 또는 백 엔드 설정의 호스트 이름(해당 순서)이 백 엔드 서버 인증서의 CN(일반 이름)과 일치하지 않을 때 발생합니다.
(V1의 경우) 백 엔드 풀 대상의 FQDN이 백 엔드 서버 인증서의 CN(일반 이름)과 일치하지 않습니다.

솔루션: 이 값은 TLS 핸드셰이크 중에 SNI(서버 이름 표시)를 설정하는 데 사용되므로 호스트 이름 정보는 백 엔드 HTTPS 연결에 매우 중요합니다. 게이트웨이의 구성에 따라 다음과 같은 방법으로 이 문제를 해결할 수 있습니다.

V2에서

기본 프로브를 사용하는 경우 – 애플리케이션 게이트웨이의 연결된 백 엔드 설정에서 호스트 이름을 지정할 수 있습니다. 백 엔드 설정에서 "특정 호스트 이름으로 재정의" 또는 "백 엔드 대상에서 호스트 이름 선택"을 선택할 수 있습니다.
사용자 지정 프로브를 사용하는 경우 – 사용자 지정 프로브에서 "호스트" 필드를 사용하여 백 엔드 서버 인증서의 일반 이름을 지정할 수 있습니다. 또는 백 엔드 설정이 동일한 호스트 이름으로 이미 구성된 경우, 프로브 설정의 "백 엔드 설정에서 호스트 이름 선택"을 선택할 수 있습니다.

V1에서는 백 엔드 풀 대상의 FQDN이 CN(일반 이름)과 동일한지 확인합니다.

팁: 백 엔드 서버 인증서의 CN(일반 이름)을 확인하려면 이러한 메서드를 사용할 수 있습니다. 또한 SAN이 있는 경우 RFC 6125에 따라 SNI 확인은 해당 필드에 대해서만 수행됩니다. 인증서에 SAN이 없는 경우 공통 이름 필드가 일치합니다.

브라우저 또는 클라이언트 사용: Application Gateway를 통하지 않고 백 엔드 서버에 직접 액세스하여 주소 표시줄에서 인증서 자물쇠를 클릭해 인증서 세부 정보를 확인합니다. "발급 대상" 섹션에서 찾을 수 있습니다.
백 엔드 서버에 로그인(Windows):
1. 해당 애플리케이션이 호스트되는 컴퓨터에 로그인합니다.
2. Win+R을 선택하거나, [시작] 단추를 마우스 오른쪽 단추로 클릭하고 [실행]을 선택합니다.
3. certlm.msc를 입력하고 Enter 키를 선택합니다. [시작] 메뉴에서 [인증서 관리자]를 검색할 수도 있습니다.
4. 인증서를 찾아서(일반적으로 Certificates - Local Computer\Personal\Certificates) 엽니다.
5. [세부 정보] 탭에서 인증서 주체를 확인합니다.
백 엔드 서버에 로깅(Linux): 올바른 인증서 파일 이름을 지정하여 이 OpenSSL 명령을 실행합니다( openssl x509 -in certificate.crt -subject -noout).

백 엔드 인증서가 만료됨

메시지: 백 엔드 인증서가 유효하지 않습니다. 현재 날짜는 인증서의 "유효 기간" 및 "유효 기간" 범위 내에 있지 않습니다.

원인: 만료된 인증서는 안전하지 않은 것으로 간주되므로 애플리케이션 게이트웨이는 만료된 인증서가 있는 백 엔드 서버를 비정상으로 표시합니다.

해결 방법: 솔루션은 백 엔드 서버에서 만료된 인증서 체인의 일부에 따라 달라집니다.

V2 SKU의 경우

만료된 리프(도메인 또는 서버라고도 함) 인증서 – 인증서 공급자를 통해 서버 인증서를 갱신하고 백 엔드 서버에 새 인증서를 설치합니다. 로 구성된 전체 인증서 체인을 설치해야 합니다 Leaf (topmost) > Intermediate(s) > Root. CA(인증 기관) 유형에 따라 게이트웨이에서 다음과 같은 작업을 수행할 수 있습니다.
- 공개적으로 알려진 CA: 인증서 발급자가 잘 알려진 CA인 경우 애플리케이션 게이트웨이에서 아무 작업도 수행할 필요가 없습니다.
- 비공개 CA: 비공개 CA에서 리프 인증서를 발급한 경우 서명 루트 CA 인증서가 변경되었는지 확인해야 합니다. 이러한 경우 새 루트 CA 인증서(.CER)를 게이트웨이의 연결된 백 엔드 설정에 업로드합니다.
만료된 중간 또는 루트 인증서 – 일반적으로 이러한 인증서의 유효 기간은 비교적 더 깁니다(10년 또는 2년). 루트/중간 인증서가 만료되면 인증서 공급자에게 갱신된 인증서 파일이 있는지 확인하는 것이 좋습니다. 백 엔드 서버에 구성된 이 업데이트되고 완전한 인증서 체인을 Leaf (topmost) > Intermediate(s) > Root 설치해야 합니다.
- 루트 인증서가 변경되지 않은 상태로 유지되거나 발급자가 잘 알려진 CA인 경우 애플리케이션 게이트웨이에서 아무 작업도 수행할 필요가 없습니다.
- 프라이빗 CA를 사용하는 경우 루트 CA 인증서 자체 또는 갱신된 중간 인증서의 루트가 변경되었다면 새 루트 인증서를 애플리케이션 게이트웨이의 백 엔드 설정에 업로드해야 합니다.

V1 SKU의 경우

만료된 리프(도메인 또는 서버라고도 함) 인증서를 CA로 갱신하고, 동일한 리프 인증서(.CER)를 애플리케이션 게이트웨이의 연결된 백 엔드 설정에 연결합니다.

중간 인증서를 찾을 수 없음

메시지: 백 엔드 서버가 제공한 인증서 체인에서 중간 인증서가 누락되었습니다. 인증서 체인이 완전하고 백 엔드 서버에서 올바르게 순서대로 정렬되었는지 확인합니다.

원인: 중간 인증서가 백 엔드 서버의 인증서 체인에 설치되어 있지 않습니다.

솔루션: 중간 인증서는 리프 인증서 서명에 사용되므로 체인을 완료하는 데 필요합니다. CA(인증 기관)에 필요한 중간 인증서를 확인하고 백 엔드 서버에 설치합니다. 이 체인은 리프 인증서, 중간 인증서, 마지막으로 루트 CA 인증서로 시작해야 합니다. 루트 CA 인증서를 포함하여 백 엔드 서버에 전체 체인을 설치하는 것이 좋습니다. 참고로 리프는 체인에서 가장 맨 위에 있어야 합니다.섹션의 인증서 체인 예제를 확인하세요.

참고 항목

인증 기관이 아닌 자체 서명된 인증서도 동일한 오류를 발생합니다. 애플리케이션 게이트웨이는 자체 서명된 인증서를 "리프" 인증서로 간주하고 서명 중간 인증서를 찾기 때문입니다. 이 문서에 따르면 자체 서명된 인증서를 올바르게 생성할 수 있습니다.

다음 이미지는 자체 서명된 인증서 간의 차이점을 보여 줍니다.

리프 인증서 또는 서버 인증서를 찾을 수 없음

메시지: 백 엔드 서버가 제공한 인증서 체인에서 리프 인증서가 누락되었습니다. 체인이 완전하고 백 엔드 서버에서 올바르게 순서대로 정렬되었는지 확인합니다.

원인: 리프(도메인 또는 서버라고도 함) 인증서가 백 엔드 서버의 인증서 체인에 누락되어 있습니다.

솔루션: CA(인증 기관)에서 리프 인증서를 가져오면 됩니다. 백 엔드 서버에 이 리프 인증서 및 모든 서명 인증서(중간 및 루트 CA 인증서)를 설치하세요. 이 체인은 리프 인증서, 중간 인증서, 마지막으로 루트 CA 인증서로 시작해야 합니다. 루트 CA 인증서를 포함하여 백 엔드 서버에 전체 체인을 설치하는 것이 좋습니다. 참고로 리프는 체인에서 가장 맨 위에 있어야 합니다.섹션의 인증서 체인 예제를 확인하세요.

공개적으로 알려진 CA에서 서버 인증서를 발급하지 않음

메시지: 백 엔드 서버 인증서 는 잘 알려진 CA(인증 기관)에서 서명되지 않습니다. 알 수 없는 CA 인증서를 사용하려면 해당 루트 인증서를 애플리케이션 게이트웨이의 백 엔드 설정에 업로드해야 합니다.

원인: 백 엔드 설정에서 "잘 알려진 CA 인증서"를 선택했지만 백 엔드 서버에서 제공하는 루트 인증서는 공개적으로 알려져 있지 않습니다.

솔루션: 비공개 CA(인증 기관)에서 리프 인증서를 발급한 경우, 서명 루트 CA의 인증서를 애플리케이션 게이트웨이의 연결된 백 엔드 설정에 업로드해야 합니다. 이렇게 하면 애플리케이션 게이트웨이가 해당 백 엔드 서버와 신뢰할 수 있는 연결을 설정할 수 있습니다. 이 문제를 해결하려면 연결된 백 엔드 설정으로 이동하여 "잘 알려진 CA가 아님"을 선택하고 루트 CA 인증서(.CER)를 업로드합니다. 루트 인증서를 식별하고 다운로드하려면 신뢰할 수 있는 루트 인증서 불일치에 설명된 것과 동일한 단계를 따를 수 있습니다.

공개적으로 알려진 CA에서 중간 인증서를 발급하지 않음

메시지: 중간 인증서는 잘 알려진 CA(인증 기관)에서 서명되지 않습니다. 인증서 체인이 완전하고 백 엔드 서버에서 올바르게 순서대로 정렬되었는지 확인합니다.

원인: 백 엔드 설정에서 "잘 알려진 CA 인증서"를 선택했지만 백 엔드 서버에서 제공하는 중간 인증서는 공개적으로 알려진 CA에서 서명되지 않습니다.

솔루션: 프라이빗 CA(인증 기관)에서 인증서를 발급한 경우 서명 루트 CA의 인증서를 애플리케이션 게이트웨이의 연결된 백 엔드 설정에 업로드해야 합니다. 이렇게 하면 애플리케이션 게이트웨이가 해당 백 엔드 서버와 신뢰할 수 있는 연결을 설정할 수 있습니다. 이 문제를 해결하려면 프라이빗 CA에 문의하여 적절한 루트 CA 인증서(.)를 가져옵니다. CER) 및 업로드합니다. "잘 알려진 CA 아님"을 선택하여 애플리케이션 게이트웨이의 백 엔드 설정에 대한 CER 파일입니다. 또한 쉽게 확인할 수 있도록 루트 CA 인증서를 포함하여 백 엔드 서버에 전체 체인을 설치하는 것이 좋습니다.

신뢰할 수 있는 루트 인증서 불일치(루트 인증서가 백 엔드 서버에 없음)

메시지: 애플리케이션 게이트웨이에 업로드된 루트 인증서로 서명되지 않은 중간 인증서입니다. 인증서 체인이 완전하고 백 엔드 서버에서 올바르게 순서대로 정렬되었는지 확인합니다.

원인: 연결된 백 엔드 설정에 업로드된 루트 CA 인증서가 백 엔드 서버에 설치된 중간 인증서에 서명하지 않았습니다. 백 엔드 서버에는 리프 및 중간 인증서만 설치되어 있습니다.

솔루션: 리프 인증서는 루트 CA 인증서로 서명된 중간 인증서로 서명됩니다. 프라이빗 인증 기관(CA)의 인증서를 사용하는 경우 해당 루트 CA 인증서를 애플리케이션 게이트웨이에 업로드해야 합니다. 프라이빗 CA에 문의하여 적절한 루트 CA 인증서(.CER)를 받고 해당 CER 파일을 애플리케이션 게이트웨이의 백 엔드 설정에 업로드합니다.

신뢰할 수 있는 루트 인증서 불일치(루트 인증서가 백 엔드 서버에서 제공됨)

메시지: 백 엔드에서 사용되는 서버 인증서의 루트 인증서가 Application Gateway에 추가된 신뢰할 수 있는 루트 인증서와 일치하지 않습니다. 올바른 루트 인증서를 추가하여 백 엔드를 허용합니다.

원인: 이 오류는 애플리케이션 게이트웨이의 백 엔드 설정에 업로드된 루트 인증서가 백 엔드 서버에 있는 루트 인증서와 일치하지 않는 경우에 발생합니다.

솔루션: 이는 비공개 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. 일반적으로 Certificates - Local Computer\Personal\Certificates에서 인증서를 찾아서 엽니다.
5. 루트 인증서를 선택한 다음 [인증서 보기]를 선택합니다.
6. [인증서] 속성에서 [세부 정보] 탭을 선택하고 "파일로 복사"를 클릭합니다.
7. [인증서 내보내기] 마법사에서 [다음]을 클릭합니다.
8. “Base-64로 인코딩된 X.509(.CER)”를 선택한 후 [다음]을 선택합니다.
9. 새 파일의 이름을 지정하고 [다음]을 클릭합니다.
10. [마침]을 클릭하여 .CER 파일을 을 가져옵니다.
11. 이 비공개 CA의 루트 인증서(.CER)를 애플리케이션 게이트웨이의 백 엔드 설정에 업로드합니다.

리프는 체인 맨 위에 있어야 합니다.

메시지: 리프 인증서는 백 엔드 서버에서 제공하는 체인의 최상위 인증서가 아닙니다. 인증서 체인이 백 엔드 서버에서 올바르게 순서대로 정렬되었는지 확인합니다.

원인: 리프(도메인 또는 서버라고도 함) 인증서가 백 엔드 서버에 올바른 순서로 설치되지 않았습니다.

솔루션: 백 엔드 서버에 인증서를 설치할 때에는 리프 인증서와 모든 서명 인증서(중간/루트 CA 인증서)로 구성된, 순서가 지정된 인증서 목록을 포함해야 합니다. 이 체인은 리프 인증서, 중간 인증서 그리고 마지막으로 루트 CA 인증서로 시작해야 합니다. 루트 CA 인증서를 포함하여 백 엔드 서버에 전체 체인을 설치하는 것이 좋습니다.

OpenSSL에서 깊이(0, 1, 2 등)로 표시되는 중간/루트 CA 인증서와 함께 서버 인증서 설치의 예제가 나와 있습니다. 다음 OpenSSL 명령을 사용하여 백 엔드 서버의 인증서에서 동일한 내용을 확인할 수 있습니다.
s_client -connect <FQDN>:443 -showcerts
또는
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

인증서 확인 실패

메시지: 백 엔드 인증서의 유효성을 확인할 수 없습니다. 이유를 확인하려면 오류 코드{errorCode}와 관련된 메시지에 대한 OpenSSL 진단을 확인합니다.

원인: 이 오류는 Application Gateway가 인증서의 유효성을 확인할 수 없는 경우에 발생합니다.

솔루션: 이 문제를 해결하려면 서버에서 인증서가 제대로 만들어졌는지 확인합니다. 예를 들어 OpenSSL을 사용하여 인증서 및 해당 속성을 확인한 다음 인증서를 Application Gateway HTTP 설정으로 다시 업로드할 수 있습니다.

백 엔드 상태: 알 수 없음

백 엔드 풀의 DNS 항목에 업데이트

메시지: 백 엔드 상태를 검색할 수 없습니다. 이 문제는 애플리케이션 게이트웨이 서브넷의 NSG/UDR/방화벽이 v1 SKU의 경우 포트 65503-65534에서 트래픽을 차단하고 v2 SKU의 경우 포트 65200-65535 또는 백 엔드 풀에 구성된 FQDN을 IP 주소로 확인될 수 없는 경우에 발생합니다. 자세히 알아보려면 https://aka.ms/UnknownBackendHealth를 방문하세요.

원인: FQDN(정규화된 도메인 이름) 기반 백 엔드 대상의 경우 Application Gateway가 후속 DNS 조회에 대한 응답을 가져오지 못하면 마지막으로 알려진 정상 IP 주소를 캐시하고 사용합니다. 이 상태의 게이트웨이에 대한 PUT 작업은 DNS 캐시를 모두 삭제합니다. 따라서 게이트웨이가 연결할 수 있는 대상 주소는 없습니다.

해결 방법: DNS 서버를 확인하고 수정하여 지정된 FDQN의 DNS 조회에 대한 응답을 제공하고 있는지 확인합니다. 또한 애플리케이션 게이트웨이의 Virtual Network를 통해 DNS 서버에 연결할 수 있는지 확인해야 합니다.

기타 이유

백 엔드 상태가 알 수 없음으로 표시되는 경우 포털 보기는 다음 스크린샷과 유사합니다.

Application Gateway 백 엔드 상태 - 알 수 없음

다음 이유 중 하나 이상으로 인해 이 동작이 발생할 수 있습니다.

Application Gateway 서브넷의 NSG가 "인터넷"에서 65503-65534(v1 SKU) 또는 65200-65535(v2 SKU) 포트에 대한 인바운드 액세스를 차단하고 있습니다.
Application Gateway 서브넷의 UDR은 기본 경로(0.0.0.0/0)로 설정되고 다음 홉은 "인터넷"으로 지정되지 않습니다.
기본 경로는 BGP를 통한 가상 네트워크에 대한 ExpressRoute/VPN 연결에 의해 보급됩니다.
사용자 지정 DNS 서버가 공용 도메인 이름을 확인할 수 없는 가상 네트워크에 구성되어 있습니다.
Application Gateway는 비정상 상태입니다.

해결 방법:

NSG가 인터넷에서 65503-65534(v1 SKU) 또는 65200-65535(v2 SKU) 포트에 대한 액세스를 차단하는지 여부를 확인합니다.

a. Application Gateway 개요 탭에서 가상 네트워크/서브넷 링크를 선택합니다. b. 가상 네트워크의 서브넷 탭에서 Application Gateway가 배포되는 서브넷을 선택합니다. c. NSG가 구성되어 있는지 여부를 확인합니다. d. NSG가 구성된 경우 검색 탭 또는 모든 리소스에서 해당 NSG 리소스를 검색합니다. e. 인바운드 규칙 섹션에서 원본이 GatewayManager 서비스 태그로 설정된 65503-65534 v1 SKU 또는 65200-65535 v2 SKU에 대한 대상 포트 범위를 허용하는 인바운드 규칙을 추가합니다. f. 저장을 선택하고 백 엔드를 정상으로 볼 수 있는지 확인합니다. 또는 PowerShell/CLI를 통해 수행할 수 있습니다.
UDR에 다음 홉이 인터넷으로 설정되지 않은 기본 경로(0.0.0.0/0)가 있는지 여부를 확인합니다.

a. 1a 및 1b 단계를 수행하여 서브넷을 결정합니다. b. UDR이 구성되어 있는지 확인합니다. 있는 경우 검색 창에서 또는 모든 리소스 에서 리소스를 검색합니다. c. 다음 홉이 인터넷으로 설정되지 않은 기본 경로(0.0.0.0/0)가 있는지 확인합니다. 설정이 가상 어플라이언스 또는 가상 네트워크 게이트웨이인 경우에는 가상 어플라이언스 또는 온-프레미스 디바이스에서 패킷을 수정하지 않고 다시 인터넷 대상으로 패킷을 올바르게 라우팅할 수 있는지 확인해야 합니다. 프로브가 가상 어플라이언스를 통해 라우팅되고 수정되면 백 엔드 리소스에 200 상태 코드가 표시되고 Application Gateway 상태가 알 수 없음으로 표시될 수 있습니다. 이는 오류를 나타내지 않습니다. 트래픽은 여전히 문제 없이 Application Gateway를 통해 라우팅되어야 합니다. d. 그렇지 않으면 다음 홉을 인터넷으로 변경하고 저장을 선택하고 백 엔드 상태를 확인합니다.
BGP(Border Gateway Protocol)를 통해 가상 네트워크에 대한 ExpressRoute/VPN 연결에 의해 보급되는 기본 경로:

a. BGP를 통해 가상 네트워크에 대한 ExpressRoute/VPN 연결이 있는 경우 및 기본 경로를 보급하는 경우에는 패킷을 수정하지 않고 인터넷 대상으로 다시 라우팅해야 합니다. Application Gateway 포털에서 연결 문제 해결 옵션을 사용하여 확인할 수 있습니다. b. 1.1.1.1과 같은 인터넷 라우팅 가능한 IP 주소로 대상을 수동으로 선택합니다. 대상 포트를 모든 항목으로 설정하고 연결을 확인합니다. c. 다음 홉이 가상 네트워크 게이트웨이인 경우 ExpressRoute 또는 VPN을 통해 보급된 기본 경로가 있을 수 있습니다.
가상 네트워크에 구성된 사용자 지정 DNS 서버가 있으면 서버에서 공용 도메인을 확인할 수 있는지 확인합니다. Application Gateway가 OCSP(온라인 인증서 상태 프로토콜) 서버와 같은 외부 도메인에 연결하거나 인증서의 해지 상태를 확인해야 하는 시나리오에서는 공용 도메인 이름 확인이 필요할 수 있습니다.
Application Gateway가 정상 상태이고 실행 중인지 확인하려면 포털에서 Resource Health 옵션으로 이동하여 상태가 정상인지 확인합니다. 비정상 또는 저하 상태가 표시되는 경우 고객 지원팀에 문의하세요.
인터넷 및 프라이빗 트래픽이 보안 가상 허브에서 호스트되는 Azure Firewall을 통과하는 경우(Azure Virtual WAN Hub 사용):

a. 애플리케이션 게이트웨이가 트래픽을 인터넷에 직접 보낼 수 있도록 하려면 다음 사용자 정의 경로를 구성합니다.

주소 접두사: 0.0.0.0/0
다음 홉: 인터넷

b. 애플리케이션 게이트웨이가 Virtual WAN 허브의 Azure Firewall을 통해 백엔드 풀로 트래픽을 전송하게 하려면 다음 사용자 정의 경로를 구성합니다.

주소 접두사: 백엔드 풀 서브넷
다음 홉: Azure Firewall 프라이빗 IP 주소

참고 항목

애플리케이션 게이트웨이가 CRL 엔드포인트에 액세스할 수 없는 경우 백 엔드 상태를 "알 수 없음"으로 표시할 수 있습니다. 이러한 문제를 방지하려면 애플리케이션 게이트웨이 서브넷이 액세스할 crl.microsoft.com crl3.digicert.com수 있는지 확인하고 . 이 작업은 CRL 엔드포인트로 트래픽을 보내도록 네트워크 보안 그룹을 구성하여 수행할 수 있습니다.

다음 단계

Application Gateway 진단 및 로깅에 대해 자세히 알아보세요.

다음을 통해 공유

Application Gateway의 백 엔드 상태 문제 해결

개요

백 엔드 상태를 확인하는 방법

백 엔드 상태: 비정상

오류 메시지

백 엔드 서버 시간 초과

DNS 확인 오류

TCP 연결 오류

HTTP 상태 코드 불일치

HTTP 응답 본문 불일치

CN(일반 이름)이 일치하지 않음

백 엔드 인증서가 만료됨

중간 인증서를 찾을 수 없음

리프 인증서 또는 서버 인증서를 찾을 수 없음

공개적으로 알려진 CA에서 서버 인증서를 발급하지 않음

공개적으로 알려진 CA에서 중간 인증서를 발급하지 않음

신뢰할 수 있는 루트 인증서 불일치(루트 인증서가 백 엔드 서버에 없음)

신뢰할 수 있는 루트 인증서 불일치(루트 인증서가 백 엔드 서버에서 제공됨)

리프는 체인 맨 위에 있어야 합니다.

인증서 확인 실패

백 엔드 상태: 알 수 없음

백 엔드 풀의 DNS 항목에 업데이트

기타 이유

다음 단계

피드백

추가 리소스