Egregoros

@feld @tezoatlipoca @VD15 Yeah, that's certainly one of the ways to do this and somewhat similar to what I do for making services like a local Minecraft server available to the public while I'm behind NAT. My solution involves almost the same wireguard tunnel configuration on the actual host and a simple OpenBSD pf/relayd config on the remote VPS to transparently forward TCP traffic and masquerade on the way out. I might write a post on this, since the only known documentation of how to set this up is a decade old archive from a mailing list and documentation is most unhelpful in this case.

Also a note on VPS providers that lock you only into Linux distros. If you can get into a recovery mode where you have access to the boot disk, it is trivial to install OpenBSD and probably also FreeBSD on these. Grab a copy of the miniroot.img file, write it onto the main disk and reboot out of recovery. Install kernel will load into memory along with the installer (it lives in initrd) and you can safely overwrite the disk during the install. Only possible issue would be if the provider uses crap like cloud-init for network autoconfig.

pf.conf:

pass in quick on wg0 proto tcp from 10.0.80.2

pass out on egress from wg0:network to any nat-to (egress)
# OR
pass out on egress from 10.0.80.2 to any nat-to (egress)

relayd.conf:

ext_inet = IP_OF_VPS
table <mc_server> { 10.0.80.2 }

relay "mc" {
	listen on $ext_inet port your_favorite_port_here
	
	# relayd on OpenBSD 7.6 dropped sessions that were still
	# active with traffic for some reason. Might be fixed...
	session timeout 28800
	
	transparent forward to <mc_server> port 25565
}