[tahoe-dev] Can Tahoe works well in this scenario?

[Brian Warner]

On 12/5/10 2:47 AM, Shu Lin wrote:

>     Putting all nodes behind a NAT with a strict firewall and no manual
>     config just isn't going to work.
> 
> I don't think Tahoe has any restrict on deployment environment. Having a
> server accessed through a public IP doesn't mean I can't put the server
> behind a strict firewall with a public IP.
> 
> For the NAT traversal, there are lots of solutions to do it
> automatically without hand configuration. For example:
> 
>    1. STUN, http://tools.ietf.org/html/rfc5389
>    2. Firewall hole
>       punching, http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.html
> 
> I think the only required public well-known address and port is the
> introducer IP address and port. All servers can be hidden behind
> firewalls with proper design. Although this might not be the original
> design goal of Tahoe, I don't think there is anything from technology
> point of view to restrict it.

That's correct. We'd absolutely love it all Tahoe storage-servers and
clients could operate correctly behind NAT boxes. We haven't had the
time to design and implement the STUN/STUNT/hold-punching code yet, and
it's been lower on the priority list than everything else, but we'd love
to have it.

We have several very-old tickets about this issue:

 UPnP:                http://tahoe-lafs.org/trac/tahoe-lafs/ticket/49
 STUNT/ICE:           http://tahoe-lafs.org/trac/tahoe-lafs/ticket/50
 TCP hole-punch:      http://tahoe-lafs.org/trac/tahoe-lafs/ticket/169
 use Relay for NAT:   http://tahoe-lafs.org/trac/tahoe-lafs/ticket/445
 use Helper for NAT:  http://tahoe-lafs.org/trac/tahoe-lafs/ticket/868

We've also been considering changing our main client-to-server protocol
away from TCP-based Foolscap and over to something else, which might
make it easier to use UDP-based STUN-like protocols.

This might make for a good Google-Summer-of-Code project.

cheers,
 -Brian