> ----- Original message ----- > From: Delyan Kratunov <[email protected]> > To: Nathan of Guardian <[email protected]> > 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 < > [email protected]> 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. _______________________________________________ Guardian-dev mailing list Post: [email protected] List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: [email protected] Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/archive%40mail-archive.com You are subscribed as: [email protected]
