Support SNI preread module and routing of TCP traffic with TransportServer

[shaun-nx]

Discussed in #5544

^{Originally posted by brianehlert May 14, 2024}
SNI based routing of Layer 4 traffic is a way to support customers using DNS names for TCP traffic and support routing based on the SNI header.
With NGINX this is implemented using the stream ssl pre-read module.
https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html

This module is already present in the NGINX Plus binary.

Today, this is possible with heavy use of snippets. The ask is to make this present and first class with the TransportServer resource.

This also historically described here:
https://stackoverflow.com/questions/34741571/nginx-tcp-forwarding-based-on-hostname

There are some additional considerations that need to be included here:

• The possibility for greater flexibility with TransportServer
• Extending this with the concept of a TranspotServerRoute (similar to the VS/VSR relationship)
• Creating theoretical simplicity to role separation and easy to provide controls over the hostname versus the backend definition
  This is conceptually no different than the suggestion to make the VS/VSR relationship easier to implement like Ingress master/minion but with some level of security controls like Gateway API ReferenceGrant.

The overall concept is multiple upstream targets for TCP behind a single listener and to route based on SNI.
This would support both TLS Passthrough as well as advanced programmability that might require TLS decryption and re-encryption.

To bring this all together:

• TransportServer would include the option for a top level domain type SNI match ( foo.com )
• Following a concept similar to an http path or nginx location - the extension of a service specific route that matches to the backend service (service.foo.com)
  this would be available in the TransportServer or possible with a TransportServerRoute 'attaching' to a TransportServer
  This is the same relationship pattern with think about with Ingress master/minion or with VirtualServer/VirtualServerRoute
• This would support TLS passthrough and decrypted TLS (it would use preread)

TLS traffic in -> TransportServer matches TLD of hostheader -> TransportServerRoute matches server.TLD of host header and defines upstream.

[github-actions]

Hi @shaun-nx thanks for reporting!

Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂

Cheers!