Thank you. This was great advice. I ended using a debian-11-minimal template and qtunnel package to create app-specific VPN qube chains with random entry -> random exit profiles. Then, I used qubes-app-shutdown-idle package in my VPN template to create a qubes service for shutting down the VPN from exit to entry after the app qube is closed and the VPN chain idles.
Anything else I might be missing?
sweet. np. nice flow. have you checked for leaks? how's it working?
Throughput wise it performs well most of the time, though, random server entry|exit can give poor performance. Need to write something for pulling load data from vpn providers over tor, then assembling optimized chains for each application instance.
Also, working on using a disposable template but disposable instances are not really built for connecting to each other. Got to be a workaround, and that would save on template size if I wanted to port something with low specs or put together random/complex/variable length chains on the fly.
Haven’t looked too deep at leakage besides monitoring the traffic from each qube. What do you recommend?
Wouldn’t it be grand if we didn’t live in surveillance states? I have little to hide but even less I want to share
well said. i'd recommend something simple to check for leaks. run curl https://ifconfig.me or curl --interface
in the vpn qube with the VPN connected, killswitch engaged and not and see what you get.
