You absolutely shouldn't do that because a vulnerability in the kernel can be immediately escalated into decloaking your real IP. /s

(TBF this is presumably why parent specified that proxying ought to happen on separate hardware.)

> a vulnerability in the kernel can be immediately escalated into decloaking your real IP

Not necessarily IMO... if you create a network namespace that can only communicate with mullvad, and then run the VM inside that... even owning the entire VM and escaping it doesn't help you... you would now have to exploit the host kernel as well, which to me is basically just as good as it being separate hardware in the first place.

By the time someone has pulled off a VM escape I think it's safe to assume they're akin to a state level actor and a network namespace isn't going to stop them.

That said, did you perhaps miss the /s tag?

My threat model does not include state level actors, I don't think it's feasible for people to adequately protect themselves from most of them.