I have servers and applications that sometimes need to be securely accessed remotely, over the internet. I wonder what tools most people in HN use to connect to their remote computers.
VPN is commonly used, but it’s good to see more details.
We had around 5 production servers colocated at he.com that were configured to use the serial port for BIOS I/O. This allowed us to manage a hardware RAID card for example. Linux was also configured to use the serial port for console I/O. We used "ttylog" to log all serial port I/O to log files.
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.
The 10.0.0.1 peer is a standard Wireguard server with masquerading.
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.
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.