Terminal Server on a Budget
blog.lasseter.org
blog.lasseter.org
I used to have a glorious box of ram, spare drives, and every cable and adapter imaginable.
My box also mysteriously disappeared some time after I got married. I feel your pain :)
Sometimes I wonder what would have happened if we didn't already have kids.
I recall at one job we had very long runs of rs232 cables to some vt100's which where very sensitive to electrical charges.
To the point where one of our electronics shop brought the official Vt100 manuals so they could repair any blown chips.
DEC field circus loved us :-) It was the 11/03 covered I black coal dust that really upset them.
I'm just saying, this is not normal or acceptable behaviour.
My box of concert tickets from every show I ever saw disappeared.
I've always wondered if you could burn SGABIOS (https://code.google.com/archive/p/sgabios/) to a PCI(e) card ROM to get this working on real hardware instead of just in QEMU.
Apparently someone did try this, so it might just work: https://www.flashrom.org/User:GNUtoo/Howto_flash_sgabios_on_...
Maybe I should dig up some old flashrom supported NIC card or something.
If you have better recommendations feel free to share them :)
[1] https://freetserv.github.io/ [2] https://www.pcengines.ch/apu2c2.htm [3] https://www.delock.de/produkte/G_95244/merkmale.html
Personally, I'm a big fan of the OpenGear units. They're *much^ more than just basic serial consoles and are quite extendable. You can even write your own scripts to interact with them, trigger them on specific events, and so on.
I've used it with virtual machines running on both vSphere and QEMU/KVM to make their serial consoles available over the network... to access the serial console you can just connect to the corresponding TCP port. Just make sure to lock down / restrict access appropriately and ensure you don't send sensitive info over the network in clear-text!
It works the same way with physical devices too (Cisco devices, primarily). It's great when you want to a "permanent record" (on disk) of any output that is sent to the console.
As mentioned, it's really nice when you need to provide "shared" console access and/or access to multiple devices and/or users simultaneously. It's really an under-rated tool.
This happened to me as well. In fact it happened so often that I took all of the critical network software off the home server and run it on an edge router-x.
Also, setting “power on after power loss” and running the computer through a smart plug is a good idea. When it gets jammed, you can at least power cycle it remotely and it attempts to reboot.
There is no BIOS serial redirection, so SoL is no use until the OS starts booting, and grub has a bug[0][1][2] which means it can't find the AMT SoL when booting in EFI mode. But SoL works fine as soon as the kernel starts, and the KVM VNC works fine during BIOS and GRUB if I have an emergency.
One gotcha which would catch someone out who wasn't expecting it - the onboard video disables itself when no monitor is connected, so the AMT KVM just shows a black screen. This can be solved by DisplayPort or VGA "ghost" dongle in the back of the machine to talk EDID and pretend to be a screen.
I'm a big fan of conserver, and intend to use it in this project to spawn amtterm processes to connect to the SoL ports.
0: https://savannah.gnu.org/bugs/?42026
1: https://community.intel.com/t5/Intel-vPro-Platform/No-AMT-se...
2: https://wiki.networksecuritytoolkit.org/index.php/HowTo_Head...
Then, just SSH in to the other host and use something like "minicom" to connect directly to the serial port -- or use "conserver" (mentioned in TFA) when you've got multiple consoles and/or multiple users to deal with simultaneously.
Plenty of HN'ers are all-in on "cloud" but for anyone dealing with physical devices (routers, servers, whatever), remote access to the console can be a lifesaver at times!
What's the reason against SSH'ing from the gateway to the servers instead of the physical COM connection?
The plan was to use a Raspberry Pi to access the two PCs (via USB-to-serial adapters), though he hasn't made it to that point yet ("I have not used it for this project yet, but it is still in my plans."). Right now, the two PCs are just connected to each other, back-to-back.
> What's the reason against SSH'ing from the gateway to the servers instead of the physical COM connection?
I would assume that he does just use SSH -- under normal circumstances.
It's when SSH access isn't available that access via the serial console would be used -- such as the network connection being down or b0rked, when the kernel (or required) modules failed to boot/build/load properly, a bad firewall change has locked you out, and so on. This method even provides access to the bootloader.
If your BIOS supports "console redirection" (to a serial port), you also gain access to the BIOS, can watch the startup (POST) process, or even change the boot device -- in order to fire off a kickstart installation, for example.
He mentioned that his PCs don't have ILO/DRAC/IPMI, so this is his backup solution. -- remember that his machines are headless.
To give my home router a static IP address, I use a Vultr VPS and pay for an additional IP address. I then use IPSec encapsulation to forward traffic for the second IP address directly to the router, which initiates the IPSec SA setup. The router has a loopback device configured with the static IP address; the routable static address is effectively local, even from the kernel's perspective. The IPSec rules handle forwarding of everything, so I don't even need packet filtering (e.g. OpenBSD PF in my case) rules.
No need to fiddle with private address ranges, NAT'ing, reverse proxying, or packet filtering of any sort. The IKEv2 setup is a single line on the VPS and a single line on the router, though OpenBSD's OpenIKED (as well as their isakmpd fork for IKEv1) is awesome that way; StrongSwan and other Linux IKE daemons require a more verbose configuration on account of their key-value pair syntax, but in any event it's still relatively simple.
Wireguard is just a better wire protocol for moving packets, but IMO it's mostly a solution in search of a problem. Most of the complexity that people disdain about IPSec actually comes from IKE, but it's largely irreducible complexity. IKE is what initiates and negotiates security associations based on abstract flow rules--in this case 0.0.0.0/0 <-> W.X.Y.Z, where the latter is the static, routable address. Wireguard doesn't diminish the need for this layer, which is why you've been forced to hack a complete solution using a reverse proxy. IKE is far more mature than the experimental additional software Wireguard developers have been cooking up to automate tasks like this (abstract flows, key management, etc), and definitely more mature than the homebrew solutions people put together.
I bring this up because I think IPSec has gotten an undeserved bad rap. If people make do with Wireguard + hacks, great, but this particular scenario is a great example that shows the strengths of IPSec+IKE and the weakness of Wireguard; a reality people don't hear about given the unabashed enthusiasm for Wireguard.
I need to do this because port forwarding isn't working with my current ISP/router/etc setup (not sure where the problem lies). Did you forward the wireguard port to your home server, or another approach? I did some research and it looks like there's a "keep-alive" option that hopefully should get my wireguard connection open through NAT.
# Ensures that your home router does not kill the tunnel, by sending a ping
# every 25 seconds.
PersistentKeepalive = 25
[0] https://zach.bloomqu.ist/blog/2019/11/site-to-site-wireguard...
'graph 2 of TFA.