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

[Delyan Kratunov]

> > 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.
> 
> Maybe using a local udpgw-client to a local udpgw daemon isn't looking
> so bad now?

And hacking it to use transparent-dns with Tor's resolver? Too many moving 
pieces for my liking but it might be possible. I'm not a fan of the fact that 
all udp traffic will go in there and.. be lost without a meaningful message. 
(Right now, UDP traffic gets ICMP rejected if you don't specify udpgw; Ideally, 
that will still happen to everything but DNS and we'd warn the user that Tor 
doesn't support UDP)

> > 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.
> 
> Would doing this in Java, help at all, considering we already have
> persistent state in the OrbotVPNService?

It might, but parsing the packets on both sides of the divide stands out as 
really inefficient - especially because it makes the design a bit convoluted 
(the fd-to-fd bridge in Java doesn't sound nice).

Actually, thinking about it some more, concurrent writes from multiple threads 
should be safe on a tun fd. There might be some locking in the kernel, but who 
cares, my concurrent situation will be at the level of spawn-a-thread-pool. 
Basically: parse DNS request in the read thread, send to the thread pool; 
thread pool worker redirects request to Tor, writes translated response 
directly to the tun fd.

I'll try to find some time to prototype this, it sounds like it might just 
work.

-- Delyan