In our last installment, Michael Martin continued his discussion of building a WLAN proxy server and explained how to set up the dhcpd.conf file.
A second dhcpd.conf example may seem a little excessive. But this second example shows both the flexibility of the ISC DHCP solution and the ease of which network access control can be implemented using DHCP. The operational goal here was to implement the same degree of "network services" segmentation achieved in the first example using different SSID segments by using a combination of a single SSID, DHCP and application layer service control. On the DHCP side, this example utilizes the same hybrid DHCP lease model where some of the subnets are "open" and the others are closed. The example diagram below depicts four DHCP client users, which will make up a population of our three different user access classes.
[IMAGE]
Network service access, in this model, is enforced by utilizing two different IP subnets on the same "physical" segment, with IP forwarding between the two segments disabled using ACL's on the router and server. This provides the capability to handle the traffic for each of the service classes differently. How we do this is the subject for the future articles in this series. In order to support the two different IP subnets, we first need to configure secondary interfaces on the IOS routers and *NIX WLAN server. On IOS routers this is accomplished using the <ip address x.x.x.x. x.x.x.x secondary> interface command:
A relic from the days before 802.1q, the IP secondary command still comes in handy, especially when the need to readdress a network segments comes up. Secondary interfaces on*NIX host's provide the ability to virtualize network services, such as Web or FTP servers. They are added simply using the ifconfig command:
Secondary interfaces can ...
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
be configured on both 802.1Q and non-Q *NIX server interfaces. However, iptables filtering can only be applied to primary interfaces, so when implementing filtering rules the primary, not secondary interface need to be defined. Now let's move onto the DHCP configuration. The global declarations for this configuration are, for the most part, the same as the previous DHCP configuration:
In the previous dhcpd.conf example a separate subnet declaration was configured for each IP segment. Here, both segments and three IP address pools are configured within the shared-network declaration, which is required because we are utilizing two different IP networks. What is also required is a way to distinguish which hosts are assigned to what pool. Otherwise the server just allocates leases out of the available pools. To properly direct the users a closed lease policy is used with one of the IP subnets and an open lease policy is used with the other -- a feat that is easily accomplished by using the <deny unknown clients> in the first subnets pool and group declarations:
Now, with the IP allocations of both pool and group definitions within the first subnet open only to known clients, all of the unknown client's, i.e., "HTTP Only users," lease requests fall to the second subnet declaration.
Granted this is not the most advanced network access control solution around, but it's quite effective with the added benefit of reducing the wireless RF/SSID complexity and the potential for expanded network range and improved performance. We will examine other potential benefits to this approach when we start to implement Web caching. So, now as we have come to the end of our long journey through the dhcpd.conf jungle, its time to look at controlling the wily dhcp daemon.
Starting and stopping DHCPD
The ISC DHCP can be launched from the command prompt (assuming you are using the default configuration by simply typing):
To launch the service using our chroot cell configuration the command line is a little busier than the default, which requires the user and group and chroot cell to be defined along with the configuration file:
While launching from the command line is fine, it's far better to have the system launch the service as part of the boot process. Now, if DHCP was one of those "run and forget" types of applications we could just add the command line to the /etc/rc3.d/S99local file and it would be loaded at the end of the bootstrap process. However, with ISC DHCP it's not that easy; the process needs to be restarted each time changes are made to the dhcpd.conf file. And it's more than likely we will need to make changes to the dhcpd.confM file with regular frequency since we are running a hybrid lease policy. So to make our lives easier we need to build an rc script to drop into /etc/rc3.d that will let us start and stop the DHCP service with ease.
Operation of the script is simple. To start the DHCP service from the command line, use the following:
To stop the DHCP service from the command line, use the following:
The script is based on the standard Red Hat rc scripts. It should be named S96dhcpd and installed in /etc/rc3.d. Once installed, it will be executed as part of the systems bootstrap process.
Now, with the standard control stuff out of the way, there is only one other problem we need to address. As DHCP is a critical path network service, we need to make sure that it stays up all of the time. The network is not much use if you can get an IP address. For this problem, we need to set up a CRON job that will run a check script. Now the S96dhcpd rc script starts and stops the service; it does not check to see if it's running; it assumes it's not. After all, it's a bootstrap script. Here is a DHCPd control script that lets you stop and start the service, but also checks to see if it's running and if so, does nothing, and if not starts the service -- perfect for running CRON checks:
Install this script in the same directory that dhcpd service daemon is, /usr/local/dhcpd/sbin, named dhcp-ctl.sh. To check if the DHCP service is running (or start the service), just run the script:
To stop the DHCP service run the script with the "–k" flag:
For best results the check script should be run every five minutes using CRON. Here is how you set it up. First open the crontab file for the user root:
This will run your default text editor (more than likely it will VI) and in most cases the crontab file will be blank, now add:
This configures CRON to run the /usr/local/dhcpd/sbin/dhcp-ctl.sh every five minutes. Once you save the file and exit the editor, CRON installs the crontab file and starts to process the job.
Monitoring DHCPD
ISC DHCP stores information on its operation in two different files. Information on IP address bindings is stored in /usr/local/dhcpd/var/state/dhcp/dhcpd.leases. Here is a sample:
The ISC service cannot start without this file and if the file becomes corrupted or is deleted, all of the previously assigned lease information is lost. If you want to find out what host got what address, the dhcpd.leases file is the first place to check.
To see information on the operational status and DHCP event processing you need to check the log file. Unless specified, DHCPd will send log data to the systems standard log file /var/messages. To set up an individual log file for DHCPd, start off by defining a SYSLOG facility in the dhcpd.conf file.
Once the facility has been defined, the SYSLOG daemon needs to be configured to send any messages sent to the log facility (in this case local5) we have defined in dhcpd.conf. The SYSLOGd configuration file is located in /etc. For our purposes we want SYSLOGd to send log messages to /usr/local/dhcpd/var/log/dhcp.log. Before we edit /etc/syslog.conf we need to create the log file (and the directories where it's stored):
With the directories built we can edit /etc/syslog.conf:
Once /etc/syslog.conf has been edited, we need to restart the syslogd service using the rc file S12syslog bootstrap script:
Once the logfile has been configured we can monitor the servers operation and DHCP event processing using the tail command with the "-f" operator flag:
Conclusion
That's a wrap for ISC DHCP. Tune in next month for implementing Web proxy auto-detection.
About the author:
Michael J. Martin has been working in the information technology field as a network and Unix system admin for over 10 years. What's his biggest strength as an expert? He says it's his "broad base of experience in working in the ISP/carrier and enterprise spaces as both a systems and a network engineer." His background in designing, implementing, and supporting MIS infrastructures for research and ISPs gives him a unique perspective on large-scale internetworking and security architecture. Michael shares his wealth of knowledge in his monthly Router Expert series.
