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

Nathan of Guardian nathan at guardianproject.info
Thu Oct 23 16:39:17 EDT 2014



> ----- 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?

Yes.

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

Agreed. The code really is in "OMG it worked!" state right now.

> > 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?

Yes.
 
> 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.

Agreed - I think we can grab those packets within the tun2socks code
somewhere, that would otherwise route them to the udpgw-client.

 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.

Right.

> 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.

Happy to fork tun2socks and tune it for our needs. I don't think we
should start from scratch, and the code definitely needs to be C/native
for performance reasons.

> 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.

Yes, always happy to have that. We really need to expand the number of
people working Orbot, be it the UI or complicated new pieces like the
VPN.

> 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

We do use the NDK now, just not in the traditional ndk-build manner. The
external/Makefile is quite a complicated piece of magic, so I am not
that excited about messing with it unless there is a good reasons.

The primary task right now is updated it to support the -PIE flags for
Android L.

> Gradle
> though it is marginally faster than ant. You do get a better integration
> with IntelliJ though.

Adding Gradle support would be a good thing, as long as we can also
still support Eclipse folks.


More information about the Guardian-dev mailing list