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. 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? 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. 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". > > 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? Gordan _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
