Configuring a Linux Wireless Access Point

In this second part of a five-part series on building a Linux wireless access point, you’ll learn how to set up name services, set static IP addresses, and more. This article is excerpted from chapter four of the Linux Networking Cookbook, written by Carla Schroder (O’Reilly; ISBN: 0596102488). Copyright © 2008 O’Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O’Reilly Media.

4.3 Setting Up Name Services

Problem

Your LAN is going to have a combination of hosts with static IP addresses and DHCP clients that come and go, especially wireless clients. And, you want DHCP clients to automatically be entered into DNS so they can be accessed by hostname just like the hosts with static IP addresses.

Solution

You don’t want much. Fortunately, you can have it all. Pyramid comes with dnsmasq, which handles DHCP and DNS, and automatically enters DHCP clients into DNS. This requires the clients to send their hostnames when they are requesting a DHCP lease. Windows clients do this by default. Most Linux clients do not, so go to Recipe 4.5 to learn about client configuration.

Now, we’ll edit /etc/dnsmasq.conf on your Pyramid box. First make the filesystem writeable by running /sbin/rw . Copy this example, using your own network name instead of alrac.net, whatever DHCP range you prefer, and your own upstream nameservers:

  pyramid:~# /sbin/rw
  pyramid:~# nano /etc/dnsmasq.conf

  domain-needed
  bogus-priv
  local=/alrac.net/
  expand-hosts
  domain=alrac.net
  interface=br0
  listen-address=127.0.0.1

  #upstream nameservers
  server=22.33.44.2
  server=22.33.44.3

  dhcp-range=lan,192.168.1.100,192.168.1.200,12h
  dhcp-lease-max=100

Next, add all of your hosts that already have static IP addresses to /etc/hosts on your Pyramid box, using only their hostnames and IP addresses. At a minimum, you must have an entry for localhost and your Pyramid router:

  ## /etc/hosts
  127.0.0.1      localhost
  192.168.1.50   pyramid
  192.168.1.10   xena
  192.168.1.74   uberpc

Restart dnsmasq:

  pyramidwrap:~# killall dnsmasq

To test your new nameserver, ping your LAN hosts from each other:

  $ ping pyramid
  $ ping xena
  $ ping uberpc

You should see responses like this:

  PING pyramid.alrac.net (192.168.1.50) 56(84) bytes of data.
  64 bytes from pyramid.alrac.net (192.168.1.50): icmp_seq=1 ttl=64 time=0.483 ms
  64 bytes from pyramid.alrac.net (192.168.1.50): icmp_seq=2 ttl=64 time=0.846 ms

You should be able to ping both wired and wireless clients, and DHCP clients should be entered automatically into the DNS table as well.

Finally, verify that their domain names are correctly assigned by DNS:

  $ hostname
  xena
 
$ hostname -f
 
xena.alrac.net
  $ dnsdomainname
 
alrac.net

Discussion

Pyramid Linux mounts a number of files into a temporary, writeable filesystem, like /etc/resolv.conf. You can see which ones they are by looking in /rw, or running ls -l /etc to see which ones are symlinked to /rw. These are copied over from /ro on boot. It’s designed to keep flash writes down. So, you can either edit /ro, or make the files in /etc immutable.

dnsmasq.conf crams a lot of functionality into a few lines, so let’s take a closer look:

domain-needed

Do not forward requests for plain hostnames that do not have dots or domain parts to upstream DNS servers. If the name is not in /etc/hosts or DHCP, it returns a “not found” answer. This means that incomplete requests (for exam ple, “google” or “oreilly” instead of google.com or oreilly.com) will be cut off before they leave your network.

bogus-priv

Short for “bogus private lookups.” Any reverse lookups for private IP ranges (such as 192.168.x.x) are not forwarded upstream. If they aren’t found in /etc/hosts, or the DHCP leases file, “no such domain” is the answer. Using domain-needed and bogus-priv are simple options for practicing good Netizenship.

local=/alrac.net/

Put your local domain name here so queries for your local domain will only be answered from /etc/hosts and DHCP, and not forwarded upstream. This is a nice bit of magic that lets you choose any domain name for your private network and not have to register it. To make this work right, you also need the expand-hosts and domain options.

expand-hosts

This automatically adds the domain name to the hostnames.

domain=alrac.net

expand-hosts looks here for the domain name.

interface

Define which interface dnsmasq should listen to. Use one line per interface, if you have more than one.

listen-address=127.0.0.1

This tells dnsmasq to also use its own local cache instead of querying the upstream nameservers for every request. This speeds up lookups made from the router, and it also allows the router to use your local DNS. You can verify this by pinging your LAN hosts from the router by their hostnames or FQDNs.

server

The server option is used for several different purposes; here, it defines your upstream DNS servers.

dhcp-range=lan,192.168.1.100,192.168.1.200,12h

Define your pool of DHCP leases and lease time, and define a network zone called “lan.” Using named zones lets you assign servers and routes to groups of clients and different subnets; see Recipe 3.13 to see this in action.

dhcp-max-lease

Maximum limit of total DHCP leases. The default is 150. You may have as many as your address range supports.

See Also

  1. Recipe 4.12 for an example of using named zones
  2. man 8 dnsmasq contains a wealth of helpful information about all the available command-line options, many of which are also dnsmasq.conf options
  3. dnsmasq.conf is also a great help resource
  4. dnsmasq home page is where you’ll find mailing list archives and excellent help documents: http://www.thekelleys.org.uk/dnsmasq/doc.html
  5. Chapter 24, “Managing Name Resolution,” in Linux Cookbook, by Carla Schroder (O’Reilly)

{mospagebreak title=4.4 Setting Static IP Addresses from the DHCP Server}

Problem

You want to manage your LAN computers from DHCP instead of configuring them individually, so you don’t have to run around tweaking individual computers all the time. You want to assign static and dynamic IP addresses, gateways, and servers all via DHCP.

Solution

dnsmasq does it all. There are a couple of ways to assign static IP addresses from dnsmasq.conf. One is to use the client’s MAC address as the client identifier, like this: 

  dhcp-host=11:22:33:44:55:66,192.168.1.75

My favorite way is to set it by hostname:

  dhcp-host=penguina,192.168.1.75

Make sure you do not have entries for these in /etc/hosts.

The only client configuration that’s necessary is the hostname, and for DHCP clients to send the hostname to the DHCP server when they request a new lease. Once you have that, you can control everything else from the server.

Remember to run killall dnsmasq every time you change dnsmasq.conf.

There are some tricky bits to client configuration, so see Recipe 4.5 for this.

Discussion

Changes in dnsmasq.conf are easy to test. After restarting dnsmasq, try the following commands on your Linux clients.

ifupdown stops and restarts interfaces:

  # ifdown eth0
  # ifup etho

Sometimes, that doesn’t quite do the job, so you can also try:

  # /etc/init.d/network restart
  # /etc/init.d/networking restart

The first one is for Fedora, the second for Debian. You’ll see it acquire the address you assigned it from the DHCP server, and it will write the correct DNS server or servers to /etc/resolv.conf.

If those don’t work, reboot.

Find MAC addresses with ifconfig for wired NICs, and iwconfig for wireless NICs. ifconfig sees both, but it doesn’t differentiate them. iwconfig identifies only wireless interfaces.

When you use the MAC address, don’t forget to change the entry in dnsmasq.conf if you replace the client’s network interface card.

MAC addresses are unique, but hostnames are not, so you have to be careful not to have duplicate hostnames. You can’t have duplicate hostnames, anyway.

MAC addresses are ridiculously easy to spoof, so don’t think you’re adding any security by relying on them as secure, unique identifiers.

See Also

  1. man 8 dnsmasq contains a wealth of helpful information about all the available command-line options, many of which are also dnsmasq.conf options
  2. dnsmasq.conf is also a great help resource
  3. dnsmasq home page (http://www.thekelleys.org.uk/dnsmasq/doc.html) is where you’ll find mailing list archives and excellent help documents
  4. Chapter 24, “Managing Name Resolution,” in Linux Cookbook, by Carla Schroder (O’Reilly)

{mospagebreak title=4.5 Configuring Linux and Windows Static DHCP Clients}

Problem

What with having both Linux and Windows clients, and various Linux distributions that like to do things their own way, you’re a bit befuddled as to how to configure them to have dnsmasq give them static IP addresses.

Solution

The key to getting static IP addresses from DHCP is for the clients to send their host-names to the DHCP server when they request a lease.

Windows 2000, 2003, and XP clients do this automatically. All you do is configure them for DHCP in the usual manner.

First, on all Linux machines, make sure there is nothing in /etc/hosts other than the localdomain entry.

Most Linux distributions are not configured to send the hostname by default. To fix this, add one line to their DHCP client files. On Debian, this is the /etc/dhcp3/ dhclient.conf file. This example is for the computer named Penguina:

  send host-name "penguina";

You must also enter the hostname in /etc/hostname:

  penguina

Just the hostname and nothing else. Then, set up the normal DHCP configuration in /etc/network/interfaces, like this:

  ##/etc/network/interface s
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet dhcp

On Fedora, each interface gets its own DHCP client file, like /etc/dhclient-eth1. You may need to create this file. This takes the same send host-name "penguina"; entry. Then, add this line to /etc/sysconfig/network-scripts/ifcfg-eth0:

  DHCP_HOSTNAME=penguina

Make sure the HOSTNAME line in /etc/sysconfig/network is empty.

The sure way to test your new configurations is to reboot, then run these commands:

  $ hostname
 
penguina
 
$ hostname -f
 
penguina.alrac.net
 
$ dnsdomainname
  alrac.net

Ping will look like this:

  carla@xena:~$ ping penguina
  PING penguina.alrac.net (192.168.1.75) 56(84) bytes of data.
  64 bytes from penguina.alrac.net (192.168.1.75): icmp_seq=1 ttl=128 time=8.90 ms
  carla@penguina:~$ ping penguina
 
PING penguina.alrac.net (192.168.1.75) 56(84) bytes of data.
  64 bytes from penguina.alrac.net (192.168.1.75): icmp_seq=1 ttl=64 time=0.033 ms

Discussion

The most common cause of problems with this is not configuring the hostname correctly. Check all of your pertinent configuration files.

Here is a complete example Fedora configuration for eth0:

  ##/etc/sysconfig/network-scripts/
ifcfg-eth 0
  DEVICE=eth0
  ONBOOT=yes
  BOOTPROTO=dhcp
  HWADDR=11.22.33.44.55.66
  DHCP_HOSTNAME=penguina
  TYPE=wireless
  PEERDNS=yes
  MODE=managed
  RATE=auto

Either edit Fedora configuration files directly, or use the graphical network configurator, but don’t use both because the graphical tool overwrites your manual edits.

dnsmasq automatically enters DHCP clients into DNS. This is a great convenience, and when you deploy IPv6, it will be more than a convenience—it will be a necessity, unless you’re comfortable with remembering and typing those long IPv6 addresses.

dnsmasq combines a lot of complex functions into a short configuration file, and can be used in conjunction with BIND, djbdns, MaraDNS, and other nameservers. Use dnsmasq for your private LAN services, and one of the others for a public authoritative server. This makes it easy to keep the two completely separate, as they should be. Remember the number one DNS server rule: keep your authoritative and caching servers strictly separated, which means using two physically separate network interfaces and different IP addresses. Authoritative servers do not answer queries for other domains; that is the job of a caching resolver like dnsmasq. Maintaining two separate servers might sound like more work, but in practice, it’s easier and safer than trying to configure a single server to handle both jobs.

See Also

  • man 5 dhclient
  • dnsmasq.conf is a great help resource
  • dnsmasq home page (http://www.thekelleys.org.uk/dnsmasq/doc.html) is where you’ll find mailing list archives and excellent help documents
  • Chapter 24, “Managing Name Resolution,” in Linux Cookbook, by Carla Schroder (O’Reilly)

{mospagebreak title=4.6 Adding Mail Servers to dnsmasq}

Problem

You have some local mail servers that you want your LAN hosts to know about. How do you do this with dnsmasq?

Solution

dnsmasq has a special record type for mailservers. You need these three lines:

  mx-host=alrac.net,mail.alrac.net, 5
  mx-target=mail.alrac.net
  localmx

The mx-host line needs the domain name, server name, and MX priority. The mx-target line is the server name. localmx means all local machines should use this server.

Discussion

A priority number of 5 means the server is higher priority than servers with larger numbers, typically 10 and then multiples of 10. If you have only one mail server, you should still give it a priority to keep clients happy.

See Also

  • man 5 dhclient
  • dnsmasq.conf is also a great help resource
  • dnsmasq home page (http://www.thekelleys.org.uk/dnsmasq/doc.html) is where you’ll find mailing list archives and excellent help documents
  • Chapter 24, “Managing Name Resolution,” in Linux Cookbook, by Carla Schroder (O’Reilly)

Please check back for the next part of the series.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye