proposal: built in self hosted ngrok

[1lann]

I want to add a built in self-hosted ngrok system to Casket. This would allow you to say, run a Casket instance on a server with an interface to a public IP, and another Casket instance on your computer behind a NAT, and trivially expose the Casket instance on your computer by forwarding requests from the remote server.

Problems to solve:

1. Authentication (ensure that only authorized Casket clients can expose sites on the remote server).
2. Configuration (how should configuration look like on both sides?)
3. Networking (how should the client communicate with the server?)

Configuration

On the Internet facing server

You would need to add a Casket server block for each server you want to run in order for TLS to work nicely. The inconvenience of this can be mitigated by allowing the use of wildcard blocks on the Internet facing server side that can resolve to as many different clients as desired. A secret must also be specified to authenticate clients.

Proposed configuration:

mysite.com {
    tun mysecret
}

*.mysite.com {
    tun mysecret2
}

:4000 {
    tun mysecret3
    tls self_signed
}

On the client server (i.e. computer behind NAT)

Proposed configuration:

tun://mysite.com {
    tun mysecret # if unspecified, defaults to environment variable maybe? CASKET_TUN_SECRET perhaps?
    # etc...
}

tun://example.mysite.com {
    tun mysecret2
    # etc...
}

tun://mysite.com:4000 {
    tun mysecret3 {
        insecure # tunnel is insecure as communication will be over plaintext HTTP/TCP
    }
    tls # TLS is mandatory
    # etc...
}

Networking

The client shall communicate to the server by connecting to the hostname specified
as the server block name, and forming a WebSocket connection to /.well-known/tun/{secret}.

With the client configuration examples above, it would look like connecting to:

wss://mysite.com/.well-known/tun/mysecret
wss://wildcard.mysite.com/.well-known/tun/mysecret2
ws://mysite.com:4000/.well-known/tun/mysecret3

The last example is over ws:// as determined by the insecure parameter. All
connections will be over wss:// otherwise.

The implementation specifics is to be determined, but I will likely use multiple (say 10 or so) multiplexed WebSocket connections that requests or connections will be round-robined across.

The Internet facing server is to return 404 Not Found for incorrect secrets, we ideally do not want to reveal
hosts that have Casket tunnels running on them.