My thought on networking is to make sure you only expose SSH and HTTPS; firewall everything else off. SSH seems like a constant source of problems for people new to running servers; within seconds of your server coming online, people will be trying to guess usernames and passwords. Configure it so you can't log in as root, and you can only authenticate with a key. These folks will never guess your key in a billion years (though obviously, don't leak it or something). I wouldn't bother with the complexity of fail2ban. If you have some out-of-band virtual console, you might not even need SSH, but it will be nice to have for git clones if you're self-hosting repositories. Totally reasonable to have SSH exposed to the Internet, in my opinion.

For HTTPS, run everything through a proxy, and maintain detailed access logs. Put your other services behind that proxy, and have them listen on 127.0.0.1 and not 0.0.0.0 (not that it really matters because you firewalled off all connectivity like that). Your HTTPS proxy should handle certificate provisioning for you. There are many options out there; I use Envoy, the self-hosting types should use Caddy or similar.

Anything that you expose to the Internet on a well-known port with an easy-to-guess password will be hacked instantly; SSH, MySQL, Wordpress, you name it, they'll own it. Seriously, your mind will be blown and your head will spin. Reduce the number of network ingress points to the bare minimum (though firewall rules), make sure absolutely everything not hardened is behind auth, and log aggressively so you can see what happened when something goes wrong.

I don't know what the state of the art these days is for auth. I wrote my own thing that uses WebAuthn; most people are probably using something like Keycloak. The Tailscale idea is also good; if you don't need this stuff on the Internet, then only put it on the Tailnet and let them handle auth.