I can't help but notice that this tool was created to circumvent private networks. If you just wanted to write a crypto tool, kudos, but this is not a good idea for production data. I also recommend focusing on system hardening versus throwing crypto and fewer lines of code at the problem. The net benefit is ten times that of a more complex set-up that only protects a corner case.

Take your original example: 17 servers and you want to share data between them on the internet. The most effective way to do this is to put them all on one or two hosting providers and use private IPs to connect them all via the same backend. This way there is no surface to attack (if the hoster VLAN'd your hosts correctly). Back in the day we used to do this by putting a private switch in a rack that nothing else could touch, but it seems the days of private cage monkeying has disappeared.

The other way is by using a VPN. A VPN is simply a network interconnect. Based on some authentication data, allow a host to connect to a private network. If done properly, there is no service to take advantage of and the daemon can run completely without any capabilities or system access, save of course network traffic. You then add firewalling to ensure only the right hosts get to the right services. You can even make this a single stand-alone VPS host to add granularity and separation of privilege, not to mention reduced attack surface.

Your tool is theoretically simpler in practice than either of those methods (I don't find setting up a VPN to be complex, but others might). But it comes with the same risks as OpenSSH, save that (I imagine?) you could set it up to be network-access-only like a VPN. The difference for a VPN being you wouldn't need to configure multiple instances of an application.