On Mon, Jul 11, 2011 at 11:50 PM, Scott Ferguson <prettyfly.producti...@gmail.com> wrote: > On 12/07/11 12:22, Nico Kadel-Garcia wrote:
>> Oh, my. You can load the IP addresses *directly*, by IP address, and >> access them if you have a route to them. > > *If you have a route*.... in the examples given there is no route, hence > NAT. *Really*. Then I suggest you look up the output of your local "route -n" command on any internal network that uses both 192.168.0.0/24 and 10.0.0.0/8, or look up the output of the "traceroute" command. The route between them is handled by whatever internal gateway is used to connect them, but it counts. It's not typically routed in the sense of having BGP scores associated with them, but you';d better believe that the routers of a company that VPN connects such local address spaces had better know about them. > > I simplified things (as noted in the original post) as a means of > explaining why NAT != security. > CIDR would take more time than I have available to explain. > >> This is quite common inside VPN's, > > You can NAT VPN can *you*? :-) Was I unclear on this? Organizations large enough to run VPN's, "Virtual Private Networks", use an encrypted channel to present a gateway to another location. It's typically done with the other location on a different address range, a different "VLAN", and often those address ranges are precisely the private, "non-routable" address ranges we're talking about. The routing between these so-called "non-routable" address spaces is done via encrypted channels with VPN tools, but oh, yes, it can be full-blown genuine "routing". The distinction between a "route" and a "gateway" can get muddied, it's true. >> and as an example is common to all of AOL's internal server address >> space (which uses the 10.0.0.0/24 address space, > > See my comment about CIDR. > AFAIK AOL only started that in early 90s - so I'm not sure what you're > trying to say. Their backend server IP addresses, the ones that support their service infrastructure, were all in the 10.0.0.0/24 address space and dould only reach out with NAT or port forwarding. I dealt with a number of such hosts and allocating servers inside their network space: I had to be very careful not to step on their unpublished address space with the 10.* addresses my own company's servers normally used. >> or did a few years ago.) It's also common in internal networks where >> 192.168.1.0/24 > > Apropos of the examples given - access from the internet to > machines behind a NAT?? Separate issue. The *internal* access is routed. It's not very complex, it's not public, but yes, indeed, it can be routed, whether in the sense of declaring individual static "routes" on specific hosts, or in the sense of full load balanced routing for multiple VPN connections. >> might be dedicated to a demilitarized zone for external servers, >> 192.168.2.0/24 might be your internal hosts, 192.168.100.0/24 is >> dedicated for idiots who connect internal NAT gateways, etc. > > Again - I used "Class" addressing for the purposes of the example - feel > free to use 8.8.8.8 for a private address. The point of your comment > is?? (seriously) See above. >> The lack of routes to to such non-routable address ranges is a >> *convention*, (http://en.wikipedia.org/wiki/Private_network), and >> published in numerous RFC's. > > No dispute there - see my comment about the distinction between illegal > and unworkable. >> IPv6 has its own..... ideas about how to deal with thus, but it >> certainly has reserved, non-routable address spaces. >> > Not sure what post you're replying to - I certainly didn't say anything > about a lack of reserved address with IPV6. It gets confusing if you don't mention it. The "go use IPv6, NAT is unnecessary, you can have public IP addresses for *EVERYTHING* misses several of the real reasons for NAT. Not having your address spaces exposed, and not having to *register* them in any way if you have a NAT working, are several of those reasons. > If information is your desire - I was, clearly, responding to Randy's > question. Apart from the redundant wikipedia quote I can't see the > relevance of your post to anything I've said. We seem to have a disagreement about what the word "route" means, at the core of this. I'm using it in the broader sense, which would also include gateway and bridge functions. This is reflected in local system state, such as the output of the "route" command. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOCN9rxerBSXZSvfK3H=7iQvho+W5=mrvd8rgeadcu4qjtq...@mail.gmail.com
