| gabriel rosenkoetter on 7 Dec 2003 09:43:02 -0500 |
|
On Fri, Dec 05, 2003 at 04:43:15PM -0500, Jeff Abrahamson wrote: > Scenario 1 (private LAN): make one box the gateway, put two ethernet > interfaces on it, and put all other boxes on a private network > (192.168.0.0) behind the gateway. pros - configuration is centralized - configuration is relatively simple and well documented cons - your DNS will break all over the place and you'll have to figure out how to make split DNS setups work if you want both the systems inside the network to address each other by name and systems outside the network to address systems inside the network by name - gateway host is a bottleneck (but probably not a big one) - without real NAT, you've SERIOUSLY interrupted access to systems inside the network > Scenario 2 (public LAN): make on box a gateway, put two ethernet > interfaces on it, and put all other boxes behind it, but still with > their existing ip addresses. pros - once it's in, this is very clean: you can silently filter packets without interrupting IP addressing - good learning experience - configuration is centralized cons - good learning experience (this ain't easy) - configuration is VERY HARD (you'll need to figure out how to proxy arp properly for all those internal hosts AND the CS department will have to honor your proxy arping, which many poorly-behaved switches and routers--which are stepping above their OSI caste in so doing-- won't) - configuration isn't documented anywhere specific to Linux that I've seen (most people who do this sort of thing do it with a real piece of networking hardware, like a Cisco 6500 series router) - gateway host is very definitely a noticeable bottleneck (without some kernel modifications, you'll probably be running into situations where the arp table fills up on the gateway host and new connections simply stop working on a daily basis; it's not difficult to deal with this situation, but the generic Linux kernel isn't set up for it and I don't even know what to tell you to change for Linux) > Scenario 3 (harden only): leave them as they are now, just harden the > iptables rules on them to make sure they make sense. pros - you already know how to do this - you may, in fact, already HAVE DONE this cons - configuration is completely distributed and may be different on each host; maintenance will be a royal pain (and don't imagine that this will be set-and-forget; consider that when there's an IP Tables security vulnerability you will HAVE to update the relevant bits on ALL of the systems) - not much of a learning experience > Comparing 1 and 3, the private LAN of 1 seems simpler and more secure, > but may be more intrusive to operations and people's workflow. I don't understand why. You appear to be stuck in the Linux-centric concept of "IP Masquerading" (which isn't, in fact, what network admins call masquerading, but whatever). Do full (source AND destination) network address translation and there should be no difficulty addressing internal machines by their formerly-used, globally-routable IP address from outside the network. You'll probably need to add all those globally-routable addresses as virtual interfaces on the gateway's external interface. > In addition, I wonder how long it will be before there's some problem > with key authentication, either with SFS (in which host names and > public keys must match) or with ssh (to scp past the gateway in one > step, I would typically first ssh over it with "ssh > -L8022:inside-machine:22 gw" and then "scp -P 8022 foo localhost:foo" > to copy foo to inside-machine.) This point is moot if you do real NAT and configure split DNS (use BIND 9's views). If you're lazy about the second half, don't use DNS for hosts inside to speak to other hosts inside; simply maintain an /etc/hosts (rsync + ssh with a null-passphrased SSH key as root from a locked down and NOT globally-accessible host is your friend). Option 1 is by far the most oft-traveled path. You'll find plenty of documentation on how to do this right. I can give some networking- level descriptions, but I've never used IP Tables except for per-host firewalls, so I can't help with that much (now, if you were doing this with ipfilter on NetBSD or Solaris...). I can probably help with questions about BIND 9 and split DNS, but I'm a bit hazy and hand-wavy myself about that at the moment. -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgp8PV2MvU7v6.pgp
|
|