My 'Quick' answers (TL;DR version below): 1. Think about VPNs for secure access and 'freedom' to connect to various devices in various ways all through an encrypted tunnel. By freedom I mean avoiding weird port forwarding rules and such in the firewalls. We use OpenVPN heavily in the VTGS, with our firewalls running the server side (look into pfSense for an awesome firewall solution with native OpenVPN support). 2. Numato Relays for low voltage control ((https://numato.com/product/8-channel-ethernet-relay-module). Both a webserver interface and a low level telnet interface for control through external programs. We use it to control things like LNA power, Polarization switch control, radio power (SDRs for us), tracking control box power, etc. (We also use a IP controllable AC strip, but mainly for the 'nuke it from orbit' solution if we need to power cycle something). For anything high current the numato relays also offer extra digital I/O ports on the same relay boards via standard 0.1 inch headers that can be used to control things like high current FET switches (W6PQL has a good example: https://www.w6pql.com/high_current_solid-state_dc_switch.htm). This might be handy for things like controlling rig power if it sucks more current during TX than the numato relays can handle. 3. 'rigctl' and 'rotctl' for controlling radios and rotators (respectively). Lots of support out there. As mentioned, SatNOGS is a good resource for this. Both can run on an RPi with USB style interfaces to the Rig / Rotator control box. We use IP controllable systems at VT (mostly Spid MD-01s) which can be controlled by rotctl or via custom software. 4. We used to use 'ffmpeg' as an audio streaming server (winner of the 'lowest latency' contest when we were searching for this kind of solution, compared to things like 'icecast'). On the 'receive side' we just used VLC media player. A low cost USB audio card + an RPi (I think the RPi jack was only audio out, no mic in, but I could be wrong about that) could work for the audio connection to a HW rig. PulseAudio has a great interface for setting up the audio routing and loopbacks and such if you need them (it's a bit like a swiss army knife for this sort of thing). There are also a few other low level command line utilities, and some cripting might make it easier to set up a two way connection. There are also some remote desktop utilities that include audio features. I think the one we used for a while was 'NoMachine' but we switched to 'X2Go' so that we could play games with GPU accelerated FFTs and OpenGL rendering (for gr-fosphor spectrum displays for those curious) that didn't work over other remote desktop solutions. There are probably a lot newer solutions for this now (its been a few years since we've messed with audio streaming). 5. Almost all of the VTGS code is on Github: https://github.com/vt-gs. There might be some nuggets buried in there useful for you (maybe the relay control code and/or the Spid control code if you want to do it with python, Eagle/Kicad boards for PA control and the companion network control software, etc.). Fair warning, its constantly changing and is pretty specific to our system, but still you might find something useful there.
TL;DR version: Most of our setup at the VT ground station is remote over IP connections (even our VHF/UHF PA system). We use SDRs + GNU Radio, so its also a little different compared to folks using HW radios. Its pretty non-standard and constantly changing, and I don't have an 'easy' diagram to share (more like a few hundred slides of the evolution over the years). At a super high level, we run everything on a LAN at the tracking station and then remotely connect to it over VPN connections. From there the remote system can then access individual servers/devices over SSH, through low level message passing protocols (RMQ and/or ZeroMQ),and even lower level TCP/UDP sockets, etc. etc. Using the VPN is 1) secure and 2) avoids crazy weird firewall rules for port forwarding.
For the remote power control, we also use a remote (IP) controllable AC strip. I use this for the 'high level' remote power control and typically a human is accessing it and controlling things through the built in webserver. For 'lower level' power control (typically DC) I use IP controllable relays from Numato Relay (https://numato.com/product/8-channel-ethernet-relay-module). They have a nifty built in webserver as well as an interface over telnet (a little archaic, but easily interfaced with using Python modules) for control from external programs. We mostly only run low voltage/low current devices through these relays, like LNAs, Polarization control, USRP power (the SDRs we use, 6VDC), the 15VDC supply to the MD01 so we can turn the tracker off (NOT the 24V motor supply!), etc. etc. We don't do things like TX/RX sequencing with this, mainly due to latency concerns over a network, and that is handled by the transmitter 'deck' that has interfaces into things like the LNA PTT lines.
For tracking control, we also use IP addressable systems. In our case its mostly Spid MD-01s with the Ethernet module add on. We also use serial to IP converters and a 'faux-yaesu' interface (basically an Arduino and some circuitry that emulates the yaesu interface box) for controlling some yaesu rotators. If I could start over, I would have thought more about using things like 'rotctl' and 'rigctl'. Problem with that for us at VT is we work with something like 10 different manufacturers' versions of 'tracking pedestals' that are never likely to be supported by rotctl because most aren't for Amateur Radio (like FLIR and MOOG systems), but we are working towards a unified 'tracking daemon' that has to account for all flavors of PTU. As mentioned, SatNOGS has good stuff on this front.
For the specific issue of audio streaming, I have only come up with two 'workable' solutions over the years, though it has been a while. The main issue was latency. A lot of the solutions at the time were fine for like podcast streaming where some delay was no big deal (like 'icecast'), but SUPER frustrating if trying to tune by ear for a linear bird on sideband (you'd tune....then like 30 seconds later you'd hear the audio change). We finally settled on 'ffmpeg' for the audio streaming 'server'. For the receive side I just used VLC media player. I think ffmpeg has been absorbed into other open source audio projects, but I can't remember which one off the top of my head. The other solution was actually a remote desktop solution called 'NoMachine'. It was a little cludgy at the time, but it was remote desktop combined with audio support and the audio latency was imperceptible. All of this was 5+ years ago, and as already mentioned, there are probably a lot better solutions out there. In all cases I'd recommend '
Finally, almost all our code is on Github (and eventually our documentation will be as well). Feel free to take a look, but fair warning, its constantly changing and pretty specific to our system. There might be nuggets in there that are useful to you though (like the Numato Relay control stuff if you go that route and you want to control them through Python, or python code for controlling MD-01s/Spid rotators): https://github.com/vt-gs
Good Luck! Feel free to reach out (on or off list) if you have more questions about any of the above!
-Zach, KJ4QLP
P.S. I just realized the TL;DR version is about as long as the 'quick' version.....sorry.