NGINX Plus R28 발표

NGINX Plus Release 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) 벡터에 표현된 서비스별 클라이언트 식별자는 백엔드 서비스로 전달되지 않습니다. NGINX Plus R28은 TLV를 디코딩하고 클라이언트 식별자를 백엔드 서비스로 전달하기 위한 변수를 정의하는 http및 컨텍스트 에 대한 모듈을 도입합니다 .stream
• 스티키 쿠키 samesite매개변수 에 대한 가변 지원  – NGINX Plus R28samesite 에서 지시문 에 대한 매개변수 값은 변수가 될 수 있습니다. 이 개선을 통해 트래픽을 더 쉽게 관리하고 보안을 강화할 수 있습니다.sticky cookie

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

행동의 중요한 변화

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

플랫폼 지원 변경

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

• AlmaLinux 8 및 9 (x86_64, aarch64)
• 알파인 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-LengthTransfer-EncodingContent-LengthTransfer-Encoding

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

추가 TLS 메트릭

SSL/TLS 이벤트 및 오류의 관찰 가능성은 프록시 구성, 업스트림 서버 및 클라이언트와 관련된 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 및 Stream 모듈 모두에서 핸드셰이크 오류 및 인증서 검증 실패에 대한 새로운 카운터로 TLS 메트릭 세트를 확장합니다(여기서는 HTTP 모듈에 대한 예만 제공하지만 사용 가능한 Stream 메트릭은 비슷합니다). 개별 업스트림 서버 및 가상 서버에 대한 메트릭 수집을 구성하는 방법에 대한 자세한 내용은 NGINX Plus R27<.htmlspan> 발표 블로그를 참조하세요 .

핸드셰이크 오류

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

• handshake_timeout – 핸드셰이크 타임아웃으로 인한 핸드셰이크 실패 횟수
• no_common_cipher – 핸드셰이크에 참여하는 당사자 간에 공통 암호가 없기 때문에 발생하는 핸드셰이크 실패 횟수(상류 서버에 대한 연결에는 적용되지 않으므로 수집되지 않음)
• no_common_protocol – 당사자 간 공통 프로토콜이 부족하여 핸드셰이크 실패 횟수가 증가함
• peer_rejected_cert – NGINX Plus에서 제시한 인증서를 상대방이 거부하고 적절한 경고 메시지를 제공하여 핸드셰이크 실패 횟수

인증서 검증 실패

verify_failures이제 인증서 검증을 구성할 때 인증서 검증 실패가 API 출력의 새 섹션에 보고됩니다 .

• 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 > Handshakes failed 열의 값 위에 마우스를 올려놓습니다.

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

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

• AWS 프라이빗 링크  –PP2_SUBTYPE_AWS_VPCE_ID
• GCP 프라이빗 서비스 연결  –pscConnectionId
• Microsoft Azure 개인 링크  –PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID

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

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 벡터는 PROXY 프로토콜 v2 헤더의 엔드포인트의 VPC ID를 인코딩합니다 PP2_SUBTYPE_AWS_VPCE_ID. (자세한 내용은 AWS 설명서를 참조하세요 .)

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

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

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 변수를 참조하는 블록 에서 [ HTTP ][ Stream ] 지시문 에 대한 매개변수 $proxy_protocol_tlv_gcp_conn_id도 포함해야 합니다 . 예를 들어 위의 proxy_protocol_v2.conf 의 8번째 줄을 참조하세요 .proxy_protocollisten

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를 디코딩하고 LinkID를 $proxy_protocol_tlv_azure_pel_id변수로 백엔드 애플리케이션에 전달합니다.

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

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

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

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

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

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

NGINX Plus R28의 기타 개선 사항

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

NGINX Plus R28은 NGINX Open Source 1.23.2를 기반으로 하며 NGINX Plus R27 이 출시된 이후(NGINX 1.23.0~1.23.2)에 이루어진 기능 변경 사항과 버그 수정 사항을 상속합니다. 변경 사항과 버그 수정 사항은 다음과 같습니다.

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

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

NGINX JavaScript 모듈의 변경 사항

NGINX Plus R28은 NGINX JavaScript 모듈(njs)의 버전 0.7.5에서 0.7.8까지 변경 사항과 수정 사항을 통합합니다. 저희는 블로그에서 Make Your NGINX Config Even More Modular and Reusable with njs 0.7.7 에서 가장 중요한 변경 사항 중 일부를 강조했습니다 . 전체 목록은 Changes 파일을 참조하세요.