Fedora iTOps Tube

Thursday, November 10, 2011

Using a Single DHCP Server to Serve Multiple Networks

Using a Single DHCP Server to Serve Multiple Networks

As stated before, DHCP clients send their requests for IP addresses to a broadcast address which is limited to the local LAN. This would imply that a DHCP server is required on each subnet. Not so. It is possible to configure routers to forward DHCP requests to a DHCP server many hops away. This is done by inserting the IP address of the router's interface on the DHCP client's network into the forwarded packet. To the DHCP server, the non-blank router IP address field takes precedence over the broadcast address and it uses this value to provide a DHCP address that is meaningful to the client. The DHCP server replies with a broadcast packet, and the router, which has kept track of the initial forwarded request, forwards it back towards the client. You can configure this feature on Cisco devices by using the ip helper-address command on all the interfaces on which DHCP clients reside. Here is a configuration sample that points to a DHCP server with the IP address 192.168.36.25:

 interface FastEthernet 2/1
  ip address 192.168.1.30 255.255.255.0
  ip helper-address 192.168.36.25


Configuring Windows Clients to Use DHCP

 Configuring Windows Clients to Use DHCP

Fortunately Windows defaults to using DHCP for all its NIC cards so you don't have to worry about doing any reconfiguration

 

Configuring Linux Clients to Use DHCP

Configuring Linux Clients to Use DHCP

A Linux NIC interface can be configured to obtain its IP address using DHCP with the examples outlined in , "Chapter 3, Linux Networking". Please refer to this chapter if you need a quick refresher on how to configure a Linux DHCP client.

DHCP Servers with Multiple NICs

DHCP Servers with Multiple NICs

DHCP servers with multiple interfaces pose two configuration challenges. The first is setting up the correct routing and the second is making sure only the required interfaces are listening to serve DHCP. Don't worry, both will be discussed next.

 

Routing

When a DHCP configured PC boots, it requests its IP address from the DHCP server. It does this by sending a standardized DHCP broadcast request packet to the DHCP server with a source IP address of 255.255.255.255.

If your DHCP server has more than one interface, you have to add a route for this 255.255.255.255 address so that it knows the interface on which to send the reply; if not, it sends it to the default gateway. (In both of the next two examples, we assume that DHCP requests will be coming in on interface eth0).

Note: More information on adding Linux routes and routing may be found in Chapter 3, "Linux Networking".

Note: You can't run your DHCP sever on multiple interfaces because you can only have one route to network 255.255.255.255. If you try to do it, you'll discover that DHCP serving working on only one interface.

 

Temporary Solution

You can temporarily add a route to 255.255.255.255 using the route add command as seen below.

 [root@bigboy tmp]# route add -host 255.255.255.255 dev eth0

If you want this routing state to be maintained after a reboot, then use the permanent solution that's discussed next.

 

Permanent Solution

Create a permanent route to 255.255.255.255. This will vary according to your version of Linux

 

Fedora / RedHat / CentOS: Add the route to your /etc/sysconfig/network-scripts/route-eth0 file if the route needs to be added to your eth0 interface.

 #
# File /etc/sysconfig/network-scripts/route-eth0
#
 
255.255.255.255/32 dev eth0

 

Ubuntu / Debian: Add the route to your /etc/network/interfaces file. In this case the route is added to the eth0 interface.

 #
# File: /etc/network/interfaces
#
 
iface eth0 inet static
 
       up route add -host 255.255.255.255 eth0

Simple Linux routing is covered in Chapter 3, "Linux Networking" and will add more clarity to adding permanent static routes.

 

Listening

Once you have defined the interface for your DHCP routing you should also ensure that your DHCP server only listens on that interface and no others. This methodology to do this varies depending on your versión of Linux.

Fedora / RedHat / CentOS: The /etc/sysconfig/dhcpd file must be edited and the DHCPDARGS variable edited to include the preferred interface. In this example interface eth0 is preferred.

 # File: /etc/sysconfig/dhcpd
DHCPDARGS=eth1

Debian / Ubuntu: The /etc/default/dhcp3-server file must be edited and the INTERFACES variable edited to include the preferred interface. In this example interface eth0 is preferred.

 # File: /etc/default/dhcp3-server
INTERFACES="eth0"

You will be able to verify success in one of two ways. First the netstat command using the –au options will give the list of interfaces listening on the bootp (DHCP) UDP port.

 [root@bigboy-f ~]# netstat -au  | grep bootp
udp        0     0 192.168.1.100:bootps    *:*
[root@bigboy-f ~]#

Secondly, your /var/log/messages file will also reveal the defined interfaces used when the DHCPd daemon was restarted.

 Jan  8 17:22:44 bigboy dhcpd: Listening on LPF/eth0/00:e0:18:5c:d8:41/192.168.1.0/24
Jan  8 17:22:44 bigboy dhcpd: Sending on   LPF/eth0/00:e0:18:5c:d8:41/192.168.1.0/24

Success! You can go back to lunch!

 

ssa � eخ� (� Web server. This usually results in your system listening on a variety of unexpected TCP/IP ports that could be used as doors into your system by hackers.

The screen output of the netstat -an command below shows a typical case. Some ports are relatively easy to recognize. TCP ports 25 and 22 are for mail and SSH, respectively, but some others are less obvious. Should you use the chkconfig command and the scripts in the /etc/init.d directory to shut these down permanently?

 [root@bigboy tmp]# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address
State
tcp    0    0 0.0.0.0:32768    0.0.0.0:*     LISTEN
tcp    0    0 127.0.0.1:32769  0.0.0.0:*     LISTEN
tcp    0    0 0.0.0.0:111      0.0.0.0:*     LISTEN
tcp    0    0 127.0.0.1:631    0.0.0.0:*     LISTEN
tcp    0    0 127.0.0.1:25     0.0.0.0:*     LISTEN
tcp    0    0 :::22            :::*          LISTEN
udp    0    0 0.0.0.0:32768    0.0.0.0:*
udp    0    0 0.0.0.0:930      0.0.0.0:*
udp    0    0 0.0.0.0:68       0.0.0.0:*
udp    0    0 0.0.0.0:111      0.0.0.0:*
udp    0    0 0.0.0.0:631      0.0.0.0:*
...
...
[root@bigboy tmp]#
 

For example, how do you know which startup script is responsible for TCP port 111? The answer is to use the lsof command which lists all open, or actively used, files and can be given additional options to extend its scope to include the TCP/IP protocol stack.

In the next examples we see that TCP ports 111 and 32769, and UDP port 123 are being used by the portmap, xinetd and ntp daemons respectively. The portmap daemon is required for the operation of NFS and NIS, topics that are covered in Chapters 29, "Remote Disk Access with NFS", and 30, "Configuring NIS". portmap also has many known security flaws that makes it advisable to be run on a secured network. If you don't need any of these three applications, it's best to shut down portmap permanently. NTP, which is covered in Chapter 24, "The NTP Server", is required for synchronizing your time with a reliable time source, and may be necessary. A number of network applications are reliant on xinetd, as explained in Chapter 16, "Telnet, TFTP, and xinetd", and it might be required for their operation:

 [root@ bigboy tmp]# lsof -i tcp:111
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
portmap 1165  rpc    4u  IPv4   2979       TCP *:sunrpc (LISTEN)
[root@ bigboy tmp #
 
[root@bigboy tmp]# lsof -i tcp:32769
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
xinetd  1522 root    5u  IPv4   2764       TCP probe-001:32769 (LISTEN)
[root@bigboy tmp]#
 
[root@bigboy root]# lsof -i udp:123
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
ntpd    1321  ntp    4u  IPv4   3390       UDP *:ntp
...
...
[root@bigboy root]#

In some cases it's tricky to determine the application based on the results of the lsof command. In the example below, we've discovered that TCP port 32768 is being used by rpc.statd, but there is no rpc.statd file in the /etc/init.d directory. The simple solution is to use the grep command to search all the files for the string rpc.statd to determine which one is responsible for its operation. We soon discover that the nfslock daemon uses it. If you don't need nfslock, then shut it down permanently.

 

 [root@bigboy tmp]# lsof -i tcp:32768
COMMAND    PID    USER   FD   TYPE DEVICE SIZE NODE NAME
rpc.statd 1178 rpcuser    6u  IPv4   2400       TCP *:32768 (LISTEN)
[root@bigboy tmp]# ls /etc/init.d/rpc.statd
ls: /etc/init.d/rpc.statd: No such file or directory
[root@bigboy tmp]# grep -i statd /etc/init.d/*
/etc/init.d/nfslock:[ -x /sbin/rpc.statd ] || exit 0
...
...
[root@bigboy tmp]#

As a rule of thumb, applications listening only on the loopback interface (IP address 127.0.0.1) are usually the least susceptible to network attack and probably don't need to be stopped for network security reasons. Those listening on all interfaces, depicted as IP address 0.0.0.0, are naturally more vulnerable and their continued operation should be dependent on your server's needs. I usually shutdown nfs, nfslock, netfs, portmap, and cups printing as standard practice on Internet servers. I keep sendmail running as it is always needed to send and receive mail (see Chapter 21, "Configuring Linux Mail Servers", for details). Your needs may be different.

Remember to thoroughly research your options thoroughly before choosing to shut down an application. Use the Linux man pages, reference books and the Internet for information. Unpredictable results are always undesirable.

Shutting down applications is only a part of server security. Firewalls, physical access restrictions, password policies, and patch updates need to be considered. Full coverage of server and network security is beyond the scope of this book, but you should always have a security reference guide on hand to guide your final decisions.

 

Final Tips on chkconfig

Remember the following:

§  In most cases, you want to modify runlevels 3 and 5 simultaneously and with the same values.

§  Don't add/remove anything to other runlevels unless you absolutely know what you are doing. Don't experiment, unless in a test environment.

§  chkconfig doesn't start the programs in the /etc/init.d directory, it just configures them to be started or ignored when the system boots up. The commands for starting and stopping the programs covered in this book are covered in each respective chapter.

 

dhcpd.conf File

dhcpd.conf File


You can define your server configuration parameters in the dhcpd.conf file which may be located in the /etc the /etc/dhcpd or /etc/dhcp3 directories depending on your version of Linux.


Note: The skeleton dhcp.conf file that is created when you install the package may vary in its completeness. In Ubuntu / Debian, the skeleton dhcpd.conf file is extensive with most of the commands deactivated with a # sign at the beginning. In Fedora / RedHat / CentOS an extensive sample is also created with activated commands. It is found in the following location which you can always use as a guide.

 /usr/share/doc/dhcp*/dhcpd.conf.sample


Note: The dhcpd.conf configuration file formats in Debian / Ubuntu and Redhat / Fedora are identical.

Here is a quick explanation of the dhcpd.conf file: Most importantly, there must be a subnet section for each interface on your Linux box.

 ddns-update-style interim
ignore client-updates
 
subnet 192.168.1.0 netmask 255.255.255.0 {
 
   # The range of IP addresses the server
   # will issue to DHCP enabled PC clients
   # booting up on the network
 
   range 192.168.1.201 192.168.1.220;
 
   # Set the amount of time in seconds that
   # a client may keep the IP address
 
  default-lease-time 86400;
  max-lease-time 86400;
 
   # Set the default gateway to be used by
   # the PC clients
 
   option routers 192.168.1.1;
   # Don't forward DHCP requests from this
   # NIC interface to any other NIC
   # interfaces
 
   option ip-forwarding off;
 
   # Set the broadcast address and subnet mask
   # to be used by the DHCP clients
 
  option broadcast-address 192.168.1.255;
  option subnet-mask 255.255.255.0;
  
   # Set the NTP server to be used by the
   # DHCP clients
 
  option ntp-servers 192.168.1.100;
 
   # Set the DNS server to be used by the
   # DHCP clients
 
  option domain-name-servers 192.168.1.100;
 
   # If you specify a WINS server for your Windows clients,
   # you need to include the following option in the dhcpd.conf file:
 
  option netbios-name-servers 192.168.1.100;
 
   # You can also assign specific IP addresses based on the clients'
   # ethernet MAC address as follows (Host's name is "laser-printer":
 
  host laser-printer {
      hardware ethernet 08:00:2b:4c:59:23;
     fixed-address 192.168.1.222;
   }
}
#
# List an unused interface here
#
subnet 192.168.2.0 netmask 255.255.255.0 {
}

There are many more options statements you can use to configure DHCP. These include telling the DHCP clients where to go for services such as finger and IRC. Check the dhcp-options man page after you do your install:

 [root@bigboy tmp]# man dhcp-options


Note: The host statement seen in the sample dhcpd.conf file can be very useful. Some devices such as network printers default to getting their IP addresses using DHCP, but users need to access them by a fixed IP address to print their documents. This statement can be used to always provide specific IP address to DHCP queries from a predefined a NIC MAC address. This can help to reduce systems administration overhead.

 

Starting the DHCP Server

Starting the DHCP Server

The methodologies vary depending on the variant of Linux you are using as you'll see next.

Note: Make sure you configure your server before starting!


Fedora / CentOS / RedHat

With these flavors of Linux you can use the chkconfig command to get dhcpd configured to start at boot:

 [root@bigboy tmp]# chkconfig dhcpd on

To start, stop, and restart dhcpd after booting use the service command:

 [root@bigboy tmp]# service dhcpd start
[root@bigboy tmp]# service dhcpd stop
[root@bigboy tmp]# service dhcpd restart

To determine whether dhcpd is running you can issue either of these two commands. The first will give a status message. The second will return the process ID numbers of the dhcpd daemons.

 [root@bigboy tmp]# service dhcpd status
[root@bigboy tmp]# pgrep dhcpd

Note: Remember to run the chkconfig command at least once to ensure dhcpd starts automatically on your next reboot.


Ubuntu / Debian

With these flavors of Linux the commands are different. Try installing the sysv-rc-conf and sysvinit-utils DEB packages as they provide commands that simplify the process. For help on downloading and installing the packages, see Chapter 6, "Installing Linux Software".) You can use the sysv-rc-conf command to get dhcp3-server configured to start at boot:

 user@ubuntu:~$ sudo sysv-rc-conf dhcp3-server on

To start, stop, and restart dhcpd after booting the service command is the same:

 user@ubuntu:~$ sudo service dhcp3-server start
user@ubuntu:~$ sudo service dhcp3-server stop
user@ubuntu:~$ sudo service dhcp3-server restart

To determine whether dhcpd is running you can issue either of these two commands. The first will give a status message. The second will return the process ID numbers of the dhcpd daemons.

 user@ubuntu:~$ sudo service dhcp3-server status
user@ubuntu:~$ pgrep dhcp

Note: Remember to run the sysv-rc-conf command at least once to ensure mysql starts automatically on your next reboot.

Introduction

Introduction

Normally if you have a cable modem or DSL, you get your home PC's IP address dynamically assigned from your service provider. If you install a home cable/DSL router between your modem and home network, your PC will most likely get its IP address at boot time from the home router instead. You can choose to disable the DHCP server feature on your home router and set up a Linux box as the DHCP server.

This chapter covers only the configuration of a DHCP server that provides IP addresses. The configuration of a Linux DHCP client that gets its IP address from a DHCP server is covered in Chapter 3, "Linux Networking", on Linux Networking.

Conclusion

Conclusion

The topics discussed in this chapter might seem simple, but like syslog, which was covered in Chapter 5, "Troubleshooting Linux with syslog", they are an essential part of Linux administration that gets frequently overlooked especially when new software is installed.

Whenever possible, always try to reboot your system to make sure all the newly installed applications start up correctly. Sometimes they start but give errors listed only in the /var/log directory. Taking the time to configure and test your startup scripts could prevent you from being awakened in the middle of the night while you are on vacation! It is really important.

Using sysv-rc-conf to Start Daemons at Each runlevel

Using sysv-rc-conf to Start Daemons at Each runlevel

With Debian / Ubuntu Linux, the update-rc.d command replaces chkconfig as the default package for modifying /etc/init.d script links. Unfortunately, the utility was written to facilitate link modification when packages are installed or removed, but is less friendly when you need to alter links for existing packages you want to keep.

Fortunately there is hope for the harried systems administrator in the form of the sysv-rc-conf package which uses an almost identical syntax to chkconfig, and has a GUI mode if you run it from the command line without any arguments. This section will show you some important tips in using sysv-rc-conf.


Installing sysv-rc-conf

The sysv-rc-conf package can be installed easily using apt-get. Here is an example.

 root@u-bigboy:~# apt-get install sysv-rc-conf


Listing the runlevels for Daemons

This can be done with the --list option. In this example below we get a listing for only the apache daemon.

 root@u-bigboy:~#  sysv-rc-conf  --list apache
apache       0:off      1:off   2:on    3:on    4:on    5:on    6:off
root@u-bigboy:~#

Here we get a listing for everything.

 root@u-bigboy:~#  sysv-rc-conf  --list
acpi-support 0:off      1:off   2:on    3:on    4:on    5:on    6:off
acpid        0:off      1:off   2:on    3:on    4:on    5:on    6:off
alsa-utils   0:off      6:off
vbesave      2:on       3:on    4:on    5:on
x11-common   S:on
root@u-bigboy:~#


Setting the runlevels for Daemons

The sysv-rc-conf program has further similarities to the chkconfig syntax. Here we set the apache daemon to start automatically at levels 2 through 5.

 root@u-bigboy:~# sysv-rc-conf  apache on

Similarly, we can set the apache daemon not to start at levels 2 through 5 with this command:

 root@u-bigboy:~# sysv-rc-conf  apache off

Finally we can use set the apache daemon to start only at levels 3 and 5.

 root@u-bigboy:~# sysv-rc-conf  --level 35 apache on