This would be a nice-to-have, but not a priority for Tor. OTOH, that functionality is more vital for i2p, who are exploring the idea of integrating into Tor's PT system: https://trac.torproject.org/projects/tor/ticket/10629 Also, right now, no PT servers can actually traverse NAT. In the future, we plan to add WebRTC capability to flashproxy, which will include NAT traversal: https://trac.torproject.org/projects/tor/ticket/5578 If you want to see it done faster, feel free to help us/them out, or find someone where I can apply for funding for it. X On 20/01/14 19:24, Juan Berner wrote:
Yes, but the point of flash proxies, is to use them as bridges, what I meant is to allow OR's behind NAT to be relays or even exit nodes.
2014/1/20 David Fifield <david@bamsoftware.com>
On Mon, Jan 20, 2014 at 05:00:38PM -0200, Juan Berner wrote:
1) Allow NAT clients to be TOR relay nodes (even maybe exit nodes) , this would be done using a queue system, possibly in a hidden service but not necessary, where nat relay nodes can query what tor clients want to connect to them and initiate the connection. This would allow more nodes in the TOR network.
This is how flash proxy works. Clients register themselves as needing a connection, and then proxies connect to the clients. (The problem is that many *clients* are also behind NAT, and then it doesn't work so well.)
You can run a flash proxy just by going to a web page like http://crypto.stanford.edu/flashproxy/, and there is also code to run a proxy in the background without a browser: https://trac.torproject.org/projects/tor/ticket/7944.
David Fifield
-- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git