Comment by infogulch
17 hours ago
I made my own tunnel system with a $5/mo vps that runs kernel wireguard and accepts my nas' public key. Once connected it DNATs 80/443 traffic down the tunnel to the nas, where its routed to caddy.
The vps runs a custom image that is 2.54 Megabytes. It has a custom kernel with almost everything but networking and wireguard disabled, a fixed-size fs with pre-allocated blocks and inodes to hold the vps wireguard key, and a single pid 1 binary that calls the kernel directly to set up the routing rules, generate a new wireguard key on first boot and save it to the fs, print out the wireguard public key to the console, and loops reap. Updating involves building and uploading a new image, assigning the vps to use it, reboot, wait for the public key in the console then set it on the nas so they can talk.
Self hosting might win on control, but it’s harder to manage so I went managed (CF Tunnel). Edge terminates TLS, my Caddy only speaks HTTP, nothing to cert renew (unless you cerbot, but that’s not a guarantee if Let’s encrypt is down).
Very cool, do you use some kind of an atomic distro like nix or something entirely self built using Yocto/Buildroot? I do something similar with a simple SSH tunnel and a NFT rule. Though, I don’t need your kind of ephemeral setup and so I just use Debian.
Thanks! The build system is nix, but the result is more of an appliance than a distro. (linuxManualConfig from tinyconfig + fragment, static musl Rust PID 1, mke2fs -d) Updates are rebuild-redeploy with the provider API; it can't update itself. The filesystem is a fixed-size image (even omitting resize2fs, so no growing onto the VPS disk), and it remounts read-only after boot. The boot log is 270 kernel lines then 4 userspace: 1 nftables loaded, 2 printing the gate's wg0 public key, 1 remounting ro.