The first decision to be made is that of what IP addresses to use. There is a RFC - internet ``standard'' which defines a range of IP addresses which are non-routed - that is, aren't directly connected or routed onto the internet.
The ranges defined by RFC 1597 are as follows:
192.168.x.x 10.x.x.x 172.16.x.x -> 172.31.x.xA good choice for a LAN is 192.168.x.y, where x is a number chosen at random. The router then should be 192.168.x.1, as this is easy to remember.
Client machines will then use the following settings:
IP address: 192.168.x.y # where 1 > y < 254 Broadcast: 192.168.x.255 Network: 192.168.x.0 Netmask: 255.255.255.0It is also necessary to select a domain name for your intranet - you can either choose a subdomain of your ISP / company, or use an obviously fake one, such as .intranet, or .homenet. The advantages of using a subdomain is that if any hostnames do leak out, it is easy to track back to a valid address and notify a responsible person. Choosing a fake domain, however, means that if somehow there is a security breach, it is harder for someone to track it back to the original host, which means other people can't take advantage of it.
Choosing hostnames for all of the machines in the intranet is also important - it makes it easier to specify which machine you are talking about, and also means less confusion when looking at logs, or when specifying what host is allowed to do what. Thinking of names for all your hosts is sometimes not easy, however - it is helpful to pick a naming scheme, and stick to it. Examples of this is planets, colours, or other similar schemes - see RFC1178 for more examples.
Now it is time to decide what type of access the clients will have. Whether the intranet is in a home environment, or an office environment, it is important to specify, even informally, what access is allowed. It may be as simple as ``all access is allowed'', or as restrictive as only allowing access to certain hosts on certain ports.
Assuming you have some form of connection to an ISP, which provides you with only one IP address, there are a few ways of providing access to the internet. One is to get your ISP to route some IP addresses to your router - this is only necessary if you have some requirements for direct internet access to each host, and is sometimes expensive.
A possibly better approach is either to provide access by application level proxies - ie, no actual connectivity to the internet from the hosts and the clients use proxies on the router to access the resources they require. The other is to use network address translation (NAT) - the most common way of providing this under linux is ip masquerading - this hides the addresses of the clients, and makes any connections appear to be coming from the router - hence you only need one ip address.
Addtionally, it is also necessary to think of what services the intranet will be providing. Possibly useful services to provide are a dns server - Bind, a dhcp server, a web proxy - Squid, and a mail server - Sendmail, Exim or any of the many other mailservers.
Other useful services, while not strictly necessary for internet connectivity, are Apache, to provide web content, Samba, to provide file services for Windows machines, ntp for time sycronisation.
As you can see, there is more to providing access to the internet for an intranet than simply giving access - there is much to be gained from thinking about what access is required, and what extra services you provide. With a little bit of thought, it is possible to provide the desired access securely.