Networking section

Routes under Debian

When you need to add a networking route, there generally are two ways to do it:

1. manually adding a route at the command prompt: this means that the machine will "understand" the route for as long as it is running. However, when you reboot the machine, it will have "forgotten" the route. This is called a non-persistent route.
2. adding a route to the networking configuration files, so that it will be in place regardless of reboots or network restarts. This is called a persistent route.

buy papers

Manipulating non-persistent routes

From the days of yore, the venerable route command enables us to view, add, change and delete routes. Its most known use is for printing the current routing table:

#route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.70.0    212.214.172.50  255.255.255.0   UG    0      0        0 eth1
192.168.67.0    *               255.255.255.0   U     0      0        0 eth0
212.214.172.0   *               255.255.255.0   U     0      0        0 eth1
default         212.214.172.1   0.0.0.0         UG    0      0        0 eth1

The addition of -n makes sure the route command does not try to substitute DNS names for IP addresses it knows. The second most used incarnation of route lies in the addition of a route, as has happened in the previous example. The route was added to the routing table using something like this:

#route add -net 192.168.70.0 netmask 255.255.255.0 gw 212.214.172.40

However, there is a newer command available to us, that gives us a bit more options (however, at the cost of losing the well-known output format): this is the ip command, which is part of the essential iproute2 package:

#ip route show
192.168.70.0/24 via 212.214.172.50 dev eth1  src 192.168.67.10
192.168.67.0/24 dev eth0  proto kernel  scope link  src 192.168.67.10
212.214.172.0/24 dev eth1  proto kernel  scope link  src 212.214.172.50
default via 212.214.172.1 dev eth1

This is the output from the same system as the previous example. However, we see something interesting here: "ip" is capable of adding extra information to the route, like the first line shows (it's using "via"). The addition of that particular route would go like this:

#ip route add 192.168.70.0/24 via 212.214.172.50 src 192.168.67.10

Ofcourse, being capable of adding routes means we also need to be capable of deleting them:

#route del -net 192.168.70.0 netmask 255.255.255.0
#ip route del 192.168.70.0/24

As you can see, we only need to specify the target of the route to delete, not the options.

Manipulating persistent routes

To make a route persistent across reboots, we need to enter them somewhere where they're saved. There are many possible routes available, but the two that fit Debian the most are the following:

A) You could add the route addition command to the /etc/network/interfaces file; let the command itself be preceeded with the keyword "up" to signal the networking scripts that the command must be executed when an interface is brought "up"; the line could look like this (just as the examples from the preceeding section):

# Internet interface
auto eth1
iface eth1 inet dhcp
up ip route add 192.168.70.0/24 via 212.214.172.50 src 192.168.67.10

Naturally, you could also use the route add command instead of the ip route add command, but we prefer ip. Note: it matters --where-- in the interfaces file you put this line: it should be put in the same stanza as the interface it operates on. In this example, the external interface of the server is 212.214.172.50, which belongs with interface eth1. Therefore, the "up" line appears in the stanza for eth1.

B) You could create a script that sets the route(s), and put it in the directory /etc/network/if-up.d. Since all scripts that reside there get called when any interface goes "up", your route setting script would be called when any interface comes up, including lo. This in turn means that a script for setting a route that belongs with a particular interface, should check on invocation which is the interface that goes up. At this moment in time, we don't employ any such script, so no example here, but if you look at the existing scripts in /etc/network/if-up.d you'll see how other programmers have done this.

DNS resolution under Debian

One headache you might encounter when configuring a Debian server is how to let every program know how to resolve DNS names. Before a program can connect to an external network resource (say, for example, a web server), it must have a means of converting DNS names (e.g. www.saruman.biz) into the corresponding IP addresses (e.g. 192.168.67.10). This process is called "name resolution". The need for name resolution means that every program needs to know about the available means by which to do this name resolution.

From the good old days comes the configuration file resolv.conf, normally found in /etc. It contains information about the nameservers to be used by the system, be they actual servers or lookup files. However, more and more programs have the need to dynamically modify the resolv.conf configuration file. This means that frequently they step on each other, and the resolv.conf file can become out-of-sync. The resolvconf program addresses this problem. It acts as an intermediary between programs that supply nameserver information (e.g. DHCP clients) and programs that use nameserver information (e.g. resolver).

When resolvconf is properly installed, the file /etc/resolv.conf is replaced by a symbolic link to /etc/resolvconf/run/resolv.conf, and any resolver thus uses the dynamically generated resolver configuration file at /etc/resolvconf/run/resolv.conf.

The resolvconf program is only necessary when a system has multiple programs that need to dynamically modify the nameserver information. In a simple system where the nameservers do not change often or are only changed by one program, the standard /etc/resolv.conf configuration file is adequate.

VLANs under Debian

Debian can support network traffic over VLANs (ethernet 802.1q) - and we don't mean the normal "untagged" network ports (hey, VLANs are transparent that way, anybody and anything can use untagged network ports). No, we mean that Debian can accept network traffic in from, and send traffic out to, a VLAN tagged switchport.

Suppose you have a layer 2 switch with support for 802.1q VLANs, and want to route traffic from one VLAN to another. For this you can use a Debian router with a single network interface, using VLAN support (this is called "router on a stick" because the routing takes place over only one cable).

First, as root, run

apt-get install vlan
modprobe 8021q

The first line is to install the vlan package, which contains all necessary tools to create and manipulate VLAN-enabled network ports. The second line loads the module that enables VLAN tagging for your ethernet network cards. Note: if you don't have the stock Debian kernel, but compiled your own, then you might have chosen not to compile the 8021q module. In that case, compile the module. Also note, that if you've compiled the 8021q code into the kernel itself, then you don't need to load the module and that second line is unnecessary for you. You'll find this kernel compile option (depending on your kernel version) under Networking -> Networking Options -> "802.1Q VLAN Support". This option has been in the Linux kernel since version 2.4.14.

ifconfig eth0 down
vconfig add eth0 2
vconfig add eth0 3

The first command brings down your network on eth0 (not the thing to do if you're working remote, then :-). The next two commands create two virtual interfaces eth0.2 and eth0.3, which have VLAN tags 2 and 3 (don't use VLAN tag 1 if you can help it; on many devices VLAN1 is a special hardware management VLAN). The virtual interfaces run on top of your eth0 interface.
Now because your VLAN interfaces run on top of eth0, you've got to bring eth0 itself up, even if you don't want to run network traffic over it. Furthermore, you've got to configure the two virtual interfaces you've created. Let's suppose you want to run IP subnet 192.168.1.0/24 on VLAN2, and 192.168.2.0/24 on VLAN3. You can do so with

ifconfig eth0 0.0.0.0 up
ifconfig eth0.2 192.168.1.1 broadcast 192.168.1.255 netmask 255.255.255.0 up
ifconfig eth0.3 192.168.2.1 broadcast 192.168.2.255 netmask 255.255.255.0 up

Now that you've this done, you must still configure one of your switch ports to belong to VLAN 2 and 3 at the same time (tagged port), and connect eth0 from your linux box to that port. This enables your box to run network traffic on both VLANs.

To round things up: if you haven't yet enabled forwarding, you can do so now. Furthermore, you might wish to augment your route table so that the routing engine in your server knows how to handle packets that it needs to forward from one VLAN to the other:

echo 1 > /proc/sys/net/ipv4/ip_forward
route add -net 10.1.1.0 netmask 255.255.255.0 gw eth0.2
route add -net 10.1.2.0 netmask 255.255.255.0 gw eth0.3

This is it; nothing to it, right?

Tunneling under Debian

Being a Linux distribution, Debian gives you all the networking power of that platform. One of the powerful features of Linux networking is the ease with which you can create network tunnels. Many possibilities exist; in this wiki we've documented the following:

• IPsec site-to-site tunnel with which you can connect two networks, so that machines in both networks can reach machines in the other network