I've looked up previous people asking similar questions, but have yet to get a straight answer that will work for my given situation, so here goes..
I'm running on Linux (Fedora 22) and have a VPN service I pay for, howver I only need specific programs to use the VPN for their internet traffic, and can use my standard ISP connection for everything else (ie, web browsing, etc)
We'll make this simple and limit it to the most used program, World of Warcraft, which is being run through WINE.
Now, I have a VPN setup via the network interface so that all of my traffic through enp10s0(my computers weird name for eth0) can be tunneled through the VPN service, however, I only need specific programs (or ports those programs use, to be specific) to go through the VPN.
How do I setup the tunnel, and have it only route the ports needed through the VPN, while keeping everything else un-routed?
Best Answer
What you are asking for does not exist. This is why you are dissatisfied with the answers you found (some of them, possibly, being mine): all of them have suggested workarounds, not a genuine solution, either simple or complex.
Let me explain. Routing in all OSes is determined by destination address: you may very well have several routes, but the choice between them is not based upon the application invoking the connection, but simply upon the destination address. Full stop.
Let me give you a non-trivial example. When a VPN client has established a connection to its server, it is still possible to route a connection to a given site, say example.org, outside the VPN. But all applications trying to reach that special address will be routed outside the VPN: you cannot have some applications going to example.org thru the VPN while other apps pass outside the VPN.
The situation becomes richer with the Linux kernel, which allows source routing: this means you can have two or more routing tables, and the choice between them is based upon the source address, not the destination address.
A non-trivial example: my pc has two outside lines, with two distinct public IPs. It can be contacted thru either interface, and it is important that my replies to a given connection go thru the same interface that connection came in thru: otherwise they will be discarded as irrelevant when they reach the person who initiated the connection. This is source routing.
Fair enough, what about connections that we start? Some apps allow you to specify the bind address, like the openssh client:
For them, there is no problem in having one instance going thru the VPN (say, routing table 1) while another instance will go outside the VPN (say routing table 2). But other apps, like Firefox, not only are notoriously difficult to bind to a specific source ip address (but see here for a very smart workaround), but also are mean and nasty in that they will not allow you to have two copies of themselves running simultaneously, each bound to a different source address. In other words, while thanks to the trick referenced above you can oblige one instance to bind to a source address of your choice, then you cannot have another version of it binding to the other source address.
This explains why we use workarounds: they are all based upon the same idea, that they work with a separate network stack than the rest of the pc. So you can have, in decreasing approximate order of complexity, VMs, dockers, containers, namespaces. In each of them you will have one or more routing tables, but you can have several instances of each (VM/dockers/containers/namespaces) and you can also admix them freely, each one of them running its own app like Firefox happily separated from the other ones.
Perhaps you are still interested in one of the workarounds?
EDIT:
The simplest work-around is a network namespace. The script below handles all necessary aspects of a NNS: put it in a file (you pick your name, I generally use
newns
, but you do whatever you prefer) in/usr/local/bin
, thenchmod 755 FILE_NAME
, and you can use it as follows:It will open an
xterm
for you (that's because I like xterm to work, but you can change it if you wish to use anything else), which belongs to the new namespace. From inside the xterm you may, if you wish, start your vpn, and then start your game. You may easily check that you are using the VPN thru the following command:which returns you your public IP. After setting up the VPN in the xterm, you may check that your public IP is different in your other windows. You may open up to 254 xterms, with 254 different NNSes, and different connections.
If you want, you can even start a whole desktop inside the new network namespace, by means of
then you can search for it using Alt+Ctrl+Fn, where Fn is one of F1,F2,....-
I need to add one caveat: DNS handling inside namespaces is a bit buggy, be patient.