Hopefully, if you have read by article on building a home server, you have a good idea what you want to do with your box that you will be building. My detailed tutorials are going to be from the perspective of setting up an all-in-one router/firewall/gateway/webserver/media server. You can most likely omit any of the sections and ignore what you will not be needing. If you have a hardware firewall/router, for example, you can ignore the steps about sharing the network connections and setting up the firewall. Some of the steps depend on the others, like the need to install an sql database if you wish to properly use php. But If you don't need to have a shared drive, you can skip the file sharing part.
But the one aspect of this server that pretty much cannot be ignored is that it is going to be on a network. I thought that I would lay out some of the networking concepts that I will be using in building our home servers. This is by NO means a course on networking. If that's what you are looking for, hit a search engine and see what you can find. There are literally countless pages that have as much networking info as you need.
First and foremost, lets discuss IP addressing. An IP address is like a phone number that tells others on the network where the computer is located. If you are using the machine as a router/gateway, you will probably have 2 network connections on the machine. One probably goes to your cable modem or DSL modem. The other will go into a switch or hub in your house that your other computers are going to connect to. Let's call your internet connected network "external" or the "outside" connection, and the other will be called the "internal" or "inside" connection. If you are already network savvy, the outside connection is the WAN connection, and the inside interface is the LAN. Each of these connections will have a different IP address. You probably will not have many options for your external IP. Either that interface gets its IP from your Internet service provider (ISP) automatically using the DHCP protocol, or you will have been assigned a static IP address and subnet mask. This is vital information and you will not be able to complete this setup without it.
The internal address is something I want to touch on a little bit. Your internal interface is pretty much going to HAVE to be set to a non-changing, static address. The reason for this is that you do not want it to change because then the internal computers will not know where your server is exactly, and using DHCP to configure this interface will not always guarantee this. (There are some ways to make it happen, but those are beyond the scope of this article). When it comes to IP addressing and networks, certain rules have to be followed. Your internal network most likely is a private network, so you will have to use ip address ranges in the "Class C" range. This is a special range of IP addresses that can be used for internal private networks like yours. Valid ranges are : 10.0.0.0 - 10.255.255.255 and 192.168.0.0 - 192.168.255.255. Any addresses in those range are valid and legal. For example you can give your internal interface of 10.0.0.5 or 192.168.1.1. For various reasons that will be illustrated during the XP routing section in the next article, I recommend that you assign your internal interface to the address of 192.168.0.1 with the default subnet mask. In addition to XP's special requirements, I recommend using this as your internal IP even if you are going the *nix route. It will simplify many of the subsequent steps. You do not HAVE to do this, but I really see no reason why you wouldn't use 192.168.0.1.
Next you will want to decide the way your clients will be connecting to your server. You may either run a DCHP server on your home server and assign your clients addresses automatically, or you may manually assign static IP addresses to your client PC's (or you can have a mix of the two if you follow some guidelines). To be honest, DHCP can sometimes have problems if your outside interface also uses DHCP, but I will show you how to use either way, and really this is a case of personal preference. Decide on this before you start, however.
Also, you need to think about how this machine will be administered. If you are going to want to administer your server over the internet and you have a static IP address, then don't worry, you should be able to access your static IP from any internet connected computer. If you have an ISP that gives you a DHCP address, you can never know when your assigned IP is going to change. If this is the case, hope is not lost. you can use something called a Dynamic DNS. I use No-ip, and if you are willing to use their domains, you can get an actual internet address like mysrvr.noip.com. There is a little program that we can install on the server that will let your dynamic DNS always know the location of your machine no matter how many times it may change. There are other dynamic DNS services, and you should pick one out. For a fee, you can usually get an actual domain and register it with these services like www.mysrvr.com. If you have a static IP you can just register a domain name and have it point to your static address.
Finally, you will need to know about NAT and port forwarding. NAT or Network Address Translation, in layman's terms is essentially this: As far as the outside network or internet is concerned, a request to the internet from any of the clients in your private network looks like it is coming from your outside interface ip address. If you Google NAT you will find extensive information about its nuances, but it's just a principle that says that the ONLY IP address that the rest of the world can see is your outside interface. Here's a dirty little diagram
remote computer--> Outside interface( 9.6.74.15)<-NAT Router-> insideinterface(192.168.0.1) --- client 1(192.168.0.7)
Say remote computer one is an internet web server. Client 1 types this web server address into his browser. The remote computer's web site appears. But as far as the remote computer can see, the request to display his site came from 9.6.74.15. In fact, it isn't even aware that 192.168.0.7 even exists. But how does the outside interface know to send the web site information back to client 1? It uses NAT routing. This is exactly what NAT is designed to do. Most home servers and hardware firewalls/routers use this exact mechanism. This is NAT in a nutshell.
One of the problems with NAT is that if the request for information is NOT initiated by one of the client computers, there is not a way to send any information to client 1. Say remote computer is your work PC at your office, away from your private network. Also, lets say you are not running a web server on your NAT router, but you are running it on client 1. If you type in 192.168.0.7, chance are you will get a page not found message. Thats because your office PC doesn't even see 192.168.0.7. It has no direct route to get there. So how can you access that machine's web server from your office?
This is where port forwarding comes in. You can set the NAT router to route all traffic from remote computers to port 80 (the default web server port) directly to 192.168.0.7. So any request that is made to 9.6.74.15 on port 80, will get sent directly to client 1. So after you set up port forwarding, at your office computer type 9.6.74.15 and poof, you will be shown the web page being served on 192.168.0.7. Any other port will still get processed by the NAT router, but all port 80 requests will go to client 1. You can even run web servers on BOTH machines if they use different ports. I'll touch on that during the installation of the server software.
The great part about this comes with respect to hackers and intruders. Because of NAT, the only machine that malicious intruders will ever be able to hit without being invited or knowing about your port forwarding scheme is your home server. That means that if you run a firewall on the server, you can block any malicious traffic to any of your clients. This eliminates the need to install software firewalls on any of your clients, because the NAT router blocks all of those attacks before they ever hit any clients. Cool, huh?
So do some research, get familiar with the above concepts, and in our next installment we'll begin building a windows XP based home server. I'm really looking forward to it.
No comments:
Post a Comment