Working notes … continuing …
[quote]whonix, torrents, and being a good tor citizen
There are 2 issues:
- Identifying / corralling net traffic.
- Proxying (udp / socks5) / anonymizing such traffic.
For 2: Internally. whonix already has several proxies in play, be it browser, e-mail, or generally. By definition, and desire, all go through tor. It is the point of using whonix. Yet not all programs have settings to set proxies, http, socks4|5, or otherwise, so there is no easy or universal way by which to except particular traffic beside tor rather than through it.
Except, that is, for using a vpn, which is by definition a proxy, and routing all traffic through it. Yes, this is trusting that the vpn provider (truly) is anonymous, or sufficiently so. However, anonymity is -the- selling feature of many VPNs. OTOH … no way to prove a negative. It’s anonymous, until it isn’t, and by then it’s too late. Hopefully word will get out on providers that aren’t, and hopefully all concerned are paying attention when it does.
But then, I suppose the possibility is no worse than the possibility of a compromised tor node or honey trap.
So, for 2 - VPN. From a trusted provider.
Aside from using a VPN, the particulars of effecting non-tor traffic on whonix will be discussed another time. It will likely involve iptables rules, routing, and perhaps even policy based routing.
For 1, the challenge of identifying particular traffic so it may be constrained as desired, outside of tor, yet within the vpn (else one wouldn’t be using whonix at all) …
Solution, part a: Create and use an additional interface, and associated IP address, and thus provide breadcrumbs by which the whonix gateway can identify, permit, and route, particular traffic, and only that particular traffic, directly to the VPN.
One way to do this would be to create an additional virtualbox, internal network only, interface on both the whonix workstation, and gateway.
However, I instead propose creating a virtual interface on workstation only. Thus only users interested in this particular facility, and having manually installed it, are affected, and only when so running such designated programs. Impact is specific, leaving all other whonix safeguards in place, and in play.
First - # apt-get install bridge-utils
brctl addbr br0
brctl addif br0 eth0
ip tuntap add dev tap0 mode tap
ifconfig tap0 192.168.2.1 up
brctl addif br0 tap0
- mv /etc/network/interfaces.d/30_non-qubes-whonix /etc/network
- this mv probably shouldn’t be needed / isn’t appropriate, but I haven’t gotten it to work by merely adding the tap0 and br0 bits to a separate file such as /etc/network/interfaces.d/50_user_add_whonix.
- append to /etc/network/interfaces:
iface lo inet loopback
iface eth0 inet manual
iface tap0 inet manual
pre-up ip tuntap add dev tap0 mode tap
pre-up ip addr add 192.168.2.1/24 dev tap0
up ip link set dev tap0 up
iface br0 inet static
bridge_ports eth0 tap0
#ip tuntap add dev tap0 mode tap
#ifconfig tap0 192.168.1.1 up
#brctl addif br0 tap0
- alternately, put the above in something like /etc/network/interfaces.d/50_user_add_whonix, but I haven’t tested that.
Leaving a distinct ip address (192.168.2.1) / interface (tap0) upon which to set a designated program to use, and by which the whonix gateway can discern such traffic.
e.g. Some torrent clients have a setting to designate the interface, or ip address, to use.
ping 192.168.2.1 # - no response, expected.
Modify or create a file in /etc/whonix_firewall.d, such as 50_user_conf, creating or modifying a section to look like:
## Destinations you don not want routed through the VPN.
## 10.0.2.2/24: VirtualBox DHCP
#LOCAL_NET=“127.0.0.0/8 10.152.152.0/24 10.0.2.2/24”
route add -net 192.168.2.0/24 dev eth1
Automatically - edit /etc/network/interfaces.d/30_non-qubes-whonix:
- append a line to the ‘iface eth inet static’ section:
<tab> up route add -net 192.168.2.0/24 gw 10.152.152.11
Alternately: Add ‘route add -net 192.168.2.0/24 gw 10.152.152.11’ to 50_user_conf above, rather than messing with files under /etc/network.
Run “whonix_firewall” to manually effect the change, without rebooting.
ping 10.152.152.11 # - should work, as expected.
ping 192.168.2.1 # - should work, now.
Next up, Solution, part b combining the individually incompletely effective fixsrcip and force_bind together, to be more completely effective.
And beyond that, Solution, part c will be necessary gateway iptables changes to make the whole work.
Suggestions/enhancements most certainly welcome. Especially for anything suggested that’s actually inadvertently rather ‘dumb’ -particularly, from a whonix community / purpose perspective. Especially anything that pertains to where best to place / plug in this stuff for other whonix users so interested, to find.