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

[Nathan of Guardian]

Moving a private thread with Delyan over to guardian-dev so we can
continue it here...

----- Original message -----
From: Delyan Kratunov <delyan at delyan.me>
To: Nathan of Guardian <nathan at guardianproject.info>
Subject: Re: Orbot VPN service
Date: Wed, 22 Oct 2014 00:15:33 -0700

On Tue, Oct 21, 2014 at 9:41 AM, Nathan of Guardian <
nathan at guardianproject.info> wrote:
>
> Here is the code in progress, that now used the badvpn tun2socks library
> to push Android VPNService packets into the Tor socks port:
> https://github.com/n8fr8/orbot/tree/dev_orbotvpn
>
> It also runs its own mini SOCKS server that handles Tor's connections
> itself, and marks them as "protected" so they are not routed through the
> VPN.
>

As is usually the case, I had the epiphany that you can just route back
Tor
traffic to the VPN process shortly after pressing "Send". :)

To verify, the chain you have in those commits is Apps -> VpnService
(10.0.0.1) -> Tor SOCKS via tun2socks -> VpnService ProxyServer ->
Internet, right?

(btw, the VpnService & ProxyServer interaction is less than ideal, it's
quite difficult to follow)


> The main open issue I have now is DNS... you can't set the Android DNS
> to a non-standard port like 5400 (Tor's DNS), you can only set an IP
> Address... so we need to use tun2socks udgpw feature which routes UDP
> through TCP, and somehow connect that to a DNS server somewhere.
>

Ugh, I thought Tor implemented the full SOCKS5 protocol, including UDP
ASSOCIATE, but reading more about it, it only looks at TCP sessions.
Correct?

I think there is a way to do this without udpgw but it requires
something
smarter than tun2socks. Say we give the VpnService.Builder a DNS server
a
made up IP address (e.g., 10.0.0.254) - we can just claim the 10.0.0.0/8
block for the tunnel. We can then filter out all packets for 10.0.0.254
(optionally, only the ones to port 53) from the interface stream and
give
them to Tor's DNS resolver instead. We then get the response the same
way
(from the interface), rewrite the source and destination and dump it
back
into the interface. Should be relatively easy to add this directly to
tun2socks or via some sort of lightweight filter layer.

On a side note, given Tor's latency, how important do you think it is to
use tun2socks? Rolling our own layer (or forking tun2socks of course)
would
allow us to deal with UDP connections in a saner way (e.g., put up
warning
notifications, identify the app, etc) and the overhead of doing that
shouldn't be visible given how long the packets spend in flight.

Last thing - how open are you do UI changes and/or code refactors? I've
seen a few thorny parts and besides a UI update is well in order now
(you
kinda skipped Holo :)). It's also a good way to get to know the
codebase.

Last-last thing - how about some build system messing about? E.g., using
the NDK build system to build all native dependencies (shouldn't be too
difficult, it's just Makefiles after all). There's little benefit in
Gradle
though it is marginally faster than ant. You do get a better integration
with IntelliJ though.

Best,
-- Delyan


-- 
  Nathan of Guardian
  nathan at guardianproject.info