Using subdomain instead of ports

[jbendes]

What are your thoughts on using subdomains instead of ports? Is the main downside there just that you would need to consume a bunch of CPU running a proxy server redirecting subdomains to one another?

[snsinfu]

Nice idea! Certainly subdomain routing would be useful. I can't add the feature soon though.

rtun is made as a "dumb" pipe that just forwards TCP/UDP traffic. To route connections over subdomains, the tool needs to special-case and inspect HTTP requests. It's some work but it's possible.

[jbendes]

I'm glad to hear you like the idea! Yeah I've had a few issues with ports being blocked behind some networks. While it sounds like you have a lot going on right now, would you be totally against discussing me funding this work?

[snsinfu]

Thanks. I can enable GitHub sponsors but pull requests help more. :) My job sometimes gets really busy and I cannot work on this project for some months. Now I have time, so I'll work on this issue.

For now, hostname-based routing can be achieved by running an HTTP reverse proxy along with rtun-server (as implied in your post?). I document an example setup here. Run Caddy with the following config:

$ cat Caddyfile
fooweb.example.com:80 {
    reverse_proxy localhost:8888
}
barapp.example.com:80 {
    reverse_proxy localhost:9999
}
$ sudo caddy run

and run rtun-server on the same host with this config:

# rtun-server.yml
control_address: 0.0.0.0:4000

agents:
  - auth_key: xxxx
    ports: [8888/tcp]
  - auth_key: yyyy
    ports: [9999/tcp]

Then, requests to http://fooweb.example.com will be transferred to a web server running on the agent host having auth_key: xxxx.

[snsinfu]

This is a design note. I will add http forwarding type in addition to the existing tcp and udp forwarding types. An http forwarding entry will specify a hostname pattern, and rtun-server will route HTTP requests to agents accordingly. The Echo framework would be reused for implementation. The new server and agent configs will look like:

# run-server.yml
agents:
  - auth_key: xxxx
    endpoints: [ 4567/tcp, http://*.example.com ]

  - auth_key: yyyy
    endpoints: [ 60000/udp, http://*.example.com:10080 ]

# rtun.yml
forwards:
  - endpoint: http://fooweb.example.com
    destination: localhost:8500

I will rename port(s) config keys to endpoint(s), keeping port(s) as aliases for compatibility.

[jbendes]

This sounds awesome! Are you imagining the reverse proxy only working on HTTP traffic? I was hoping to be able to use this for SSH forwarding. I currently use this as a reverse proxy for SSH forwarding via ports and I was hoping to use either subdomain or honestly even path is fine.

Something like this ssh -P 10000 user@https://example.com Would become ssh user@https://10000.example.com Or even ssh user@https://example.com/10000 Or ssh user@https://example.com/?port=10000

I experimented a bit with nginx reverse proxy with raw streams to get this to work but I haven't cracked it yet.

[snsinfu]

No, reverse proxy is for any TCP/UDP traffic. SSH is a primary use case of this tool. But hostname-based routing is possible only in special protocols like HTTP.

As far as I know, direct SSH connections cannot be routed based on hostname. An SSH client resolves a hostname to the IP address before connecting to a server, and the hostname is not used thereafter. So, the server has no idea what hostname the client uses to connect to it. On the other hand, HTTP traffic can be routed on the server side because a client sends hostname in a request like "Host: example.com".

But. There seem to be people wrapping SSH into HTTP:

• https://unix.stackexchange.com/questions/190490/how-to-use-ssh-over-http-or-https
• https://nurdletech.com/linux-notes/ssh/via-http.html

I do not understand how the ProxyCommand tricks in the linked pages work. So I'm not certain, but hostname-based routing may be possible if you can do SSH-via-HTTP.

[jbendes]

Ahhh damn. Okay I'll keep thinking on it then. For now will close this out