Date: Wed, 29 Mar 2006 06:43:05 +0200 From: Benjamin Lutz <benlutz@datacomm.ch> To: Mark Jayson Alvarez <jay2xra@yahoo.com> Cc: questions@freebsd.org Subject: Re: Need some tips in reorganizing our LAN. Message-ID: <200603290643.08831.benlutz@datacomm.ch> In-Reply-To: <20060329035511.28080.qmail@web51607.mail.yahoo.com> References: <20060329035511.28080.qmail@web51607.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1634779.h0PD1G39ei Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello jay, On Wednesday 29 March 2006 05:55, Mark Jayson Alvarez wrote: > The MIS suggested a LAN transition project, and I was assigned to lead the > team. Right now, we are only two in this very big team. :-) I'm just > wondering if I will ever gonna finish this project or not. I have a lot of > stuffs mixed up in my mind right now but I really don't know where to > start. If you don't have it already, I'd start cleaning up the old system without= =20 changing it's structure. Remove the redudancies, eg unnecessary cascading=20 switches, or computers that are no longer used. This will give you a clear= =20 idea of what the current layout looks like, making it easier to plan change= s,=20 and with some luck it'll also give you a hardware stockpile that you can th= en=20 recycle for your new LAN. > I have these in my mind right now: > > Connectivity > 1. wired > 2. wireless I see no place for a wireless network in a professional network. It's hard = to=20 secure it (it's possible, encrypted-VPN-over-WLAN works, but it's difficult= =20 and expensive to set up). Stick with a wired LAN, and there'll be one=20 security threat less that you have to worry about. > Machines being hooked into the network: > 1. servers > 2. workstations Make a list of the servers you have, and which user groups need them. Make = a=20 list of which logical user groups there are. Then design a network layout t= o=20 match those needs. You could, for example, put each use group into its own= =20 subnet, including the servers it needs. Access between user groups could th= en=20 be restricted at will*. Alternatively, put some or all servers into a dedicated subnet. This will a= lso=20 allow protecting them better. I realize I'm being very unspecific, but you didn't give us all that much=20 information. > 3. testbeds If there are users accessing those, treat them as servers. Otherwise, isola= te=20 them from the production network. > 4. personal (laptops etc.) This is a difficult one. Personal laptops are machines you have no direct=20 control over (you cannot control what software is installed on it), and as= =20 such they are a high risk factor when they are connected to your network.=20 They might introduce malware into the company, or evade your file storage=20 procedures. This is a matter of policy basically. Try to restrict personal machines as= =20 much as you can. Forbid connecting them to the LAN. If you can't do that,=20 maybe have specialized laptop ports that are firewalled off from the rest o= f=20 the network. > Will use DHCP Keep in mind that a DHCP server needs to be in the same subnet it serves.=20 Other services do not have this requirement. > Will use centralized directory service > Will use centralized authentication Sounds good. Personal laptops will undermine this though, another reason to= =20 try to keep them away. > We have at most 150 employees... > We don't have that much to spend on equipments like managed switches, > powerful servers, etc. We have a lot of political issues that needs to be > resolved regarding network usage policies You don't need powerful hardware to manage a network with just 150 employee= s.=20 Some gigabit hardware for popular servers would be nice, but the network=20 management will use very little CPU resources (unless of course you decide = to=20 play around with VPNs). So don't worry about that too much. > All these stuffs, basically mixed up in my mind. I really have no idea > where to start aside from creating a purchase request for a new PC router > and a multiple port lan card, which I already did a week ago..And it has > not arrived yet. :-) It sounds like you're planning to have all subnets connected through this o= ne=20 =46reeBSD box. This is not necessary. You can put a router in between subne= ts,=20 and have that one located elsewhere, where it's more convenient. It can als= o=20 make perfect sense to have firewalls on these routers. If you isolate user= =20 groups that need to communicate with each other into different subnets and= =20 block traffic between them, it'll be easier to contain a worm outbreak. And oh yeah: in my opinion, the firewall, ie the outermost machine that's=20 connected to the internet, should have 2 or 3 interfaces only, and carry da= ta=20 only on 2 of them. Do not give it several interfaces for the purpose of=20 routing your LAN. It'll make creating an airtight firewall ruleset much mor= e=20 difficult. Instead, have one or several routers inside your LAN that handle= =20 it, that don't need to deal with malicious outside traffic too. > Please help me. =46eel free to be more specific about your plan or with your questions, I'm= sure=20 people here will happily comment on or answer them. I'm also sensing that you feel a bit overwhelmed. Try to keep pressure on=20 yourself low, by having as few disruptive changes as necessary. Don't try t= o=20 change your whole network over a weekend, it's too large for that. Install= =20 the new parts bit by bit, and try to do so with the rest of the old system= =20 still working, until you change it. In other words: take it slow, and plan= =20 your steps well. And here's another thought: reliability and redundancy. Computers fail. If = you=20 have one central router that everything goes through, not only is it a=20 performance choke point, but it'll also bring the whole agency to a=20 standstill if it should fail. Maybe there isn't a better way to do things=20 given your resources, but if there is, try to limit the impact of potential= =20 failures. Distribute things like routing, and most of the network will keep= =20 working if one machine fails. Or, if you can, make things redundant. Cheers Benjamin --nextPart1634779.h0PD1G39ei Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEKhBcgShs4qbRdeQRAoWfAJ96WtIazURL8xaC+jtDfMfaE3j1HACbBzMw 0+O3TX5NKlZxfA0ica6pAgU= =niZM -----END PGP SIGNATURE----- --nextPart1634779.h0PD1G39ei--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603290643.08831.benlutz>