I set up a wireguard server on a publicly accessible VPS.
The neat part about using "lscr.io/linuxserver/wireguard:latest"
is that it allows my to codify the number of clients I need. This includes both endpoints and source devices.
The second thing I did, was separate out the "networking" bits from the "userspace" bits, meaning it doesn't matter what port the service is running on. The client can hit it.
Taking that one step further, I just combined the above with haproxy and set my application ports there. This means I can hit haproxy on "someport" inside the VPN and it'll forward to whatever service I've got configured on that "client" that haproxy can see on it's LAN.
Works great, currently running a simple web page off the whole thing, where you connect to VPS and it tunnels the actual HTTP connection into kubernetes in my house.
I was thinking about writing this all up one day, but there's some cleanup to be done. Oh well.
A mesh VPN will give you point to point tunnel. Even http will be secure.
If I was doing something that I intended to have running more than an hour or two at a time, I would 100% do something more like what you're describing haha.
Cool part is that you don't even need to install a client. If you have Wireguard and curl you can simply run this one-liner:
curl https://tunnel.pyjam.as/8080 > tunnel.conf && wg-quick up ./tunnel.conf
> You can now access http://0.0.0.0:8080 on https://<unique_slug>.tunnel.pyjam.as/
Check it out if you're interested.
Code: https://gitlab.com/pyjam.as/tunnel
Public instance: https://tunnel.pyjam.as
In .ssh/rc:
if [ -n "$DOMAIN" ]; then
# ... create socket & report to user
clean_socket(){ rm /tmp/test.dev.tld.socket; }
trap clean_socket EXIT INT HUP;
fiI combined this infinite loop in ssh rc and a -T and a simple command "echo hello" in my client function and now it prints out the link to visit, hangs infinitely until I close it or it gets closed, and cleans itself up.
This just took the level of hackishness to new heights and I love it.
it's functional. but far from practical or elegant.
good write up tho
I also tried to hack together my own solution [0] just for fun, but I didn't know about the unix socket part, so at the end I went with traefik and redis. :)
[0] https://deadlime.hu/en/2023/10/29/light-at-the-end-of-the-tu...
I just checked out your solution and also learned a new trick about ssh! I didn't know that setting the port to 0 would cause dynamic allocation for the tunnel. It makes sense, I did know about that 0 behavior just in typical linux processes, but never thought to apply it to an ssh tunnel.
- https://news.ycombinator.com/item?id=39754786
- FWIU headscale works with the tailscale client and supports MagicDNS
I didn't know about headscale, that does seem pretty cool but I think MagicDNS also specifically would introduce a behavior that I didn't particularly want -- TLS certs being issued for my individual hosts, and thus showing up in cert transparency logs and getting scanned. Ultimately this is really only a problem in the first minutes or hours of setting up a cert, though.
Honestly I would probably recommend every other solution before I recommend my own. It was just fun to figure out and it works surprisingly well for what I wanted -- short lived development tunnels on my own infra with my own domain, without leaking the address of the tunnel automatically.