NGINX Plus R28リリースのお知らせ

Robert Haynesテクニカルマーケティングマネージャー

NGINX Plus Release 28 (R28)の提供開始をお知らせします。NGINX Open SourceをベースとするNGINX Plusは、Webサーバー、ロードバランサー、リバースプロキシ、コンテンツキャッシュ、APIゲートウェイの機能をすべて備えた唯一のオールインワンソフトウェアです。

NGINX Plus R28の新機能および強化された機能は次のとおりです。

• 追加のTLSメトリクス – NGINX Plus R28では、システム全体、クライアント側、サーバー側の各レベルで追加のTLS統計情報を収集します。これにより、プロキシ設定や、クライアントおよびアップストリームサーバーへの接続におけるSSL/TLS関連エラーのトラブルシューティングに不可欠な知見が得られます。NGINX Plusのライブアクティビティ監視ダッシュボードも更新され、新しいSSLセッションデータが表示されるようになりました。
• クラウドプライベートサービスでのPROXY protocol v2 TLVのサポート – AWS、Google Cloud Platform、Microsoft Azureの「プライベートサービス」を介して外部クライアントにリソースを提供する場合、デフォルトでは、PROXY protocol v2ヘッダー内のtype-length-value（TLV）ベクトルで表されるサービス固有のクライアント識別子は、バックエンドサービスに渡されません。NGINX Plus R28では、TLVをデコードし、クライアント識別子をバックエンドサービスに転送するための変数を定義する、httpおよびstreamコンテキスト用のモジュールが導入されています。
• sticky cookieの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日に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はシステム全体で3つのTLSメトリクスを収集しています。

• handshakes – 成功したSSLハンドシェイクの数
• handshakes_failed – SSLハンドシェイクの失敗回数（SSLハンドシェイク後に発生する証明書検証の失敗は含まれません）
• session_reuses – SSLセッションの再利用回数

In NGINX Plus R27<.htmla>以降では、個々のアップストリームサーバーおよび仮想サーバーについて、3つのメトリクスを収集するように設定できます。

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][Stream]
  • 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］列の値にマウスポインターを合わせます。

Cloud Private ServicesでのPROXY Protocol v2 TLVのサポート

主要な3つのクラウドプロバイダーであるAmazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azureは、それぞれ「プライベートサービス」を提供しています。これにより、サービスをパブリックインターネットに公開することなく、外部クライアントからのアクセスを可能にできます。各サービスでは、PROXY protocol v2ヘッダー内のtype-length-value (TLV)ベクトルで表されるクライアント識別子を使用します。サービス固有の識別子は次のとおりです。

• AWS PrivateLink – PP2_SUBTYPE_AWS_VPCE_ID
• GCP Private Service Connect – 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 Protocol v2のサポート

AWSでは、Virtual Private Cloud（VPC）エンドポイントサービスを介したクライアントからのトラフィックの送信元IPアドレスは、Network Load BalancerノードのプライベートIPアドレスになります。バックエンドアプリケーションでクライアントの実際のIPアドレスやその他の識別子が必要な場合は、PROXY protocol v2ヘッダーから取得できます。

AWSでは、カスタムTLVベクトルにより、エンドポイントのVPC IDがPROXY protocol 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変数を参照する場合は、proxy_protocolパラメーターもlisten［HTTP］［Stream］ディレクティブに含める必要があります。例については、直下のproxy_protocol_v2.confの8行目を参照してください。

このAWS向けサンプル構成では、VPC IDが許可されているかどうかを確認し、許可されている場合は、add_headerディレクティブの第2パラメーターとしてバックエンドアプリケーションに渡します。

コード例を読み込み中…

GCP向けPROXY Protocol v2サポート

GCP Private Service Connectでは、クライアントから送信されるトラフィックの送信元IPアドレスは、「サービスプロデューサーのVPCネットワーク内にあるPrivate Service Connectサブネットのいずれかのアドレス」となります。バックエンドアプリケーションでクライアントの実際のIPアドレスやその他の識別子が必要な場合は、PROXY protocol v2ヘッダーから取得できます。

GCPでは、カスタムTLVベクトルに、その時点で一意の接続IDがPROXY protocol v2ヘッダー「pscConnectionId」内にエンコードされます。（詳細については、GCPドキュメントを参照してください。）

NGINX Plus R28はTLVをデコードし、pscConnectionIdの値を$proxy_protocol_tlv_gcp_conn_id変数でバックエンドアプリケーションに渡します。

注： serverブロックで$proxy_protocol_tlv_gcp_conn_id変数を参照する場合は、proxy_protocolパラメーターもlisten［HTTP］［Stream］ディレクティブに含める必要があります。例については、上記のproxy_protocol_v2.confの8行目を参照してください。

Microsoft Azure向けPROXY Protocol v2のサポート

Microsoft Azure Private Linkでは、クライアントからのトラフィックの送信元IPアドレスは、「プロバイダーの仮想ネットワークから割り当てられたNAT IP［アドレス］を使用して、サービスプロバイダー側でネットワークアドレス変換（NAT）されます」。バックエンドアプリケーションでクライアントの実際のIPアドレスやその他の識別子が必要な場合は、PROXY protocol v2ヘッダーから取得できます。

Azureでは、カスタムTLVベクトルにより、クライアントのLinkIDがPROXY protocol v2ヘッダーの「PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID」にエンコードされます。（詳細については、「Azureドキュメント」を参照してください。）

NGINX Plus R28はTLVをデコードし、LinkIDを$proxy_protocol_tlv_azure_pel_id変数でバックエンドアプリケーションに渡します。

注： serverブロックで$proxy_protocol_tlv_azure_pel_id変数を参照する場合は、proxy_protocolパラメーターもlisten［HTTP］［Stream］ディレクティブに含める必要があります。例については、上記のproxy_protocol_v2.confの8行目を参照してください。

Sticky Cookieのsamesiteパラメーターでの変数サポート

以前のNGINX Plusリリースでは、3つの静的な値（strict、lax、none）を、samesiteパラメーターの値としてsticky cookieディレクティブで使用できました。NGINX Plus R28では、変数も値として使用できます。

デフォルトでは（samesiteパラメーターが指定されていない場合）、NGINXはCookieにSameSite属性を追加しません。samesiteパラメーターが変数の場合、結果は実行時に変数がどのような値に解決されるかによって異なります。

• 標準値のいずれか（strict、lax、none）に解決される場合 – NGINXは、その値に設定されたSameSite属性をCookieに挿入します
• 空の値（""）に設定した場合、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）に行われた機能変更とバグ修正を継承しています。変更とバグ修正には、以下が含まれます。

• 新しいHTTP ipv4=off パラメーターをresolver ディレクティブに指定すると、IPv4アドレスの検索が無効になります。
• HTTPセッション情報の共有キャッシュを有効にするため、sharedパラメーターをssl_session_cacheディレクティブに指定すると、TLSセッションチケットキーが自動的にローテーションされるようになりました。
• 複数の種類のTLS/SSLエラーをログに記録する際の重大度レベルが、critからinfoに引き下げられました。

これらのリリースから継承された新機能、変更点、バグ修正の全一覧については、CHANGESファイルを参照してください。

NGINX JavaScript Moduleの変更点

NGINX Plus R28には、NGINX JavaScriptモジュール（njs）のバージョン0.7.5～0.7.8で行われた変更と修正が組み込まれています。特に重要な変更については、F5のブログ記事「njs 0.7.7でNGINXの設定をさらにモジュール化し、再利用性を向上」で紹介しています。完全な一覧については、「Changes」ファイルをご覧ください。

NGINX Plusへのアップグレードまたはお試し

NGINX Plusをご利用の場合は、できるだけ早くNGINX Plus R28へアップグレードすることを強く推奨します。これにより、複数の追加修正や改善も適用され、サポートチケットを起票する必要が生じた際に、NGINXがより円滑にサポートを提供できるようになります。

NGINX Plusをまだお試しでない場合は、セキュリティ、負荷分散、APIゲートウェイとして、または強化された監視・管理APIを備え、充実したサポートを受けられるWebサーバーとして、ぜひお試しください。今すぐ30日間の無料トライアルを開始できます。

著者について

Robert Haynesテクニカルマーケティングマネージャー

Robert Haynesのその他のブログ記事