You are no longer "zero trust" as you have to trust the VPN server to verify the identity of the nodes, because the traffic to your node is not encrypted to and from another node (there are two encrypted tunnels between each of you and the VPN server, and the information that would allow you to verify the identity of the other node is stripped at the VPN server).
Your VPN server also basically becomes a network switch in this case, doing the backhaul between all clients, which is likely to be expensive and slow compared to peer-to-peer connections.
If you try to improve this by making the clients entire networks with switches/routers connected to each other only via internetwork VPN tunnels, then you also lose the property of the network that only known, verified nodes can be on that network. Not only can you not verify all nodes you connect to, neither can the VPN server (e.g. someone could plug a malicious or insecure device into the switch in your office, that would then have the same access to the network as other nodes).
Good point. But what would be the security difference between running a VPN server on a cloud instance, versus running a DERP/relay/coordination server on the same cloud?
Sure, the traffic is decrypted on the VPN server in the hub-and-spoke case (even if most traffic is already encrypted by TLS and applications) but in both cases the server in the cloud could compromise the connection (in different ways, but correct me if I’m wrong that malicious servers used initially to establish the peer to peer connection cannot compromise the network, even with the Lock feature which prevents addition of unsigned public keys). You have to trust the cloud provider.
Somehow people think mesh VPNs don’t need opening ports or are peer to peer. Not exactly: you just pass it to someone else to open ports for your network (used at minimum in the initial connection, and in the case of relays for the entire session). You have to trust the cloud in both cases, though in different ways. Further, at least your identity provider could act as an administrator with full privileges.
Certainly there are potential exploits if you rely on a 3rd party cloud or service to run the coordination service, though these might be more limited than on a VPN server.
Yggdrasil, assuming nodes operate their own identify based firewall as described the the original article, and tailscale if you use it with self hosted headscale rather than their coordination server can improve on this further.
At work we run headscale on a physical machine we control for now.
Personally I’m very interested in mesh networks like Yggdrasil and secure, radically open overlay networks and virtualised services in general.
I would note to aborsy comment 'VPN server on a cloud instance, versus running a DERP/relay' that if the overlay is architected 'correctly' then it uses mTLS connections between each hope while having E2E encryption between source and destination for the overlay. Net result is you do not have to trust the node as its never decrypting data while the edge runs in your own environment. Further, you cannot just impersonate a node.
You do have to trust the control/coordination server, though you could also run this in confidential compute.
Your VPN server also basically becomes a network switch in this case, doing the backhaul between all clients, which is likely to be expensive and slow compared to peer-to-peer connections.
If you try to improve this by making the clients entire networks with switches/routers connected to each other only via internetwork VPN tunnels, then you also lose the property of the network that only known, verified nodes can be on that network. Not only can you not verify all nodes you connect to, neither can the VPN server (e.g. someone could plug a malicious or insecure device into the switch in your office, that would then have the same access to the network as other nodes).