How can you configure an app to use a specific interface? Is this like configuring proxy settings? Very few applications support this, right?
I was just thinking ahead.
Yes, because from there, with (1)… That means, once (1) is implemented… A VPN-only gateway for everything as opposed to selective would not be far away in development.
Nevermind that. It’s not important for implementing this proposal.
Yes. Set same place as proxy settings.
apt-get install ktorrent - settings / configure ktorrent / network / network interface - all | lo | eth0
apt-get install qbittorrent - tools / options / advanced / network interface (requires restart) - any interface | eth0
Can’t say I see such all that often. Also can’t remember to be able to say where all I do see it. Idea does make some sense, for many things, I suppose.
Ah! No, please do think ahead - it’s part of why I asked for comment.
I take your point, I think - if an interface, then all sorts of interoperability and flexibility comes along for the ride. e.g. Suppose VPNBOX were indeed another vm (connected by interface) - then it’s all routing. All -gateway needs to know is ‘this traffic’ ‘that way’. Conversely ‘from here’, let it go out clearnet. What the VPNBOX does internally is its business - complexity stays out of whonix.
Easy to add functionality / network capability, easy to remove, easy to constrain, and thus easy to prove ( security / isolation /whatever ).
Haven’t lost sight of this, but been sidetracked for a while.
Notes to date:
- qbittorrent has socks5 settings but they don’t work. They do with ktorrent. At least for my vpn provider. Tested on a kubuntu 14.04 vm, going out via default gw to an openwrt with openvpn connection.
- have seen note that despite socks5 setting, ktorrent does not use it for udp.
-
- this seems born out by netstat / wireshark. I see udp trying to go out directly, not via socks5. (Which seems bizarre, as the whole point of wanting socks5 is to tunnel udp, not just tcp.)
- curiously, I see no udp traffic reach gw for forwarding (*). Socks5 encapsulates udp within tcp?
'* I very much do not want to enable forwarding on gw, seems much the whole point / safeguard of whonix, having forwarding off.
Puzzled as to how best to proxy / forward these ‘excepted’ packets, though. rinet, socat, dante, mod_proxy, or squid, seem to be candidates, but it seems prudent to be the least whonix invasive possible.
e.g. It feels like a socks5 proxy on gw, since vpn is set up there / whonix is ‘invaded’ anyways, seems appropriate, but seems problematic to corral / identify which ws traffic so qualifies. i.e. with a known src/dst ip and dst port, candidate traffic is qualified. Without such, no way for gw to know which to treat regularly and which to except.
A model seems to be to watch the 9050 treatment, where I guess tor is tracking and doing the de/nat’ting, but not sure rinet has such capabilities.
Thoughts welcome.
Related [a “connect to other anonymity network than Tor directly” modification for Whonix-Gateway], FYI:
killyourtv managed to set up an I2PBOX. I.e. installing I2P
on the gateway and accessing it from the workstation. So users would be
using I2P directly rather than tunneling I2P through Tor.
I2PBOX - user → i2p → destination
[ without i2p over Tor (user → Tor → i2p → destination) ]
The Qubes Updates Proxy implementation uses interception for magic IP addresses. Qubes TemplateVMs upgrade through their ProxyVM. In case of let’s say a Debian template, the ProxyVM usually is sys-firewall and in case of whonix-gw template the ProxyVM is usually sys-whonix. So the firewall rules of sys-firewall and sys-whonix intercept traffic for 10.137.255.154 and redirect it to tinyproxy. On sys-whonix, tinyproxy runs as user tinyproxy and that user’s traffic is redirected to to Tor’s TransPort / DnsPort.
Interesting, all. Thank you!
Seems tinyproxy is http/s only, no udp. But demonstrates a viable path of the concept.
Have also come across ‘stone’ (socat light?) http://manpages.ubuntu.com/manpages/dapper/man1/stone.1.html which is also in the repos. “p stone - TCP/IP packet repeater in the application layer” Came across it while googling upd proxy (or something), which is to say, apparently udp capable.
I’m getting the sense that something ‘invasive’ (additional package/sw) on the gw is unavoidable. Drats. (i.e. Wanting to preserve all the goodness that has gone into gw design.) It is also feeling perhaps not unreasonable to enable forwarding - the iptables rules currently present seem rather nicely tight. However … it was not enabled for a reason, and I’d not like to casually break it that way. whonixcheck will evidently whine, at the least. (Not inappropriately so, just that such will alarm most users.)
It has occurred to me to vpn on the ws itself, however all such traffic will be torified, and the point of the thread is to be a good tor citizen and not torrent over tor.
It’s also occurred to me that udp ain’t gonna work noway, nohow. Any gw mechanism will need to nat the traffic, and so probably won’t know where to send any incoming responses. i.e. Only full on forwarding is going to do it, and that’s turned off. Which takes me back to enabling forwarding, in a similarly rigorous manner to what is already present.
None of this seems optimal. Perplexing. From a majority of users perspective, it seems like it oughta be easier / there oughta be a way. That it isn’t isn’t a deficiency of whonix, merely, it is what it is.
ip forwarding is not enabled because for the current Whonix design it’s
not required at all. If you need it for your setup however is a
different question. If you find a way to make a non-Whonix
VPN-Workstation work behind a non-Whonix VPN-Gateway however that would
be good. However, not a blocker.
whonixcheck is the least of your worries. It can easily be configured to
skip certain tests. See its config file. Such a config snippet could be
easily deployed as part of an optional package.
JonDonym does not have a Trans- or DnsPort and yet you can use JondoNym
with transparent proxying. See:
HowTo use JonDo like a transparent proxy
Is there some software to interface with a VPN server through a socks or
http proxy port interface? I.e. a software opening a local socks proxy
port, accepting connections there and then creating a connection to the
VPN server. If the gateway would just provide other socks ports that
result in different network paths that would seem like a better design.
Not exactly tun2socks or redsocks. (But good to know something like this
exists.)
The answer to which I’m trying to figure out.
Thus far, it feels like the answer is ‘yes’. I’m guessing here, but … I expect a fair bit of the reason for torrent / udp success is udp nat hole punching. With the dearth of sock5 udp capable relays, forwarding seems appropriate.
However … forwarding was turned off, presumably for good reason. [Yes, I caught your note - essentially, forwarding is turned off by default in Linux, ws didn’t need it, so the default was left unchanged.] But who knows what else will leak through, inadvertently, if forwarding enabled. Yet, can’t prove a negative. e.g. Scrubbing proxies like privoxy exist for a reason. Comments that reduce the size of that negative haystack would be useful.
Currently using a debian ws default gatewayed to an openwrt box with vpn running as a non/Whonix sanity check. Thus far any discrepancies have turned out to be non-Whonix related. e.g. Proxy not working … 2 days later happened to check non-Whonix to find it also not working. (What a supreme time waster that was.)
Thanks for the config snippet thought. Will bear that in mind. e.g. It’s feeling like whonix_firewall calling a post-run script is going to be needed. Additional iptables rules are going to be required.
whonixcheck is not the least of my worries, by any means. One of the things I have noticed / been sensitive to … whonix encapsulates a great deal of complexity for the non-technical end user. whonixcheck provides a very nice pass/fail as to something is wrong.
Thus the patch to note the undesired package to the user, even if it’s a duplicate message in the mean time, so the user can actually do something about it.
And also, thus, BTW, … updating the warning that ip forwarding is enabled to be in bold, red, would be useful.
Anywho, so part of the challenge here is to simplify things so that whonixcheck can do pass/fail/warn type things. Which is to say, as I work through this … I have to keep in mind to K.I.S.S. so the ultimate end user has easy implementation and pass/fail whonixcheck detection.
[quote]JonDonym does not have a Trans- or DnsPort and yet you can use JondoNym
with transparent proxying. See:
https://anonymous-proxy-servers.net/en/help/transocks.html[/quote]
So much complexity in all this. I’ve read so much, and so much of it is a blur. So much only half understood, and left behind as a result. Then, days later, if I happen to come across it again, more of it gels.
One thing I can say is … this all shouldn’t be this hard. My industry (‘computing’) is self-inflicting its own pain, disserving its customers. <sigh>
For example (a): several torrent clients will bind to a specific interface. Such a virtual interface, with its own IP, would provide an ip tables mechanism (by source address) to identify / segregate / separately route designated traffic.
- yet I have been unable to find a simple description to create such an interface. [Return to … material read several days prior, skipped at the time, and now can’t find again.] Various things like ‘ip tuntap add dev veth0 mode tap’ | ‘ip link set name veth0 dev dummy 0’ | ‘tunctl’ end up with a 2nd eth0 matching gw and routing falls apart.
- never mind such would be technical steps for a non-technical ws user to execute.
For example (b): Then I find that such interface bound clients don’t always use that interface. e.g. udp bypassing socks5 settings. Never mind if the interface isn’t up (triggering defaults to all interfaces), or the app has no interface or proxy configuration settings.
[quote] Is there some software to interface with a VPN server through a socks or
http proxy port interface? I.e. a software opening a local socks proxy
port, accepting connections there and then creating a connection to the
VPN server. If the gateway would just provide other socks ports that
result in different network paths that would seem like a better design.[/quote]
IIUC, in essence, the VPN, or OpenVPN, bundles within itself the ‘proxying’ capabilities. It has to - by very definition and point of a VPN. ‘proxying’ here, is essentially, forwarding on your behalf (aka NAT) - the very definition of proxying. Forwarding == relay … and we’re back to enabling ip forwarding. <sigh>
Thus, if such traffic could be corralled, all that should really be needed is a relay. This, then, is the basic problem: how to corral / identify appropriate traffic. e.g. As currently set, whonix permits the traffic it can, and roadblocks all other traffic. This is a wonderful thing. Problem is, to specifically identify the now to be permitted traffic, only, so that the unexpected traffic still gets roadblocked by native whonix.
My expected solution, thus far, is to also specify a socks5 proxy in the client app - thus providing a mechanism to identify / corral / route excepted traffic. [Return to above … turns out even setting an interface / socks / proxy, an app doesn’t always use it. <sigh>]
There are OpenVPN config settings for proxies / socks to use, but these are under hood fiddly bits I expect to be beyond the average target user of whonix. (It’s hard enough to discern which vpn providers also provide socks5 services, to add discerning that such provide an openvpn config file with such settings embedded, is too much.)
Even as it stands now, additional openvpn config settings are necessary to yank default gateways (providing a vpn kill switch) [yes, I know in theory a kill switch is inherent to whonix]. It’s not just ‘apt-get install openvpn’ ‘download vpn provider’s .conf file’ and ‘get on with your day’. If the vpn falls over, no gateway should be present until a user intervenes.
From what I can tell tun2socks doesn’t udp.
Briefly looked at redsocks, but too goofy for words. i.e. This should all be simpler, having to change the group nixes all the base user understanding of groups and permissions … there must be a better way.
It has been obvious that the correct way to do this all is to provide a tor equivalent alternate channel. Effecting that has just been a whole 'nuther story.
Seems like dante provided ‘socksify application’ is the next possibility to check out. (See: dearth of udp capable socks5 functionality.)
Which will have to be on ws, and leaves me puzzled as to how to ferret out such on gw to mangle appropriately. Seems like dante will need to run on both, and be transparent on one or the other. (Which should allow a dst=1080 redir 9050 alternate to the already in place whonix equivalent.)
Don’t know of such a relay, but if found, perhaps ip forwarding could then be turned off.
Well … nix danted (socksd) … Dante configuration -- Server chaining … “Forwarding of UDP is currently not supported by Dante.” Let alone … “Using authentication between two SOCKS servers is possible, but not currently supported.”
SS5?
Another option might be to not tamper with Whonix-Gateway at all. And
instead adding a VPN-Gateway. To the same internal network. Then the
Whonix-Workstation could be configured to by default use Whonix-Gateway
and selectively the VPN-Gateway for specific stuff.
Agreed, but this still makes the solution too complex.
Arguably, the whonix gw could then forward to the vpn gateway. Losing the vpn killswitch / whonix_firewall facility in the process. Not optimal. (Mind you, the openvpn config can effect the same via scripts / routing. I’ll post on that here at some point.)
However … still back to identifying and corralling the particular traffic to be so routed. And if that could be done, then the need for the vpn gateway is negated. (i.e. a ‘bypasstor’ tor equivalent.) e.g. equivalent to tcp 9050 redirect now, to, say, tcp/udp 1080, on both ws and gw I expect. One capturing, the other relaying.)
Equally arguable, would be a vpn client ws, also routing out the whonix gw as the whonix ws does. i.e. iptables identifiable source ip. I guess something like qemu would be equally topical.
It’s already irritating enough, and necessarily so, to have to run 2 vms. Expanding that to 3 or 4 seems excessive. ‘There oughta be a (simpler) law (way)!’
The beauty of whonix is K.I.S.S. and one stop shopping. The user shouldn’t have to remember to do activity a on vm a, and activity b on vm b. Especially as torrent as a file distribution facility seems likely to only grow.
[quote=“rAntOCauDgb, post:26, topic:1766”]For example (a): several torrent clients will bind to a specific interface. Such a virtual interface, with its own IP, would provide an ip tables mechanism (by source address) to identify / segregate / separately route designated traffic.
- yet I have been unable to find a simple description to create such an interface. [Return to … material read several days prior, skipped at the time, and now can’t find again.] Various things like ‘ip tuntap add dev veth0 mode tap’ | ‘ip link set name veth0 dev dummy 0’ | ‘tunctl’ end up with a 2nd eth0 matching gw and routing falls apart.
[/quote]
Journalling notes …
stone didn’t work for me … but I now realize the proxy was brain dead, so I’ll have to revisit it.
So, as I may have said earlier … turns out clients such as ktorrent and qbittorrent are leaky. Specifying a proxy, socks5 or otherwise, does not necessarily mean all traffic goes out that way. Be it to trackers, or udp. Let alone if the proxy is down or the interface doesn’t exist at start time. e.g. Set to use tun0, but openvpn not started at time of app start.
So, it would seem that the desired solution would be something that encapsulates a program, forcing all net communications (perhaps with rules, e.g. dns) to go out as specified. e.g. (Dante’s) socksify, socks and socksd.
However, as mentioned, turns out Dante won’t use authentication when going up stream. [Looking through the whonix wiki, it notes a dearth of free / open source socks5 proxies / relays - it doesn’t seem too likely that a paid vpn provider isn’t going to required authentication.] This is part of what I meant about the sadness of the industry … (e.g. Dante’s) web pages that promise intuitively obvious functionality … then excepting the important bits in the fine print.
Alternately, instead of firing up a socksd on the ws, and possibly a socks5 relay on the gw to go out the openvpn tun0, one might consider per app invocation via dante’s ‘socksify {app}’ facility.
However, ‘socksify ktorrent’ crashes withing seconds. Googling reveals dante just falls over at exception and silently crashes. ‘socksify bittorrent’ did stay up and pass traffic - except the traffic all goes out directly, not via the specified socks5. Evidently dante/socksd is not part of any solution.
Next seems tun2socks, which seems to handle the magic mentioned above (‘Such a virtual interface, with its own IP …’, answering ‘I have been unable to find a simple description to create such an interface’) - however, as it doesn’t encapsulate a program, it creates a tun0 interface to bind programs to, it is arguable that this is no better than appropriate iptables rules on the gw - never mind as mentioned above that clients don’t necessarily pass ALL traffic over the configured proxy / socks5 / interface. (And I believe the same is true in ktorrent when a DSCP value is specified.) i.e. In the end, the whonix gw has to corral / guarantee no non-excepted traffic out non-tor. Partial solutions, ws or otherwise, merely add complexity without delivering certainty.
tun2socks does appear to promise udp forwarding - IF the provided badvpn-udpgw (udp gateway) service is run on the ssh server. This seems to imply the vpn provider running badvpn-udpgw … not likely.
OTOH, if someone knows … could badvpn-udpgw be run on gw, and something there simply relay such traffic to the running openvpn tun0 interface? If so, how? (I assume socat?)
https://www.giac.org/paper/gsec/2326/understanding-implementing-socks-server-guide-set-socks-environment/104018 is a really nice explanatory document!
Perhaps I’m thinking / going about this the wrong way.
There are 2 issues:
-
Identifying / corralling net traffic.
-
Proxying (udp / socks5) / anonymizing such traffic.
-
Is inherently satisfied by the use of a trusted (openvpn) vpn provider.
-
Docker? (Force all net traffic to a segregated ip that can then be identified and routed by iptables?)
e.g. Ramblings from Jessie: How to Route Traffic through a Tor Docker container
Docker seems over the top, in terms of heft. Not much different than running another entire vm (within the ws vm, even). [But the idea of lightweight containers seems attractive. One comment I saw noted LXC as entire OS’ and docker as single application’able. I noted the idea of a docker-whonix in the forum/wiki somewhere. Don’t know that I saw the thought of a docker app within whonix. torbrowser, icedove, torchat, with zero post-run footprint, seems like it would appeal.]
linux - How to use different network interfaces for different processes? - Super User seems topical, however I gave up on making it work. Multiple ‘ip link’ commands needed, bridge-utils, and script complexity; must be root to create the interfaces.
-
it’s initial attractiveness, however, is that it is scripting - not another package to install, and not binary/source hosted on ‘strange’ servers.
-
it is also limiting the containerization (and thus complexity and heft) to the network only, via network namespaces (ip netns). But brings bridging and other manual steps that I think would make the result unacceptable to whonix.
I have come across Binding applications to a specific IP | Daniel Lange's blog , however, this is compiling downloaded code, as opposed to a repository. e.g. http://www.ryde.net/code/bind.c.txt, Index of /lennart/projects/fixsrcip, http://www.semicomplete.com/projects/liboverride/, netjail - Browse /netjail/1.0.0 at SourceForge.net, or http://wari.mckay.com/~rm/bindhack.c.txt. In the first link, not even a page of code, in the last, perhaps two pages - most of it whitespace. Which is to say, easily code reviewed for unacceptable behaviour.
What is the general ‘whonix’ attitude toward such code? Assume GPL’ed/FOSS’ed, and so on. With no repository, no updates (but ‘this’ is a solved problem). Would ‘whonix’ be willing to take in a copy of such code and incorporate it?
- not so much asking about this specific code as is even the very idea at all acceptable?
To review (this aspect) - the goal is to be able to identify, and so segregate, traffic. Be it for further control, processing, or manglement. This seems easiest if the app could be forced to run under a different ip address (containerized). Thus ip leaks (despite proxy settings) are contained, and could be forwarded to a local socks proxy (e.g. dante, if it worked), which forwards to a gw relay (e.g. stone).
- not saying the additional processing is to be effected at the moment, or even optimal, merely that by isolating the traffic to its own ip, all such goodness is possible, when deemed desirable. [e.g. optimal - if dante worked, could easily be more efficient, for all I know, to forward the app to a rinet’ed port to dante running on the gw, as happens with tor now.]
In poking about containerization, I got to Flockport and encountered firejail. https://firejail.wordpress.com/ , GitHub - netblue30/firejail: Linux namespaces and seccomp-bpf sandbox Packages are downloadable at Download | Firejail
/etc/firejail contains parameter files, including:
Mathematica.profile
audacious.profile
bitlbee.profile
chromium-browser.profile
chromium.profile
clementine.profile
conkeror.profile
deadbeef.profile
deluge.profile
dnscrypt-proxy.profile
dropbox.profile
empathy.profile
evince.profile
fbreader.profile
filezilla.profile
firefox.profile
generic.profile
gnome-mplayer.profile
google-chrome-beta.profile
google-chrome-stable.profile
google-chrome-unstable.profile
google-chrome.profile
hexchat.profile
icecat.profile
icedove.profile
iceweasel.profile
kmail.profile
ktorrent.profile
login.users
mathematica.profile
midori.profile
mupen64plus.profile
opera-beta.profile
opera.profile
palemoon.profile
parole.profile
pidgin.profile
qbittorrent.profile
quassel.profile
rhythmbox.profile
rtorrent.profile
seamonkey-bin.profile
seamonkey.profile
server.profile
skype.profile
spotify.profile
steam.profile
telegram.profile
thunderbird.profile
totem.profile
transmission-gtk.profile
transmission-qt.profile
uget-gtk.profile
unbound.profile
vlc.profile
weechat-curses.profile
weechat.profile
wine.profile
xchat.profile
e.g. firejail qbittorrent
- seemingly presenting the ability to containerize / isolate / segregate most any app to the extent deemed prudent. e.g. memory limiting.
Installation and use really was as K.I.S.S. as download, gdebi <package> ; firejail <your favourite app>
A default profile exists, and --noprofile is possible.
In this case a segregated network stack, and separate ip, is possible via:
- firejail --net=eth0 --ip=10.152.152.111 qbittorrent
– Note: I ran into problems of inaccessible files (in my non-default locations), until I commented out ‘noroot’ in the qbittorrent.profile. (Worst case in all of this is no worse than running the app natively. i.e. Without further 'whonix’ization.)
Sadly, ktorrent would not run - complaints about lack of access to dbus. (I see the problem has been noted - presumably this will be fixed at some uknown, unpredictable, future time.)
Curiously, there is a kmail profile, so dbus must not be getting its finger into each and every kde app.
So:
- nailing down an app to run under a unique ip seems desirable. [iptables -A FORWARD -i eth1 -o tun0 -s 10.152.152.111 -j ACCEPT]
- what is the whonix project’s attitude towards rarer source code? e.g. Just sucking in the file / original author not themselves doing so (thus no implied promise of keeping it updated).
- is there value to containerization to the whonix project such that it would consider putting any time or energy into establishing the facility?
- if firejail at all whonix topical?
We don’t have any compiled code for now. Nor any policy for this.
The closest to such a policy is this one:
Whonix firejail discussion:
Something super simple to answer “everything from the workstation is
always routed through Tor” becomes something less simple and more
insecure sounding “everything from the workstation is always routed
through Tor unless you install that package”.
/cc @HulaHoop since this involves compiled code, policy, firejail and
contributions.
Agree, but then, that’s why it’s optional.
However … whonix is already there. e.g. The enabling of VPN in whonix_firewall, so that bridge has already been crossed. In the sense of needing user intervention. (Given the mass of material already present about proxy/socks this way vs that way, before or after tor, the idea of ‘excepted tor’ traffic isn’t an onerous expansion.)
Getting to this tor-excepted traffic facility will be similar, and one, similarly user chosen, step beyond current VPN enablement - probably a whonix_firewall.d post-whonix_firewall-50user_run type call.
And some anondist equivalents. e.g. qbittorrent → qbittorrent.nontor → (sg vpnnet; qbittorrent.clearnet)
firejail testing fails for me at a ‘seamless user use’ (and works) level.
Have come across Index of /lennart/projects/fixsrcip which also fails, and http://freecode.com/projects/force_bind (see source tar.gz link top right) - which looks more promising. (netstat shows ip bound, but no net traffic at moment - I’ve probably played too much / need a reboot.)
It’s a single.c file, small, all of 113 lines long. Guts (whitespace cut):
[Accompanying LICENSE file notes GPL’ed.]
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
{
int err;
struct sockaddr new;
struct sockaddr_in *sa4;
struct sockaddr_in6 *sa6;
void *p = NULL;
unsigned short *pport = NULL;
init();
if ((addr->sa_family != AF_INET) && (addr->sa_family != AF_INET6)) {
syslog(LOG_INFO, “force_bind: unsupported family=%u!\n”,
addr->sa_family);
return old_bind(sockfd, addr, addrlen);
}
memcpy(&new, addr, sizeof(struct sockaddr));
switch (new.sa_family) {
case AF_INET:
sa4 = (struct sockaddr_in *) &new;
p = &sa4->sin_addr;
pport = &sa4->sin_port;
break;
case AF_INET6:
sa6 = (struct sockaddr_in6 *) &new;
p = &sa6->sin6_addr.s6_addr;
pport = &sa6->sin6_port;
break;
}
if (force_address != NULL) {
err = inet_pton(new.sa_family, force_address, p);
if (err != 1) {
syslog(LOG_INFO, “force_bind: cannot convert [%s] (%d)!\n”,
force_address, err);
return old_bind(sockfd, addr, addrlen);
}
}
if (force_port != -1)
*pport = htons(force_port);
return old_bind(sockfd, &new, addrlen);
}
Not advocating it, yet, further testing to do, but you can see why I asked about the acceptability of such files. Small, easily code reviewed, and not really ‘big enough’ for a ‘maintainer’ once instantiated.
Probably not much different than a bash snippet, but it is code / needs compiling - and I have no familiarity with how projects manage such. Thus my question.