[guardian-dev] Fwd: Re: Orbot VPN service

[Delyan Kratunov]

On Saturday, October 25, 2014 08:34:49 PM Nathan of Guardian wrote:
> On Sat, Oct 25, 2014, at 05:47 PM, Delyan Kratunov wrote:
> > > (adding /jni to git now)
> > 
> > Except, you're missing Android.mk from external/badvpn. :)
> > 
> > /home/delyan/dev/orbot/jni/Android.mk:2: ../external/badvpn/Android.mk:
> > No
> > such file or directory
> 
> Alright, looks like it is there now:
> https://github.com/guardianproject/badvpn/commits/master

Also missing are SLF4J, appcompat's project structure and x86 binaries. I've 
patched all of the above locally (the x86 is useful if you want to use an 
emulator), so I am making some progress now. 

Unfortunately, this is harder than I originally envisioned. Between the 
*hilarious* Android bug where the VPN service crashing means you can't 
reestablish it (prepare() returns null, not sure if that means we can just 
establish()) and the hilarity of the my-process-gets-all-device-traffic-but-
cannot-open-raw-sockets state of affairs, I'm mildly stuck atm. 

In particular, I can redirect DNS requests to Tor's resolver but that requires 
opening a new socket from the tun2socks layer. This socket is to a loopback 
address (Tor's resolver), so doesn't require whitelisting (good) but it can't 
be raw since you need effective uid == 0 for that (bad). (If I could use raw 
sockets, I could trick the resolver to pass the response to the original 
request-er, skipping the translation layer on the way back.) The key 
misunderstanding I had was that I thought writes to the tun device can also go 
to loopback addresses. They can't. :/

Which means I'll have to hold state in my little DNS layer, which means 
separate threads so I don't stop the flow of the VPN traffic, which means 
significant amounts of complexity. It'll take me a bit of time to come up with 
all of this crap, errr... code.
 
Userspace port forwarding. Definitely something I have not written before. 
There's a first for everything, I guess.

--Delyan