Application Gateway 수신기 구성
참고 항목
Azure Az PowerShell 모듈을 사용하여 Azure와 상호 작용하는 것이 좋습니다. 시작하려면 Azure PowerShell 설치를 참조하세요. Az PowerShell 모듈로 마이그레이션하는 방법에 대한 자세한 내용은 Azure PowerShell을 AzureRM에서 Azure로 마이그레이션을 참조하세요.
수신기는 포트, 프로토콜, 호스트, IP 주소를 사용하여 들어오는 연결 요청을 확인하는 논리적 엔터티입니다. 수신기를 구성하는 경우 게이트웨이에 들어오는 요청의 해당 값과 일치하는 설정 값을 입력해야 합니다.
Azure Portal을 사용하여 애플리케이션 게이트웨이를 만들 때 수신기의 프로토콜 및 포트를 선택하여 기본 수신기도 만듭니다. 수신기에서 HTTP2 지원을 사용할지 여부를 선택할 수 있습니다. 애플리케이션 게이트웨이를 만든 후 기본 수신기(appGatewayHttpListener)의 설정을 편집하거나 새 수신기를 만들 수 있습니다.
수신기 유형
새 수신기를 만들 때 기본과 다중 사이트 중에서 선택할 수 있습니다.
모든 도메인에 대한 모든 요청을 허용하여 백 엔드 풀에 전달하려는 경우 기본을 선택합니다. 기본 수신기로 애플리케이션 게이트웨이를 만드는 방법을 알아봅니다.
호스트 헤더 또는 호스트 이름을 기반으로 요청을 다른 백 엔드 풀로 전달하려면 다중 사이트 수신기를 선택합니다. Application Gateway는 HTTP 1.1 호스트 헤더를 기반으로 동일한 공용 IP 주소 및 포트에서 둘 이상의 웹 사이트를 호스트합니다. 동일한 포트에서 요청을 구분하려면 수신되는 요청과 일치하는 호스트 이름을 지정해야 합니다. 자세한 내용은 Application Gateway를 사용하여 여러 사이트 호스팅을 참조하세요.
수신기 처리 순서
v1 SKU의 경우 요청은 규칙의 순서와 수신기의 유형에 일치하게 됩니다. 기본 수신기를 사용하는 규칙이 순서 첫 번째인 경우 이는 먼저 처리되며 해당 포트 및 IP 조합에 대한 모든 요청을 허용합니다. 이를 방지하려면 다중 사이트 수신기를 사용하는 규칙을 첫 번째로 구성하고 기본 수신기를 사용하는 규칙을 목록의 마지막으로 푸시합니다.
v2 SKU의 경우 규칙 우선 순위가 정의되지 않는 한 다중 사이트 수신기는 기본 수신기 전에 처리됩니다. 규칙 우선 순위를 사용하는 경우 와일드카드 수신기는 와일드카드가 아닌 수신기가 와일드카드 수신기보다 먼저 실행되도록 와일드카드 수신기가 아닌 수신기보다 큰 숫자로 우선 순위를 정의해야 합니다.
프런트 엔드 IP 주소
이 수신기와 연결하려는 프런트 엔드 IP 주소를 선택합니다. 수신기는 이 IP에서 들어오는 요청을 수신 대기합니다.
참고 항목
Application Gateway 프런트 엔드는 이중 스택 IP 주소를 지원합니다. 최대 4개의 프런트 엔드 IP 주소, 즉 IPv4 주소 2개(퍼블릭, 프라이빗)와 IPv6 주소 2개(퍼블릭, 프라이빗)를 만들 수 있습니다.
프런트 엔드 포트
프런트 엔드 포트를 연결합니다. 기존 포트를 선택하거나 새 포트를 만듭니다. 허용되는 포트 범위에서 값을 선택합니다. 잘 알려진 포트(예: 80 및 443)뿐만 아니라 허용되는 모든 적합한 사용자 지정 포트를 사용할 수 있습니다. 퍼블릭/프라이빗 수신기에 동일한 포트를 사용할 수 있습니다.
참고 항목
동일한 포트 번호로 프라이빗 및 퍼블릭 수신기를 사용하는 경우 애플리케이션 게이트웨이는 인바운드 흐름의 "대상"을 게이트웨이의 프런트 엔드 IP로 변경합니다. 따라서 네트워크 보안 그룹의 구성에 따라 애플리케이션 게이트웨이의 퍼블릭 및 프라이빗 프런트 엔드 IP로 대상 IP 주소를 사용하는 인바운드 규칙이 필요할 수 있습니다.
인바운드 규칙:
- 원본: (요구 사항에 따라)
- 대상 IP 주소: 애플리케이션 게이트웨이의 퍼블릭 및 프라이빗 프런트 엔드 IP입니다.
- 대상 포트: (수신기 구성에 따라)
- 프로토콜: TCP
아웃바운드 규칙: (특정 요구 사항 없음)
프로토콜
HTTP 또는 HTTPS 선택:
HTTP를 선택하면 클라이언트와 애플리케이션 게이트웨이 간의 트래픽이 암호화되지 않습니다.
TLS 종료 또는 엔드투엔드 TLS 암호화를 원하는 경우 HTTPS를 선택합니다. 클라이언트와 애플리케이션 게이트웨이 간의 트래픽이 암호화되고 TLS 연결이 애플리케이션 게이트웨이에서 종료됩니다. 백 엔드 대상에 대한 엔드투엔드 TLS 암호화를 원하는 경우 백 엔드 HTTP 설정 내에서도 HTTPS를 선택해야 합니다. 그러면 애플리케이션 게이트웨이가 백 엔드 대상에 대한 연결을 시작할 때 트래픽이 암호화됩니다.
TLS 종료를 구성하려면 수신기에 TLS/SSL 인증서를 추가해야 합니다. 이를 통해 Application Gateway는 들어오는 트래픽을 해독하고 클라이언트에 대한 응답 트래픽을 암호화할 수 있습니다. Application Gateway에 제공된 인증서는 프라이빗 키와 공개 키를 모두 포함하는 PFX(개인 정보 교환) 형식이어야 합니다.
참고 항목
수신기에 Key Vault의 TLS 인증서를 사용하는 경우 Application Gateway가 연결된 키 자격 증명 모음 리소스 및 그 안에 있는 인증서 개체에 항상 액세스할 수 있는지 확인해야 합니다. 이렇게 하면 TLS 종료 기능을 원활하게 작업할 수 있으며 게이트웨이 리소스의 전반적인 상태를 유지 관리합니다. 애플리케이션 게이트웨이 리소스가 잘못 구성된 키 자격 증명 모음을 검색하면 연결된 HTTPS 수신기가 비활성화된 상태로 자동으로 배치됩니다. 자세히 알아보기.
지원되는 인증서
Application Gateway를 사용한 TLS 종료 및 엔드투엔드 TLS 개요를 참조하세요.
추가 프로토콜 지원
HTTP2 지원
HTTP/2 프로토콜 지원은 애플리케이션 게이트웨이 수신기에만 연결하는 클라이언트에서 사용할 수 있습니다. 백 엔드 서버 풀에 대한 통신은 항상 HTTP/1.1을 통해 이루어집니다. 기본적으로 HTTP/2 지원은 사용할 수 없습니다. 다음 Azure PowerShell 코드 조각은 이를 사용하도록 설정하는 방법을 보여 줍니다.
$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm
$gw.EnableHttp2 = $true
Set-AzApplicationGateway -ApplicationGateway $gw
또한 Application Gateway > 구성의 HTTP2에서 사용을 선택하여 Azure Portal을 통해 HTTP2 지원을 사용할 수 있습니다.
WebSocket 지원
WebSocket 지원은 기본적으로 사용하도록 설정되어 있습니다. 사용하도록 설정 또는 사용하지 않도록 설정하기 위해 사용자가 구성할 수 있는 설정이 없습니다. HTTP 및 HTTPS 수신기 모두에서 WebSocket을 사용할 수 있습니다.
사용자 지정 오류 페이지
Application Gateway에서 반환하는 다양한 응답 코드에 사용자 지정된 오류 페이지를 정의할 수 있습니다. 오류 페이지를 구성할 수 있는 응답 코드는 400, 403, 405, 408, 500, 502, 503, 504입니다. 전역 수준 또는 수신기별 오류 페이지 구성을 사용하여 각 수신기에 맞게 세부적으로 설정할 수 있습니다. 자세한 내용은 Application Gateway 사용자 지정 오류 페이지 만들기를 참조하세요.
참고 항목
백 엔드 서버에서 발생하는 오류는 Application Gateway에서 수정되지 않은 상태로 클라이언트에 전달됩니다.
TLS 정책
TLS/SSL 인증서 관리를 중앙 집중화하고 백 엔드 서버 팜에 대한 암호화-암호 해독 오버헤드를 줄일 수 있습니다. 중앙 집중식 TLS 처리를 통해 보안 요구 사항에 적합한 중앙 TLS 정책을 지정할 수도 있습니다. 기본 또는 사용자 지정 TLS 정책을 선택할 수 있습니다.
TLS 프로토콜 버전을 제어하는 TLS 정책을 구성합니다. TLS1.0, TLS1.1, TLS1.2 및 TLS1.3의 TLS 핸드셰이크에 최소 프로토콜 버전을 사용하도록 애플리케이션 게이트웨이를 구성할 수 있습니다. SSL 2.0 및 3.0은 기본적으로 사용하지 않도록 설정되며 구성할 수 없습니다. 자세한 내용은 Application Gateway TLS 정책 개요를 참조하세요.
수신기를 만든 후에는 요청 라우팅 규칙과 연결합니다. 이 규칙은 수신기에서 수신된 요청이 백 엔드로 라우팅되는 방법을 결정합니다.