Proper opsec is you blackhole all traffic when the vpn isn’t active.
I can't believe someone can literally destroy its life for BTC. Imagine his family and close friends. His parents probably thought he was a tech wizard genius. And now he destroyed his reputation, his employer's, and he'll be behind bars for quite a few years. I hope he doesn't have kids.
And picture: he could have been the guy who did a great job "fixing" employer's lack of security. Have that on his resume, tell lessons learned on real world practice.
Why the hell would he even think about the FBI route in the first place?
This is not really a thing. It's very hard to get recognition or even a shared understanding of the risk mitigation. As everything else in the world, it's way easier to reward someone for things that happen (new functionality) than rewarding someone for preventing things happening (hack).
One was to strike a good balance here is a security roadmap. Write down the adverse outcomes that would be a problem for your business. Write down the possible mitigations, how much they cost to implement and how strong they are. Propose a plan that continuously improves security in a cost effective way. Highlight significant things you can’t defend against yet, and explain how you could address them sooner with more funding. Show the plan to leadership, get it approved, and get to work. Every month / quarter / sprint, write down what you did, show where you are the roadmap, and adjust the roadmap to reflect any changes in business priorities.
Let's say you have a Wireguard configuration, wg0 which runs off ens0. If your wg0 connection dies, for whatever reason (let's say the remote server goes down), your computer falls back to ens0.
What does "not having a connection to be maintained" change about this?
I guess, too much magic automation on top of this is not the best thing for opsec, including having some daemon that can disable your wireguard interface or reconfigure the network if it doesn't like something. You want your network configuration to be static and predictable, regardless of some temporary failures. Basic wireguard kernel primitives will give you that.
So... You'd have to do work to properly blackhole traffic when wg0 goes down. However long it takes to reconnect, you still will automatically fall back down to ens0 while it's down unless you do something to stop that.
Packets are always delivered to wg interface as long as it is marked as 'UP' (or 'enabled', if 'UP' sounds to you like having anything to do with some kind of "connection") when your routing table directs them there.
When they hit the wg interface when the other endpoint is unreachable for whatever reason, they are either dropped, or queued, or get ICMP unreachable response generated for them, depending on situation. This is done internally by wireguard.
If you wanted to not go through wg0 (whether it can reach the other wireguard peer or not) you'd have to remove the routes first.
https://www.wireguard.com/netns/
In brief, you move your physical eth/wlan device to a new namespace, and create the wg device in that namespace but then move it to the init ns.
By default (and without root) everything will use the init ns and only be able to reach the physical device via wg. If it's not active, nothing will even reach your NIC, nevermind the internet.