NGINX Plus R28 발표

Robert Haynes기술 마케팅 매니저

NGINX Plus 릴리스 28(R28)이 출시되었음을 기쁘게 알려드립니다. NGINX Open Source를 기반으로 하는 NGINX Plus는 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 API 게이트웨이 기능을 모두 갖춘 유일한 통합 소프트웨어입니다.

NGINX Plus R28의 새로운 기능과 향상된 기능은 다음과 같습니다:

• 추가 TLS 메트릭 – NGINX Plus R28은 시스템 전체, 클라이언트 측 및 서버 측 수준에서 추가 TLS 통계를 수집하여 프록시 구성과 클라이언트 및 업스트림 서버 연결에서 발생하는 SSL/TLS 관련 오류를 해결하는 데 중요한 정보를 제공합니다. NGINX Plus 실시간 활동 모니터링 대시보드도 새로운 SSL 세션 데이터를 표시하도록 업데이트되었습니다.
• 클라우드 프라이빗 서비스의 PROXY 프로토콜 v2 TLV 지원 – AWS, Google Cloud Platform 및 Microsoft Azure에서 ‘프라이빗 서비스’를 통해 외부 클라이언트가 리소스를 사용할 수 있도록 설정할 경우, 기본적으로 PROXY 프로토콜 v2 헤더의 TLV(type-length-value) 벡터로 표현되는 서비스별 클라이언트 식별자는 백엔드 서비스로 전달되지 않습니다. NGINX Plus R28에는 TLV를 디코딩하고 클라이언트 식별자를 백엔드 서비스로 전달하기 위한 변수를 정의하는 http 및 stream 컨텍스트용 모듈이 도입되었습니다.
• 고정 쿠키의 samesite 매개변수에 대한 변수 지원 – NGINX Plus R28에서는 sticky cookie 지시문의 samesite 매개변수 값으로 변수를 사용할 수 있습니다. 이 개선 사항을 통해 트래픽을 더 쉽게 관리하고 보안을 강화할 수 있습니다.

이번 릴리스에는 NGINX Open Source에서 이어받은 새로운 기능과 버그 수정 사항, 그리고 NGINX JavaScript 모듈 업데이트도 포함됩니다.

중요한 동작 변경 사항

참고: NGINX Plus R27 이외의 릴리스에서 업그레이드하는 경우, 현재 사용 중인 릴리스부터 이번 릴리스까지의 모든 릴리스 발표 블로그에서 중요한 동작 변경 사항 섹션을 반드시 확인하세요.

플랫폼 지원 변경 사항

새롭게 지원되는 운영 체제 및 아키텍처:

• AlmaLinux 8 및 9(x86_64, aarch64)
• Alpine 3.17 (x86_64, arm64)
• Oracle Linux 9 (x86_64)
• Rocky Linux 8 및 9(x86_64, aarch64)

이전 운영 체제 지원 종료:

• 2022년 8월에 지원 종료(EOL)된 Debian 10

지원 중단이 예정되어 있으며 NGINX Plus R29에서 제거될 이전 운영 체제 및 아키텍처:

• 2022년 11월 1일에 지원이 종료된 Alpine 3.13

이름이 동일한 여러 헤더의 처리 방식 변경

• 이제 알려진 중복 업스트림 응답 헤더는 대부분 경고와 함께 무시됩니다.
• 중복된 Content-Length 및 Transfer-Encoding 헤더뿐만 아니라, 유효하지 않은 Content-Length 또는 Transfer-Encoding 헤더가 포함된 응답이나 Content-Length와 Transfer-Encoding가 모두 포함된 응답도 이제 거부됩니다.

새로운 기능 상세

추가 TLS 메트릭

프록시 구성, 업스트림 서버 및 클라이언트와 관련된 TLS 문제를 해결할 때는 SSL/TLS 이벤트와 오류를 관찰할 수 있어야 합니다. NGINX Plus API가 NGINX Plus R13에 도입된 이후 NGINX Plus는 시스템 전체 수준에서 세 가지 TLS 메트릭을 수집해 왔습니다:

• handshakes – 성공한 SSL 핸드셰이크 수
• handshakes_failed – SSL 핸드셰이크 실패 횟수(SSL 핸드셰이크 후에 발생하는 인증서 검증 실패는 포함되지 않음)
• session_reuses – SSL 세션 재사용 횟수

In NGINX Plus R27<.htmla> 이상에서는 개별 업스트림 서버와 가상 서버에 대해 세 가지 메트릭을 수집하도록 구성할 수 있습니다.

NGINX Plus R28에서는 HTTP 및 Stream 모듈 모두에 핸드셰이크 오류와 인증서 검증 실패를 위한 새로운 카운터가 추가되어 TLS 메트릭 세트가 확장되었습니다(여기서는 HTTP 모듈의 예만 제공하지만, 사용 가능한 Stream 메트릭도 유사합니다). 개별 업스트림 서버 및 가상 서버의 메트릭 수집 구성에 대한 자세한 내용은 NGINX Plus R27<.htmlspan> 발표 블로그를 참조하세요.

핸드셰이크 오류

다음 핸드셰이크 오류에 대한 카운터가 NGINX Plus R28에 새로 추가되었습니다:

• handshake_timeout – 핸드셰이크 시간 초과로 인한 핸드셰이크 실패 횟수
• no_common_cipher – 핸드셰이크 당사자 간에 공통 암호화 방식이 없어 발생한 핸드셰이크 실패 횟수(업스트림 서버 연결에는 해당되지 않으므로 수집되지 않음)
• no_common_protocol – 당사자 간 공통 프로토콜이 없어 발생한 핸드셰이크 실패 횟수
• peer_rejected_cert – 상대방이 NGINX Plus에서 제시한 인증서를 거부하고 적절한 경고 메시지를 제공하여 발생한 핸드셰이크 실패 횟수

인증서 검증 실패

인증서 검증을 구성하면 인증서 검증 실패가 이제 API 출력의 새로운 verify_failures 섹션에 보고됩니다:

• 클라이언트 연결에 ssl_verify_client[HTTP][Stream] 지시어를 사용하는 경우
• 다음과 같은 프로토콜별 지시문을 사용하는 서버 연결의 경우:
  • grpc_ssl_verify
  • proxy_ssl_verify[HTTP][스트림]
  • uwsgi_ssl_verify

인증서 검증에 실패하면 해당 원인에 대한 메트릭이 증가하고 연결이 종료됩니다. 단, 이러한 실패는 핸드셰이크가 성공한 후에 발생하므로 기본 handshakes 카운터는 여전히 증가합니다.

인증서 검증 실패에 대한 메트릭은 다음과 같습니다:

• expired_cert – 피어가 만료된 인증서를 제시함
• hostname_mismatch – 서버의 인증서가 호스트 이름과 일치하지 않음(클라이언트 연결의 경우 수집되지 않음)
• no_cert – 클라이언트가 필수 인증서를 제공하지 않음(업스트림 서버 연결에서는 수집되지 않음)
• revoked_cert – 피어가 해지된 인증서를 제시함
• other – 기타 인증서 검증 실패를 명시적으로 집계하는 카운터

메트릭 출력 예시

다음은 시스템 전체 수준의 HTTP 연결에 대한 TLS 메트릭 예시입니다:

$ curl 127.0.0.1:8080/api/8/ssl{    "handshakes": 32,    "session_reuses": 0,    "handshakes_failed": 8,    "no_common_protocol": 4,    "no_common_cipher": 2,    "handshake_timeout": 0,    "peer_rejected_cert": 0,    "verify_failures": {        "no_cert": 0,        "expired_cert": 2,        "revoked_cert": 1,        "hostname_mismatch": 2,        "other": 1    }}

다음은 클라이언트와 HTTP 가상 서버 s9 간 연결에 대한 샘플 메트릭입니다(앞서 언급했듯이 이러한 연결에서는 hostname_mismatch 카운터가 수집되지 않습니다):

$ curl 127.0.0.1:8080/api/8/http/server_zones/s9{    ...    "ssl": {        "handshakes": 0,        "session_reuses": 0,        "handshakes_failed": 1,        "no_common_protocol": 0,        "no_common_cipher": 1,        "handshake_timeout": 0,        "peer_rejected_cert": 0,        "verify_failures": {            "no_cert": 0,            "expired_cert": 0,            "revoked_cert": 0,            "other": 0        }    }    ...}

다음은 u2 업스트림 그룹의 서버에 대한 HTTP 연결의 샘플 메트릭입니다(앞서 언급했듯이 이러한 연결에서는 no_cert 및 no_common_cipher 카운터가 수집되지 않습니다):

$ curl 127.0.0.1:8080/api/8/http/upstreams/u2{    "peers": [        {            "id": 0,            "server": "127.0.0.1:8082",            "name": "127.0.0.1:8082",            ...            "ssl": {                "handshakes": 1,                "session_reuses": 0,                "handshakes_failed": 0,                "no_common_protocol": 0,                "handshake_timeout": 0,                "peer_rejected_cert": 0,                "verify_failures": {                    "expired_cert": 1,                    "revoked_cert": 0,                    "hostname_mismatch": 0,                    "other": 0                }            },            ...        }    ],}

NGINX Plus 대시보드에 확장된 TLS 메트릭 표시

NGINX Plus R28 이상에서는 실시간 활동 모니터링 대시보드에 위에서 설명한 새로운 TLS 메트릭이 표시됩니다. 이 스크린샷은 클라이언트 연결에 대한 메트릭을 보여 줍니다. 새로운 메트릭을 보려면 그림과 같이 SSL > 핸드셰이크 실패 열의 값 위에 마우스 포인터를 올려놓으십시오.

Cloud Private Services에서 PROXY Protocol v2 TLV 지원

3대 주요 클라우드 제공업체인 Amazon Web Services(AWS), Google Cloud Platform(GCP), Microsoft Azure는 각각 서비스를 공용 인터넷에 노출하지 않고도 외부 클라이언트가 서비스에 액세스할 수 있도록 하는 ‘프라이빗 서비스’를 제공합니다. 각 서비스는 PROXY 프로토콜 v2 헤더의 유형-길이-값(TLV) 벡터로 표현되는 클라이언트 식별자를 사용합니다. 서비스별 식별자는 다음과 같습니다.

• AWS PrivateLink – PP2_SUBTYPE_AWS_VPCE_ID
• GCP 비공개 서비스 연결 – pscConnectionId
• Microsoft Azure Private Link – PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID

기본적으로 이러한 클라이언트 식별자는 백엔드 서비스에 전달되지 않습니다. NGINX Plus R28에는 http 및 stream 컨텍스트용 모듈인 ngx_http_proxy_protocol_vendor_module 및 ngx_stream_proxy_protocol_vendor_module이 도입되었습니다. 이 모듈은 TLV를 디코딩하고 식별자를 백엔드 서비스로 전달하기 위한 변수를 정의합니다.

NGINX Plus가 PROXY 프로토콜을 사용하여 클라이언트의 IP 주소 및 기타 정보를 가져오는 방법에 대한 일반적인 내용은 NGINX Plus 관리 가이드의 PROXY 프로토콜 수락을 참조하세요.

AWS용 PROXY 프로토콜 v2 지원

AWS에서 Virtual Private Cloud(VPC) 엔드포인트 서비스를 통해 클라이언트에서 유입되는 트래픽의 소스 IP 주소는 Network Load Balancer 노드의 프라이빗 IP 주소입니다. 백엔드 애플리케이션에 클라이언트의 실제 IP 주소와 기타 식별자가 필요한 경우 PROXY 프로토콜 v2 헤더에서 이를 가져올 수 있습니다.

AWS에서는 사용자 지정 TLV 벡터가 엔드포인트의 VPC ID를 PROXY 프로토콜 v2 헤더 PP2_SUBTYPE_AWS_VPCE_ID에 인코딩합니다. (자세한 내용은 AWS 설명서를 참조하세요.)

NGINX Plus R28은 TLV를 디코딩하고 엔드포인트 ID를 백엔드 애플리케이션에 $proxy_protocol_tlv_aws_vpce_id 변수로 전달합니다.

참고: server 블록에서 $proxy_protocol_tlv_aws_vpce_id 변수를 참조하는 경우, listen[HTTP][Stream] 지시문에 proxy_protocol 매개변수도 포함해야 합니다. 예시는 바로 아래의 proxy_protocol_v2.conf 파일에서 8번째 줄을 참조하세요.

이 AWS용 샘플 구성은 VPC ID가 허용되는지 확인하고, 허용되는 경우 이를 add_header 지시문의 두 번째 매개변수로 백엔드 애플리케이션에 전달합니다.

코드 예제를 로드하는 중…

GCP용 PROXY 프로토콜 v2 지원

GCP Private Service Connect에서 클라이언트로부터 들어오는 트래픽의 소스 IP 주소는 “서비스 프로듀서의 VPC 네트워크에 있는 Private Service Connect 서브넷 중 하나의 주소”입니다. 백엔드 애플리케이션에 클라이언트의 실제 IP 주소와 기타 식별자가 필요한 경우 PROXY 프로토콜 v2 헤더에서 이를 가져올 수 있습니다.

GCP에서는 사용자 지정 TLV 벡터가 PROXY 프로토콜 v2 헤더의 고유한(당시 기준) 연결 ID인 pscConnectionId를 인코딩합니다. (자세한 내용은 GCP 문서를 참조하세요.)

NGINX Plus R28은 TLV를 디코딩하고 pscConnectionId 값을 $proxy_protocol_tlv_gcp_conn_id 변수에 담아 백엔드 애플리케이션에 전달합니다.

참고: server 블록에서 $proxy_protocol_tlv_gcp_conn_id 변수를 참조하는 경우, listen[HTTP][Stream] 지시문에 proxy_protocol 매개변수도 포함해야 합니다. 예시는 위의 proxy_protocol_v2.conf 파일에서 8번째 줄을 참조하세요.

Microsoft Azure용 PROXY 프로토콜 v2 지원

Microsoft Azure Private Link에서 클라이언트로부터 유입되는 트래픽의 원본 IP 주소는 “공급자의 가상 네트워크에서 할당된 NAT IP [주소]를 사용하여 서비스 공급자 측에서 네트워크 주소 변환(NAT)된 주소”입니다. 백엔드 애플리케이션에 클라이언트의 실제 IP 주소와 기타 식별자가 필요한 경우 PROXY 프로토콜 v2 헤더에서 이를 가져올 수 있습니다.

Azure에서는 사용자 지정 TLV 벡터가 PROXY 프로토콜 v2 헤더의 클라이언트 LinkID를 인코딩합니다. PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID 자세한 내용은 Azure 설명서를 참조하세요.

NGINX Plus R28은 TLV를 디코딩하고 $proxy_protocol_tlv_azure_pel_id 변수를 통해 LinkID를 백엔드 애플리케이션에 전달합니다.

참고: server 블록에서 $proxy_protocol_tlv_azure_pel_id 변수를 참조하는 경우, listen[HTTP][Stream] 지시문에 proxy_protocol 매개변수도 포함해야 합니다. 예시는 위의 proxy_protocol_v2.conf 파일에서 8번째 줄을 참조하세요.

고정 쿠키 samesite 매개변수의 변수 지원

이전 NGINX Plus 릴리스에서는 세 가지 정적 값(strict, lax, none)을 samesite 매개변수의 값으로 sticky cookie 지시문에 사용할 수 있었습니다. NGINX Plus R28부터는 변수도 값으로 사용할 수 있습니다.

기본적으로(samesite 매개변수가 없는 경우) NGINX는 쿠키에 SameSite 속성을 삽입하지 않습니다. samesite 매개변수가 변수인 경우 결과는 런타임에 변수가 어떤 값으로 해석되는지에 따라 달라집니다:

• 표준값 중 하나로 확인되는 경우(strict, lax, none) – NGINX는 해당 값으로 설정된 SameSite 속성을 삽입합니다
• 빈 값("")으로 설정하면 NGINX는 SameSite 속성을 삽입하지 않습니다.
• 잘못된 구성을 나타내는 그 밖의 값으로 설정하면 NGINX는 SameSite 속성을 Strict(가장 안전한 설정)로 설정하여 삽입합니다.

이 샘플 구성은 HTTP samesite 헤더의 값에 따라 User-Agent 특성을 설정합니다(SameSite 특성을 지원하지 않는 레거시 클라이언트에 유용함):

코드 예제를 로드하는 중…

NGINX Plus R28의 기타 개선 사항

NGINX Open Source에서 상속된 변경 사항

NGINX Plus R28은 NGINX Open Source 1.23.2를 기반으로 하며, NGINX Plus R27 출시 이후(NGINX 1.23.0부터 1.23.2까지) 적용된 기능 변경 사항과 버그 수정을 상속합니다. 변경 사항 및 버그 수정은 다음과 같습니다:

• 새로운 ipv4=off 매개변수를 HTTP resolver 지시어에 지정하면 IPv4 주소 조회가 비활성화됩니다.
• HTTP 세션 정보에 대한 공유 캐시를 활성화하기 위해 shared 매개변수를 ssl_session_cache 지시문에 지정하면 이제 TLS 세션 티켓 키가 자동으로 교체됩니다.
• 여러 유형의 TLS/SSL 오류가 기록되는 심각도 수준이 crit에서 info로 낮아졌습니다.

이 릴리스에서 상속된 새로운 기능, 변경 사항 및 버그 수정의 전체 목록은 CHANGES 파일을 참조하세요.

NGINX JavaScript 모듈 변경 사항

NGINX Plus R28에는 NGINX JavaScript 모듈(njs) 버전 0.7.5부터 0.7.8까지 적용된 변경 사항과 수정 사항이 포함되어 있습니다. 그중 가장 중요한 몇 가지 사항은 블로그의 njs 0.7.7로 NGINX 구성을 더욱 모듈화하고 재사용 가능하게 만들기에서 자세히 소개합니다. 전체 목록은 변경 사항 파일을 참조하세요.

NGINX Plus 업그레이드 또는 체험

NGINX Plus를 실행 중이라면 가능한 한 빨리 NGINX Plus R28로 업그레이드하시기를 강력히 권장합니다. 업그레이드하면 여러 추가 수정 사항과 개선 사항도 적용되며, 지원 티켓을 제출해야 할 때 NGINX가 더 원활하게 지원하는 데 도움이 됩니다.

아직 NGINX Plus를 사용해 보지 않으셨다면 보안, 부하 분산, API 게이트웨이 용도로, 또는 향상된 모니터링 및 관리 API를 갖춘 완전한 기술 지원이 제공되는 웹 서버로 사용해 보시기 바랍니다. 지금 바로 30일 무료 평가판으로 시작할 수 있습니다.

작성자 소개

Robert Haynes기술 마케팅 매니저

Robert Haynes의 다른 블로그 게시물