VPN is commonly used, but it’s good to see more details.
Each server had 2 serial ports. We cabled them together in a circular daisy chain. To access server 2, we'd ssh into server 1 and use cu to connect to server 1's serial port. This was wired to server 2's console serial port.
The advantage of this setup is that even if a system had a hard failure and halted, we could still talk to it and get it going again. I guess it could be done with a terminal server connected to each console serial port, but the logging we got with ttylog was also nice: server 2's console log would be stored on server 1. And of course it was easily extendable and dirt cheap to implement. Worked really well for us for years.
I wonder if jumphosts could be achieved in Wireguard, so Peer A connects to Peer B, then to Peer C, while the connection from A to C is end to end encrypted.
This would be similar to SSH jump hosts.
To my knowledge, this could not be done with VPN, unless with additional software, eg, a mesh VPN. B could port forward A’s request to C. This may not be possible, since B might offer a VPN access not port forwarding. For example, you authenticate to a network by policy, and then to a server. A could run two instances of VPN, one to A, then another to C. This gets quickly unwieldy and the client software may not allow running more than one instance of VPN, eg, in phones.