Moving a private thread with Delyan over to guardian-dev so we can continue it here...
----- 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? (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 [email protected] _______________________________________________ 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]
