[tahoe-dev] Can Tahoe works well in this scenario?
Shu Lin
linshu at gmail.com
Sun Dec 5 08:47:16 UTC 2010
>
>
> Certainly coda may not do what you want; I just thought you should know
> about it.
>
>
Sure. Thanks a lot! :-)
> > For fixing the firewall, I don't quite understand you suggestion. Even
> > through, I fixed my setup by opening a port in my firewall last time as
> you
> > suggest if you remember. But, I don't think opening a port is eventually
> > acceptable in my deployment. I prefer a zero firewall configuration
> effort
> > as NAT traversal is so a popular technology already. I don't think Skype
> > will get success if it has to ask everybody to twist their firewall ports
> at
> > home. :-)
>
> It's hard to tell, but it sounds like you are fundamentally
> misunderstanding the network traffic required for tahoe. Relative to
> all nodes that might be clients or servers, you need:
>
> a public IP address for the introducer, reachable by all servers and
> clients
>
> servers need either a public IP address, not firewalled, or an address
> with static NAT and firewall allowance so that clients (including
> other servers) can connect. If the server's address is not global,
> you need to hand configure the static NAT situation
>
> clients need to be able to reach all servers
>
>
> 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.
Thanks,
-Shu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20101205/e5d579c5/attachment.html>
More information about the tahoe-dev
mailing list