Jody Harris wrote: > For the record, I've tried and failed to use ssh tunneling. Can someone > explain to be why this solution won't work? I've searched the tickets > and the mailing list and not found an explanation as to why this fails. > I think it would be nice to have it documented, if someone can explain it.
How exactly were you setting up the tunnel? And was this tunnel for the purpose of letting your node connect to the outside world, or for the outside world to connect to your node? If the latter, I'd be using "ssh -R12345:localhost:6789", use the tahoe.cfg "tub.location" setting to announce the "targethost:12345" public side of your tunnel, and the "tub.port" setting to tell your node to listen on localhost:6789 . That ought to cause other nodes to connect to the outside of your tunnel. Note that without the tub.location setting, your node will announce its real (internal+unreachable) address to the other nodes, and they probably won't be able to connect in. However, if they have public IP addresses, you might be able to connect out, possibly masking or confusing the problem. If the former (i.e. if you're using ssh like an outbound proxy), then the challenge is that tahoe will connect to the introducer, then connect to every node announced by the introducer, all using the IP addresses contained in the various FURLs. So a single tunnel won't do (you'd need to create a tunnel for each node, and you'd have to intercept the Introducer messages to trick your node into connecting to the local tunnel endpoint instead of the actual remote address). But, ssh can behave like a SOCKS5 server, and you can run your tahoe node under 'tsocks' or 'runsocks' to force all the network connections to go to that socks server. This is how we suggest people get Tahoe running under Tor, since the Tor client also behaves like a SOCKS5 server. does that help? cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
