NGINX Plus R28 の発表

NGINX Plus リリース 28 (R28)が利用可能になったことをお知らせします。 NGINX オープンソースをベースにした NGINX Plus は、唯一のオールインワンソフトウェア Web サーバー、ロード バランサー、リバース プロキシ、コンテンツ キャッシュ、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)
• 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 メトリクスを収集しています。

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

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 ][ストリーム]
  • 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、「ピア拒否証明書」: 0、"verify_failures": { "no_cert": 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、「ピア拒否証明書」: 0、"verify_failures": { "no_cert": 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、「ピア拒否証明書」: 0、"verify_failures": { "expired_cert": 1、「失効した証明書」: 0、「ホスト名の不一致」: 0、「その他」: 0 } }, ... } ], }

NGINX Plusダッシュボードに拡張TLSメトリックが表示される

NGINX Plus R28以降では、ライブ アクティビティ モニタリング ダッシュボードに上記の新しい TLS メトリックが表示されます。 このスクリーンショットは、クライアントへの接続のメトリックを示しています。 新しいメトリックを表示するには、図に示すように、 [SSL] > [ハンドシェイク失敗]列の値にマウスを合わせます。

クラウド プライベート サービスにおける PROXY プロトコル v2 TLV のサポート

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

• AWS プライベートリンク– PP2_SUBTYPE_AWS_VPCE_ID
• GCP プライベート サービス接続– pscConnectionId
• Microsoft Azure プライベート リンク– PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID

デフォルトでは、これらのクライアント識別子はバックエンド サービスに渡されません。 NGINX Plus R28 では、 httpおよびストリームコンテキスト用のモジュール ( 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変数でバックエンド アプリケーションに渡します。

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

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

GCP の PROXY プロトコル v2 サポート

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

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

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

注記： $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 ヘッダーPP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKIDにクライアントの LinkID をエンコードします。 (詳細については、 Azure のドキュメントを参照してください。)

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

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

スティッキー Cookie samesiteパラメータの変数サポート

以前の NGINX Plus リリースでは、スティッキークッキーディレクティブのsamesiteパラメータには 3 つの静的値 ( strict 、 lax 、 none ) が許容されていました。 NGINX Plus R28では、値は変数にすることもできます。

デフォルトでは ( samesiteパラメータはありません)、NGINX は Cookie に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 を備えた完全にサポートされた Web サーバーとして、ぜひお試しください。 30 日間の無料トライアルを今すぐ開始できます。