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.
.
.
.
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. …
{Creation of br0 …}[/quote]
Continuing here with Solution, part b: Constraining a program / application’s IP traffic to a designated address …
I have combined / expanded / ‘enhanced’ the individually incompletely effective fixsrcip and force_bind together, creating runfromiptcpudp
Usage: runfromiptcpudp {ip address} {program}
e.g., per prior post: runfromiptcpudp 192.168.2.1 qbittorrent
Having pinned the program to an ip, traffic is corralled, and part c, what to do with the now identified traffic, can proceed.
Enhancements include:
- exiting if the specified IP doesn’t exist on an interface (rather than proceeding anyways!).
- more verbosity / better syslog’ging whereby a user can figure out what all a program is doing / IPs being used.
Degradation includes:
- fixsrcip is not IPv6 aware, while force_bind is. However, although the runfromiptcpudp combination doesn’t remove that awareness, it has not yet been extended to the fixsrcip base. Thus, until such experts apply their expertise to the code, IPv6 traffic is denied. (Which some may agree is no bad thing.)
Consequences include:
- traffic that escapes a program is either denied, or gets handled and appropriately scrubbed by the current whonix facility. e.g. Despite being so pinned, ktorrent leaks traffic (being a KDE program) - which still gets tor’ified.
- local network broadcasts get muted. (Since they become bound to an IP, not 0.0.0.0).
- A program is independently network encapsulated, without the overhead of LXC, and traffic sysloggable. Providing, consequently, an independent trapping / logging mechanism for 3rd party programs.
To make use of / install:
$ mkdir ~/local/src; cd ~/local/src
$ git clone GitHub - rAntOCauDgb/runfromiptcpudp: Constrain a (Linux) program to use a designated IP address (and, thus, interface).
$ ./INSTALL #(which merely calls make; make install.)
Having set up br0 as per prior message in this thread:
runfromiptcpudp 192.168.2.1 {program}
And traffic is corralled, as desired.
Next up, Solution, part c will be necessary gateway iptables changes to make the whole work.