Tailscale Peer Relays is now generally available

Embedding is an option, but tunnelers - https://netfoundry.io/docs/openziti/reference/tunnelers/ - and edge routers (which can front legacy services without modifying them) also exist.

The difference is architectural; Tailscale is a mesh VPN, whereas OpenZiti is an identity-first, zero trust overlay network. This makes OpenZiti service-centric and deny-by-default, not network-centric. Instead of “join a private network,” you get access only to explicitly authorised services — with no ambient reachability at all. Its also 100% open source. If you want a simple productised, SaaS experience, NetFoundry, the company behind OpenZiti provides that.

It's difficult for us to maintain documentation of exactly the kind you'd want there, though we do try to keep up with docs as best we can. In particular there is a fairly wide array of heuristics in the client to adapt to the environment that it's running in - and this is most true on Linux where there are far far too many different configuration patterns and duplicate subsystems (example: https://tailscale.com/blog/sisyphean-dns-client-linux).

To try and take a general poke at the question in more of the context you leave at the end:

- We use rule based routing to try to dodge arbitrary order conflicts in the routing tables.

- We install our rules with high priority because traffic intended for the tailnet hitting non-tailscale interfaces is typically undesirable (it's often plain text).

- We integrate with systemd-resolved _by preference_ on Linux if it is present, so that if you're using cgroup/namepsace features (containers, sandbox runtimes, etc etc) then this provides the expected dns/interface pairings. If we can't find systemd-resolved we fall back to modifying /etc/resolv.conf, which is unavoidably an area of conflict on such systems (on macos and windows they have more broadly standard solutions we can use instead, modulo other platform details).

- We support integration with both iptables and nftables (the latter is behind manual configuration currently due to slightly less broad standardization, but is defaulted by heuristic on some distros/in some environments (like gokrazy, some containers)). In nftables we create our own tables, and just install jumps into the xtables conventional locations so as to be compatible with ufw, firewalld and so on.

- We do our best in tailscaled's sshd to implement login in a broadly compatible way, but again this is another of those places the linux ecosystem lacks standards and there's a ton of distro variation right now (freedesktops concerns start at a higher level so they haven't driven standardization, everyone else like openssh have their own pile of best-guesses, and distros go ham with patches).

- We need a 1360 byte MTU path to peers for full support/stability. Our inner/interface MTU is 1280, the minimum MTU for IPv6, once packed in WireGuard and outer IPv6, that's 1360.

I can't answer directly based on "very custom" if there will be any challenges to deal with. We do offer support to work through these things though, and have helped some users with fairly exotic setups.

Through paying users like me.

Thank you for being the first person in this discussion to explain wtf this is.

Netbird is very good for my use case. Simple to set up, and just works.