1 |
On Sat, Jul 16, 2022 at 6:57 AM Dale <rdalek1967@×××××.com> wrote: |
2 |
> |
3 |
> I also want to use a VPN but only for some programs. Example, I want |
4 |
> Ktorrent and a couple Firefox profiles to use VPNs but at least one |
5 |
> Firefox profile I want to remain outside of VPN. |
6 |
|
7 |
I can't keep up with which VPNs are more or less scummy at any moment |
8 |
in time, but I will comment on this bit and on the concept in general. |
9 |
|
10 |
Controlling which HOSTS use a VPN is pretty straightforward via the |
11 |
routing tables. If you have a decent DHCP server and can issue |
12 |
routers to individual hosts you can do it that way (most consumer |
13 |
routers probably won't support this with their built-in DHCP). |
14 |
|
15 |
Controlling it at the software level is a real PITA. On an OS like |
16 |
Windows I don't think it is even possible unless via SOCKS or |
17 |
whatever. On Linux you can do it with iproute2 and often netfilter is |
18 |
needed as well. Look up policy-based routing, and be prepared to do |
19 |
some studying. I'll tell you right now you probably don't want to do |
20 |
it this way. I think for outbound-only connections it isn't as hard |
21 |
to do it at a uid level, so if you run software under different uids |
22 |
that would make it easier. If you want to handle inbound connections |
23 |
on servers and have the replies not go out over the normal |
24 |
destination-based route then you need to mark the connections using |
25 |
netfilter and then set a policy routing for the replies, otherwise |
26 |
your reply traffic will go out over the wrong router and have the |
27 |
wrong IP and the other end won't associate it with the connection. I |
28 |
imagine you run into the same problems with any kind of use of NAT for |
29 |
inbound forwarded traffic in a multi-homed situation. |
30 |
|
31 |
Controlling routes by container is also a potential issue. If you're |
32 |
using a container technology that uses virtual interfaces that get |
33 |
their own IPs/routing/etc then it is easy - same as host-level |
34 |
routing. If you're using something like Docker/k8s where it wants all |
35 |
the outbound traffic to just go out from the host then it can be a |
36 |
pain. I think they can do macvlan but I think that has its own |
37 |
issues. That is actually something I'm trying to figure out for |
38 |
myself. |
39 |
|
40 |
Ok, topic change: the threat model. As others have pointed out, the |
41 |
VPN changes WHO can see your traffic, and that's mainly it. I think |
42 |
this is still a useful consideration, because in many places your ISP |
43 |
is chosen by where you live, but with a VPN provider you can choose |
44 |
anyone you want. The ISP has no reason to earn your trust because |
45 |
you're a captive audience, while a VPN provider who gets outed for |
46 |
leaking private info basically is out of business. So I think there |
47 |
is a benefit. However, you're going to be reducing your risk of being |
48 |
traced by private companies here, like advertisers, intellectual |
49 |
property enforcement companies, and so on. If you're worried about |
50 |
the NSA or some other state-level actor then you need to do a LOT more |
51 |
to evade them. I just assume the NSA has root on all my hosts |
52 |
already, and I wish that they'd at least offer to sell backups of my |
53 |
systems back to me so that I didn't need to keep my own... :) |
54 |
|
55 |
-- |
56 |
Rich |