On Tue, May 13, 2014 at 8:40 PM, Andy Isaacson adi@hexapodia.org wrote:
Anecdotally, the GFW blocks OpenVPN endpoints as well.
You need to specify context... access *to* ovpn nodes?, which is moot because that is not the deployment specified here in diagram... you already guaranteed access via the localhost exit you can already reach, (or via the exit op's clear forward path to their off exit box ovpn node). Or *from* ovpn nodes?... well as before, if your node is in gfw area trying to get out, or is outside trying to get in, it really doesn't matter, gfw will block exit or ovpn as it will.
So, this is not about such gfw things. It's about enabling quite some other users other means to get around silly ip based blocklists derived from the consensus, the tor dns query thing, or poor management models by the site the user wishes to access, etc. We provide tor exits exact so users can get around stuff, so adding in an ovpn on a spare ip is no philosophical difference there. Yes, it is a fuck you to old way of playing nice by saying "here's all our public nodes, block us", and it might cost $few more a month for the ip, and eat some cpu on localhost, but that's about it. If it helps some users it's worth doing, to each operators own desire.
Same goes for binding/routing your tor exit out a different ip than your OR ip. Except that using OpenVPN can permit other protocols for help of user than only TCP.