That doesn't work well if you want to run the same service on multiple machines. For some you can proxy that (eg, for web you can just run nginx to proxy everything based on either the host header or SNI data), but for others you can't - you're only going to be able to have one machine accepting port 22 traffic for ssh.
I can port forward port 22 to a single machine. I can't proxy port 22 in a way that directs the incoming connection to the correct machine, at least not without client configuration.
You only need one inbound machine as your bastion. Then hop from there to the rest using local address. Once you set up the proxy config in ssh it’s completely transparent.
Right yes but I (for various reasons) end up using a lot of different client systems and I don't want to have to configure all of them to transparently jumphost or use different port numbers and why are people spending so much time trying to tell me that I should make my life complicated in a different way to the one I've chosen?
It's weird how much pushback you're getting for a few simple firewall rules, but I guess it's just another bikeshed. Basically all of the options for doing this are simple if you already know them, and have some annoying complexity otherwise. So everyone has a favorite.
I've got a similar setup to what you've done here, with the policy routing and wireguard tunnels being part of a larger scheme that lets me granularly choose which Internet horizon each particular host sees. So I can have a browsing VM that goes out a rotating VPS IP, torrent traffic out a commercial VPN, Internet of Trash out a static VPS IP (why not separate from my infrastructure IP), visitors' devices going out a different rotating VPS IP (avoid associating with me), Windows VMs that can only access the local network (they have personal data), etc.
I'm currently hosting email/etc on a VPS, but the plan is to bring those services back on-prem using VPS IPs with DNAT just like you're doing. Any day now...
Yeah, I currently have a VPS with various SSH port forwards allowing me to direct incoming connections of various types to my home computer which is behind NAT. It's evil and horrible and nasty for various reasons, not least of which that all your incoming connections look to your inner server like they come from the same IP address, preventing you from logging or filtering the source of any request. And you need to make sure if you forward incoming connections to your SMTP server that it doesn't think they are local trusted connections that it can relay onwards, turning your setup into an open relay.
Seriously thinking about switching to a setup similar to the article. I mean, my setup works for now, but it's un-pretty.
Yes, if I had multiple IPv4 addresses already it wouldn't be necessary to tunnel in additional IPv4 addresses, but since I don't and since there are no ISPs who will provide that to me at this physical address, tunneling is where I am.
The Google data strongly suggests that at this point it's probably available to a majority of home users. Corporate remains significantly worse. My employer, which paid me to do IPv6 stuff last century in a very different role, today has IPv6 for random outsiders but if you have a corporate issued laptop IPv6 is disabled and they cheerfully explained that it's "difficult" in a call this week right before I pointed out what I was paid to do and where a quarter century ago. Embarrassing for them.
Meta IIRC is one of several outfits which unsurprisingly discovered that (as a corporation) the cure is just purchasing policy. When your new Doodad vendor sells you a product that is IPv4 only instead of saying "Oh, shame, OK, set all corporate systems to IPv4-only" you point them to the line in your purchase contract which says you require IPv6 and it's not your problem it's their problem, do they want to fix it or refund you ?
