SLT(8)

πŸ’– SLT β€” the manual, but make it make sense πŸ’–

okay so bestie, gather round, because slt is about to become your new main character. this is SLT(8) from the System Manager's Manual, and yes we're doing this in full, no skips, no cuts, periodt. πŸ‘‘


✨ NAME ✨

slt β€” multiplex a port for multiple TLS applications with SNI πŸ’…


✨ SYNOPOSIS ✨

slt config-file

(yes the section is literally spelled "SYNOPOSIS", we don't make the rules, we just respect the lore πŸ™ˆ)


✨ DESCRIPTION ✨

so like, slt is a TLS reverse-proxy and its whole vibe is letting an administrator run multiple TLS applications on a single port. iconic, honestly. πŸŽ€

the way it works is: slt multiplexes incoming connections by peeking at the Server Name Indication (SNI) extension data, and then forwards the connection to the appropriate upstream server. that's it. that's the whole slay. ✨


✨ CONFIGURATION FILE ✨

you configure slt with a simple YAML file. adorable. πŸ¦‹

  • specify a bind_addr to tell slt where it should listen for incoming connections. πŸ“
  • slt may listen for any number of frontends.
  • each frontend is identified by the name to match in the SNI data. 🏷️
  • each frontend forwards to any number of backends.
  • you may specify each backend with a hash of values.
  • the only required attribute is addr. that's the non-negotiable one, fr fr.
  • when more than one backend is enumerated, slt performs simple round-robin load balancing among them. πŸ”„

🌸 an example, because visuals help 🌸

here's one for listening on port 443 of all local interfaces, multiplexing traffic for two applications, v1.example.com and v2.example.com.

  • v1.example.com forwards to a single upstream server on port 1234. πŸ“
  • v2.example.com forwards to two upstream hosts on different addresses:
bind_addr: ":443"

frontends:
  v1.example.com:
    backends:
      - addr: ":1234"

  v2.example.com:
    backends:
      - addr: "192.168.0.2:443"
      - addr: "192.168.0.1:443"

πŸ” terminating TLS (optional, but cute) πŸ”

by default, slt does not terminate any TLS traffic. it only inspects connections for their SNI data before being forwarded upstream. lowkey just a lil gossip who reads the name tag and passes you along. πŸ‘€

but!! slt may terminate TLS traffic for any frontend by providing paths to the TLS public certificate and private key files, like so:

frontends:
  v1.example.com:
    tls_key: /path/to/v1.example.com.key
    tls_crt: /path/to/v1.example.com.crt

πŸ‘‘ designating a default πŸ‘‘

designate one frontend to be the default in the case that no SNI data is present in the connection, like so:

frontends:
  v1.example.com:
    default: true

✨ EXIT STATUS ✨

  • exit status is 0 on success 🌈
  • non-zero on failure πŸ’€


✨ AUTHOR ✨

Alan Shreve (@inconshreveable) β€” the icon, the legend, the moment. πŸ‘‘βœ¨


✨ SEE ALSO ✨


πŸ’– reminder bestie: slt by default does not terminate TLS, it just reads the SNI and passes the connection along. only add tls_key / tls_crt if you actually want it terminating for that frontend. don't be out here assuming things, iykyk. πŸ™ˆ

and that's the whole page, no cap. this one came from the System Manager's Manual, version dated August 2023, filed under SLT(8). take care of her, she's iconic. πŸŽ€πŸ’…πŸ«Ά

πŸ“¦ where this page comes from