NGINX Plus R28 발표

NGINX Plus 릴리스 28(R28)이 출시되어 기쁩니다 . NGINX 오픈 소스를 기반으로 하는 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( 유형-길이-값 ) 벡터에 표현된 서비스별 클라이언트 식별자는 백엔드 서비스로 전달되지 않습니다. NGINX Plus R28은 TLV를 디코딩하고 클라이언트 식별자를 백엔드 서비스로 전달하기 위한 변수를 정의하는 http 및 스트림 컨텍스트를 위한 모듈을 도입했습니다.
• 스티키 쿠키 samesite 매개변수에 대한 변수 지원 – NGINX Plus R28 에서 스티키 쿠키 지시문에 대한 samesite 매개변수 값은 변수가 될 수 있습니다. 이러한 개선으로 교통 관리가 더욱 쉬워지고 보안도 강화되었습니다.

이번 릴리스의 핵심은 NGINX 오픈 소스에서 물려받은 새로운 기능과 버그 수정, NGINX JavaScript 모듈에 대한 업데이트입니다.

행동의 중요한 변화

메모: NGINX Plus R27이 아닌 다른 릴리스에서 업그레이드하는 경우 현재 릴리스와 이번 릴리스 사이의 모든 릴리스에 대한 발표 블로그에서 중요한 동작 변경 사항 섹션을 확인하세요.

플랫폼 지원 변경

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

• AlmaLinux 8 및 9 (x86_64, aarch64)
• Alpine 3.17(x86_64, arm64)
• 오라클 리눅스 9 (x86_64)
• Rocky Linux 8 및 9 (x86_64, aarch64)

제거된 이전 운영 체제:

• 2022년 8월에 수명 종료(EOL)에 도달한 Debian 10

NGINX Plus R29 에서 더 이상 지원되지 않으며 제거될 예정인 이전 운영 체제 및 아키텍처:

• 2022년 11월 1일 EOL에 도달한 Alpine 3.13

동일한 이름을 가진 여러 헤더 처리 변경

• 알려진 중복 업스트림 응답 헤더의 대부분은 이제 경고와 함께 무시됩니다.
• 중복된 Content-Length 및 Transfer-Encoding 헤더는 이제 거부되며 잘못된 Content-Length 또는 Transfer-Encoding 헤더가 포함된 응답이나 Content-Length 및 Transfer-Encoding이 모두 응답에 있는 경우에도 거부됩니다.

새로운 기능에 대한 자세한 정보

추가 TLS 메트릭

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

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

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

NGINX Plus R28은 HTTP와 스트림 모듈 모두에서 핸드셰이크 오류와 인증서 검증 실패에 대한 새로운 카운터를 추가하여 TLS 메트릭 세트를 확장합니다(여기서는 HTTP 모듈에 대한 예만 제공하지만, 사용 가능한 스트림 메트릭은 비슷합니다). 개별 업스트림 서버와 가상 서버에 대한 메트릭 수집을 구성하는 방법에 대한 자세한 내용은 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

인증서 검증에 실패하면 해당 원인에 대한 메트릭이 증가하고 연결이 끊어집니다. 그러나 이러한 실패는 핸드셰이크가 성공한 후에 발생하기 때문에 기본 핸드셰이크 카운터는 계속 증가합니다.

실패한 인증서 유효성 검사에 대한 측정 항목은 다음과 같습니다.

• expired_cert – 피어가 만료된 인증서를 제시했습니다.
• hostname_mismatch – 서버의 인증서가 호스트 이름과 일치하지 않습니다(클라이언트에 대한 연결에 대해 수집되지 않음)
• no_cert – 클라이언트가 요구 사항에 따라 인증서를 제공하지 않았습니다(업스트림 서버에 대한 연결에 대해 수집되지 않음)
• revoked_cert – 피어가 해지된 인증서를 제시했습니다.
• other – 다른 인증서 검증 실패에 대한 명시적 카운터

샘플 메트릭 출력

다음은 시스템 전체 수준에서 HTTP 연결에 대한 샘플 TLS 메트릭 세트입니다.

$ curl 127.0.0.1:8080/api/8/ssl { "핸드셰이크": 32, "세션 재사용": 0, "핸드셰이크_실패": 8, "공통 프로토콜 없음": 4, "공통 암호 없음": 2, "핸드셰이크_타임아웃": 0, "peer_rejected_cert": 0, "확인_실패": { "인증_없음": 0, "만료된 인증서": 2, "폐지된 인증서": 1, "호스트 이름 불일치": 2, "기타": 1 } }

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

$ curl 127.0.0.1:8080/api/8/http/server_zones/s9 { ... "ssl": { "핸드셰이크": 0, "세션 재사용": 0, "핸드셰이크_실패": 1, "공통 프로토콜 없음": 0, "공통 암호 없음": 1, "핸드셰이크_타임아웃": 0, "peer_rejected_cert": 0, "확인_실패": { "인증_없음": 0, "만료된 인증서": 0, "폐지된 인증서": 0, "기타": 0 } } ... }

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

$ curl 127.0.0.1:8080/api/8/http/upstreams/u2 { "피어": [ { "ID": 0, "서버": "127.0.0.1:8082", "이름": "127.0.0.1:8082", ... "ssl": { "핸드셰이크": 1, "세션 재사용": 0, "핸드셰이크_실패": 0, "공통 프로토콜 없음": 0, "핸드셰이크_타임아웃": 0, "peer_rejected_cert": 0, "verify_failures": { "만료된 인증서": 1, "폐지된 인증서": 0, "호스트 이름 불일치": 0, "기타": 0 } }, ... } ], }

NGINX Plus 대시보드는 확장된 TLS 메트릭을 표시합니다.

NGINX Plus R28 이상의 경우 라이브 활동 모니터링 대시보드에 위에 설명된 새로운 TLS 메트릭이 표시됩니다. 이 스크린샷은 클라이언트 연결에 대한 메트릭을 보여줍니다. 새로운 지표를 보려면 표시된 대로 SSL > 핸드셰이크 실패 열의 값 위에 마우스를 올려놓으세요.

클라우드 프라이빗 서비스의 PROXY 프로토콜 v2 TLV 지원

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

• AWS PrivateLink – PP2_SUBTYPE_AWS_VPCE_ID
• GCP Private Service Connect – pscConnectionId
• Microsoft Azure 개인 링크 – PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID

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

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

AWS를 위한 PROXY 프로토콜 v2 지원

AWS에서 Virtual Private Cloud(VPC) 엔드포인트 서비스 를 통해 클라이언트에서 오는 트래픽의 소스 IP 주소는 네트워크 로드 밸런서 노드의 개인 IP 주소입니다. 백엔드 애플리케이션에 클라이언트의 실제 IP 주소와 기타 식별자가 필요한 경우 PROXY 프로토콜 v2 헤더에서 이를 얻을 수 있습니다.

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

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

메모: $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 헤더 pscConnectionId 의 고유한(그 당시의) 연결 ID를 인코딩합니다. (자세한 내용은 GCP 설명서를 참조하세요.)

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

메모: $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 벡터는 클라이언트의 LinkID를 PROXY 프로토콜 v2 헤더 PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID 에 인코딩합니다. (자세한 내용은 Azure 설명서를 참조하세요.)

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

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

Sticky Cookie samesite 매개변수에 대한 변수 지원

이전 NGINX Plus 릴리스에서는 세 가지 정적 값( strict , lax , none )이 sticky 쿠키 지시문의 samesite 매개변수에 허용되었습니다. NGINX Plus R28 에서는 값이 변수가 될 수도 있습니다.

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

• 표준 값 중 하나( strict , lax 및 none )에 대해 NGINX는 SameSite 속성 집합을 해당 값에 주입합니다.
• 빈 값( "" ) – NGINX는 SameSite 속성을 주입하지 않습니다.
• 다른 값으로 잘못된 구성을 나타내는 경우 NGINX는 SameSite 속성 집합을 Strict (가장 안전한 설정)로 주입합니다.

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

NGINX Plus R28의 기타 개선 사항

NGINX 오픈 소스에서 상속된 변경 사항

NGINX Plus R28 은 NGINX Open Source 1.23.2를 기반으로 하며 NGINX Plus R27이 출시된 이후(NGINX 1.23.0~1.23.2) 기능 변경 사항과 버그 수정을 계승했습니다. 변경 사항 및 버그 수정 사항은 다음과 같습니다.

• HTTP 리졸버 지시문의 새로운 ipv4=off 매개변수는 IPv4 주소 조회를 비활성화합니다.
• ssl_session_cache 지시문에 shared 매개변수를 사용하여 HTTP 세션 정보에 대한 공유 캐시를 활성화하면 이제 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일 체험판을 통해 시작해 보세요.