I set the VPN tunnel from the VPS to deny everything to the internal network by default, then put the services that need to be accessed on the allow list in the firewall. So the VPN endpoint from the VPS can only hit the very specific IPs/ports/protocols that were explicitly allowed. There is still the possibility of a compromise chain of VPS->service->container/VM->hypervisor->internal network access, but I feel comfortable with those layers.

You could also setup an IDS such as Snort to pick up on that exploit traffic between the services and internal VPN endpoint if extra security is necessary on top of fail2ban and log alerts on the VPS.

Yeah, Tesla is certainly not the first ones to have this design or issues with it:

Texas man, dog die after being trapped in Corvette

The headline is misleading. Roku didn’t get hacked and leak accounts. There were ~15000 customers that had accounts accessed due to credential stuffing. Aka, they reused passwords on other sites that had leaks and hackers tried those credentials on their Roku accounts and got into them.

Awesome, glad that helped and thanks for the update!

I wonder if there is something going on with scheduling waits that is impacting the audio process. I would first try upping the CPU units in Processors->Advanced settings for the VM, bump it to something like 200. Otherwise, if you over subscribing your CPU cores, try temporarily dropping the number of cores subbed out to your VMs to match the physical host to see if it helps, since that could help resolve scheduling issues as well.