On Wed, Sep 03, 2003 at 05:33:05PM +0100, Gordan wrote: > Sorry for not trimming this too much, but I think most of it is > context-relevant... > > > > Say I have a bunch of nodes on a fast LAN, on private IPs (say 10.x.y.z) > > > and those were connected to the internet via a much slower connection > > > with NAT on the firewall. One node, (say the most powerful one) has a > > > public IP, e.g. port forwarded from the NAT firewall. > > > > > > Obviously, only the one node will be accessible from the internet (the > > > one with a public IP). The other nodes will not be visible from > > > "outside". All nodes have unrestricted access out. > > > > > > 1) Would the "private" nodes ever learn about each other (in their > > > private IP space)? If they are not routable inward, then how will thel > > > learn about each other, short of manually creating a seednodes.ref file > > > to give to all of them? > > > > You would have to tell them about each other, correct. > > Is there a tool or an automated way for creating such a seednodes.ref file? > > > > 1.1) How doe Fred currently deal with nodes that report > > > invalid/private/non-routable IP addresses? Do nodes just try to route to > > > them anyway, or is there some kind of a mechanim (e.g. a 2-way handshake) > > > to detect and prevent invalid/non-routable IP addresses from poluting > > > routing tables? > > > > You would have to set localIsOK=true, also, as currently designed they > > would have to talk to the border node via its public address, because we > > don't yet support multiple IP addresses in a reference. > > What about having the internal DNS resolving to a different address than the > external DNS? Or even, have the border node actually on the inside, port > forwarded from the firewall. > > That way the "border" node has ipAddress=mynode.dyndns.org which resolves to > the public firewall IP and gets forwarded in, but it actually lives on a > machine that has a private IP on the inside of the firewall that has an > address in the same 10.0.0.0/8 block. At the same time, the internal DNS > resolves mynode.dyndns.org to 10.0.0.1.
That would work. > > Would that work? > > > > 2) Would the nodes learn to route requests to local nodes first, because > > > they are much, much faster, with amost no network latency, because they > > > sit on something like a 100Mb switch or 802.11g WiFi, instead of a 256Kb > > > DSL line? > > > > If they knew about each other, yes. And our loop protection would ensure > > that the request eventually got routed to the outside net. Hopefully. > > Although the internal hops would still take up a hop in the HTL. > > 2.2) If the external access from internal nodes was denied (i.e. they could > not contact other external nodes), would they learn reasonably quickly to > "funnel" all the traffic through the border node(s), if they knew about them, > e.g. from seednodes.ref? Yes... I think we had some code to not forward references to nodes on other interfaces, not sure. > > 2.3) What effect would this have on the specialisation of the border node(s)? > Would this lead to massive redundancy between the border node(s) and the > internal node(s)? The reason I ask is because the border node would end up > seeing all the keys being requested by all/any of the internal nodes, and I > expect that this might skew it's caching/routing specialisations. Not sure. Probabilistic caching would ensure there was some difference though. > > 2.4) Would such a setup open any potential (theoretical) possibility of attack > or security risk for that network? Obviously, if the funnel node goes bad, > all through traffic could be logged, but that is not really any worse than > any node being compromised in such a way, provided the internal network is > sufficiently large for the routing to go "fuzzy". I don't know. > > > > 2.1) Is this what NGR is supposed to achieve? > > > > > > The idea of such a network would be that while there is still a "way out" > > > to other nodes in the world, the requets would hopefully be fulfillable > > > over the fast LAN instead of the slow WAN. > > > > Yes. Hopefully the internal nodes would never forget about the border > > node. NGRouting has of course a much wider scope than this. Such > > setups may well be used in hostile environments... talk to jrand0m about > > that :) > > jrand0m? Who is that? An anonymous person usually present on IIP channel #freenet. > Gordan -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
pgp00000.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
