This section covers information specific to IP.
DHCP is an acronym for Dynamic Host Configuration Protocol. The creation of DHCP has made configuring the network on multiple hosts extremely simple. Instead of having to configure each host separately you can assign all of the commonly used parameters by the hosts using a DHCP server.
Each time the host boots up it will broadcast a packet to the network. This packet is a call to any DHCP servers that are located on the same segment to configure the host.
DHCP is extermely useful in assigning items such as the IP address, Netmask, and gateway of each host.
Under linux as the user root start the program linuxconf. This program comes with all versions of redhat and works with X as well as the console. It also works for SuSe, and Caldera.
Select Networking
----------------->Basic Host Information
----------------->Select Enable
----------------->Set Config Mode DHCP
Retrieve DHCPD if your machine does not already have it installed. Get DHCPD
Quick Note: MAKE SURE YOU HAVE MULTICAST ENABLED IN THE KERNEL.
If there is not a binary distribution for your version of linux you will have to compile DHCPD.
Edit your /etc/rc.d/rc.local to reflect an addition of a route for 255.255.255.255.
Quoted from DHCPd README:
In order for dhcpd to work correctly with picky DHCP clients (e.g., Windows 95), it must be able to send packets with an IP destination address of 255.255.255.255. Unfortunately, Linux insists on changing 255.255.255.255 into the local subnet broadcast address (here, that's 192.5.5.223). This results in a DHCP protocol violation, and while many DHCP clients don't notice the problem, some (e.g., all Microsoft DHCP clients) do. Clients that have this problem will appear not to see DHCPOFFER messages from the server.
Type the following as root:
route add -host 255.255.255.255 dev eth0
If the message appears:
255.255.255.255: Unknown host
Try adding the following entry to your /etc/hosts file:
255.255.255.255 dhcp
Then, try:
route add -host dhcp dev eth0
Now you need to configure DHCPd. In order to do this you will have to create or edit /etc/dhcpd.conf. There is a graphical interface for dhcpd configuration under linuxconf. This makes configuring and managing DHCPD extremely simple.
If you want to configure it by hand follow instructions below. I suggest configuring it by hand at least once. It will help in the diagnostics that a GUI can't give you. Unfortunately Micrsoft doesn't believe this.
The easiest thing to do is assign IP addresses randomly. Below is a sample configuration file that shows this type of setup.
# Sample /etc/dhcpd.conf
# (add your comments here)
default-lease-time 1200;
max-lease-time 9200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-name "mydomain.org";
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
range 192.168.1.150 192.168.1.200;
}
This will allow the DHCP server to assign the client an IP address from the range 192.168.1.10-192.168.1.100 or 192.168.1.150-192.168.1.200.
It will lease an IP address for 1200 seconds if the client doesn't request a longer time frame. Otherwise the maximum (allowed) lease the server will allow is 9200 seconds. The server send the following paramaters to the client:
Use 255.255.255.0 as your subnet mask Use 192.168.1.255 as your broadcast address Use 192.168.1.254 as your default gateway USE 192.168.1.1 and 192.168.1.2 as your DNS servers.
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.1;
You can also assign specific IP addresses based on clients ethernet MAC address e.g.
host haagen {
hardware ethernet 08:00:2b:4c:59:23;
fixed-address 192.168.1.222;
}
This will assign IP address 192.168.1.222 to a client with ethernet MAC address of 08:00:2b:4c:59:23.
In most cases the DHCP installation doesn't create a dhcpd.leases file. Therefore before you start the server you must type to create an empty file:
touch /var/state/dhcp/dhcpd.leases
To start the DHCP server, simply type (or include in the bootup scripts)
/usr/sbin/dhcpd
This will start dhcpd on eth0 device. If you need to start it on another device simply supply it on the command line e.g.
/usr/sbin/dhcpd eth1
If you wish to test the configuration for any oddities you can start dhcpd with the debugging mode. Typing the command below will allow you to see exactly what is going on with the server.
/usr/sbin/dhcpd -d -f
Boot up a client take a look at the console of the server. You will see a number of debugging messages come up.
Your done
The EQL device name is `eql'. With the standard kernel source you may have
only one EQL device per machine. EQL provides a means of utilizing multiple
point to point lines such as PPP, slip or plip as a single logical link to
carry tcp/ip. Often it is cheaper to use multiple lower speed lines than to
have one high speed line installed.
Kernel Compile Options:
Network device support --->
[*] Network device support
<*> EQL (serial line load balancing) support
To support this mechanism the machine at the other end of the lines must also support EQL. Linux, Livingstone Portmasters and newer dial-in servers support compatible facilities.
To configure EQL you will need the eql tools which are available from: metalab.unc.edu.
Configuration is fairly straightforward. You start by configuring the eql interface. The eql interface is just like any other network device. You configure the IP address and mtu using the ifconfig utility, so something like:
root# ifconfig eql 192.168.10.1 mtu 1006
Next you need to manually initiate each of the lines you will use. These may be any combination of point to point network devices. How you initiate the connections will depend on what sort of link they are, refer to the appropriate sections for further information.
Lastly you need to associate the serial link with the EQL device, this is called `enslaving' and is done with the eql_enslave command as shown:
root# eql_enslave eql sl0 28800
root# eql_enslave eql ppp0 14400
The `estimated speed' parameter you supply eql_enslave doesn't do anything directly. It is used by the EQL driver to determine what share of the datagrams that device should receive, so you can fine tune the balancing of the lines by playing with this value.
To disassociate a line from an EQL device you use the eql_emancipate command as shown:
root# eql_emancipate eql sl0
You add routing as you would for any other point to point link, except your
routes should refer to the eql device rather than the actual serial
devices themselves, typically you would use:
root# route add default eql
The EQL driver was developed by Simon Janes, simon@ncm.com.
The IP accounting features of the Linux kernel allow you to collect and analyze some network usage data. The data collected comprises the number of packets and the number of bytes accumulated since the figures were last reset. You may specify a variety of rules to categorize the figures to suit whatever purpose you may have. This option has been removed in kernel 2.1.102, because the old ipfwadm-based firewalling was replaced by ``ipfwchains''.
Kernel Compile Options:
Networking options --->
[*] IP: accounting
After you have compiled and installed the kernel you need to use the ipfwadm command to configure IP accounting. There are many different ways of breaking down the accounting information that you might choose. I've picked a simple example of what might be useful to use, you should read the ipfwadm man page for more information.
Scenario: You have a ethernet network that is linked to the internet via a PPP link. On the ethernet you have a machine that offers a number of services and that you are interested in knowing how much traffic is generated by each of ftp and world wide web traffic, as well as total tcp and udp traffic.
You might use a command set that looks like the following, which is shown as a shell script:
#!/bin/sh
#
# Flush the accounting rules
ipfwadm -A -f
#
# Set shortcuts
localnet=44.136.8.96/29
any=0/0
# Add rules for local ethernet segment
ipfwadm -A in -a -P tcp -D $localnet ftp-data
ipfwadm -A out -a -P tcp -S $localnet ftp-data
ipfwadm -A in -a -P tcp -D $localnet www
ipfwadm -A out -a -P tcp -S $localnet www
ipfwadm -A in -a -P tcp -D $localnet
ipfwadm -A out -a -P tcp -S $localnet
ipfwadm -A in -a -P udp -D $localnet
ipfwadm -A out -a -P udp -S $localnet
#
# Rules for default
ipfwadm -A in -a -P tcp -D $any ftp-data
ipfwadm -A out -a -P tcp -S $any ftp-data
ipfwadm -A in -a -P tcp -D $any www
ipfwadm -A out -a -P tcp -S $any www
ipfwadm -A in -a -P tcp -D $any
ipfwadm -A out -a -P tcp -S $any
ipfwadm -A in -a -P udp -D $any
ipfwadm -A out -a -P udp -S $any
#
# List the rules
ipfwadm -A -l -n
#
The names ``ftp-data'' and ``www'' refer to lines in
/etc/services. The last command lists each of the Accounting
rules and displays the collected totals.
An important point to note when analyzing IP accounting is that totals for all rules that match will be incremented so that to obtain differential figures you need to perform appropriate maths. For example if I wanted to know how much data was not ftp nor www I would substract the individual totals from the rule that matches all ports.
root# ipfwadm -A -l -n
IP accounting rules
pkts bytes dir prot source destination ports
0 0 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 20
0 0 out tcp 44.136.8.96/29 0.0.0.0/0 20 -> *
10 1166 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 80
10 572 out tcp 44.136.8.96/29 0.0.0.0/0 80 -> *
252 10943 in tcp 0.0.0.0/0 44.136.8.96/29 * -> *
231 18831 out tcp 44.136.8.96/29 0.0.0.0/0 * -> *
0 0 in udp 0.0.0.0/0 44.136.8.96/29 * -> *
0 0 out udp 44.136.8.96/29 0.0.0.0/0 * -> *
0 0 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 20
0 0 out tcp 0.0.0.0/0 0.0.0.0/0 20 -> *
10 1166 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 80
10 572 out tcp 0.0.0.0/0 0.0.0.0/0 80 -> *
253 10983 in tcp 0.0.0.0/0 0.0.0.0/0 * -> *
231 18831 out tcp 0.0.0.0/0 0.0.0.0/0 * -> *
0 0 in udp 0.0.0.0/0 0.0.0.0/0 * -> *
0 0 out udp 0.0.0.0/0 0.0.0.0/0 * -> *
The new accounting code is accessed via ``IP Firewall Chains''.
See
the IP chains home page for more information. Among other
things, you'll now need to use ipchains instead of ipfwadm
to configure your filters. (From Documentation/Changes in the
latest kernel sources).
There are some applications where being able to configure multiple IP addresses to a single network device is useful. Internet Service Providers often use this facility to provide a `customized' to their World Wide Web and ftp offerings for their customers. You can refer to the ``IP-Alias mini-HOWTO'' for more information than you find here.
Kernel Compile Options:
Networking options --->
....
[*] Network aliasing
....
<*> IP: aliasing support
After compiling and installing your kernel with IP_Alias support
configuration is very simple. The aliases are added to virtual network
devices associated with the actual network device. A simple naming
convention applies to these devices being <devname>:<virtual
dev num>, e.g. eth0:0, ppp0:10 etc. Note that the the
ifname:number device can only be configured after the main
interface has been set up.
For example, assume you have an ethernet network that supports two different IP subnetworks simultaneously and you wish your machine to have direct access to both, you could use something like:
root# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# ifconfig eth0:0 192.168.10.1 netmask 255.255.255.0 up
root# route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0
To delete an alias you simply add a `-' to the end of its name and refer
to it and is as simple as:
root# ifconfig eth0:0- 0
All routes associated with that alias will also be deleted automatically.
IP Firewall and Firewalling issues are covered in more depth in the Firewall-HOWTO. IP Firewalling allows you to secure your machine against unauthorized network access by filtering or allowing datagrams from or to IP addresses that you nominate. There are three different classes of rules, incoming filtering, outgoing filtering and forwarding filtering. Incoming rules are applied to datagrams that are received by a network device. Outgoing rules are applied to datagrams that are to be transmitted by a network device. Forwarding rules are applied to datagrams that are received and are not for this machine, ie datagrams that would be routed.
Kernel Compile Options:
Networking options --->
[*] Network firewalls
....
[*] IP: forwarding/gatewaying
....
[*] IP: firewalling
[ ] IP: firewall packet logging
Configuration of the IP firewall rules is performed using the ipfwadm command. As I mentioned earlier, security is not something I am expert at, so while I will present an example you can use, you should do your own research and develop your own rules if security is important to you.
Probably the most common use of IP firewall is when you are using your linux machine as a router and firewall gateway to protect your local network from unauthorized access from outside your network.
The following configuration is based on a contribution from Arnt Gulbrandsen,
<agulbra@troll.no>.
The example describes the configuration of the firewall rules on the Linux firewall/router machine illustrated in this diagram:
- -
\ | 172.16.37.0
\ | /255.255.255.0
\ --------- |
| 172.16.174.30 | Linux | |
NET =================| f/w |------| ..37.19
| PPP | router| | --------
/ --------- |--| Mail |
/ | | /DNS |
/ | --------
- -
The following commands would normally be placed in an rc file
so that they were automatically started each time the system
boots. For maximum security they would be performed after the network
interfaces are configured, but before the interfaces are actually
brought up to prevent anyone gaining access while the firewall machine
is rebooting.
#!/bin/sh
# Flush the 'Forwarding' rules table
# Change the default policy to 'accept'
#
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p accept
#
# .. and for 'Incoming'
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p accept
# First off, seal off the PPP interface
# I'd love to use '-a deny' instead of '-a reject -y' but then it
# would be impossible to originate connections on that interface too.
# The -o causes all rejected datagrams to be logged. This trades
# disk space against knowledge of an attack of configuration error.
#
/sbin/ipfwadm -I -a reject -y -o -P tcp -S 0/0 -D 172.16.174.30
# Throw away certain kinds of obviously forged packets right away:
# Nothing should come from multicast/anycast/broadcast addresses
#
/sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24
#
# and nothing coming from the loopback network should ever be
# seen on a wire
#
/sbin/ipfwadm -F -a deny -o -S 127.0/8 -D 172.16.37.0/24
# accept incoming SMTP and DNS connections, but only
# to the Mail/Name Server
#
/sbin/ipfwadm -F -a accept -P tcp -S 0/0 -D 172.16.37.19 25 53
#
# DNS uses UDP as well as TCP, so allow that too
# for questions to our name server
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 -D 172.16.37.19 53
#
# but not "answers" coming to dangerous ports like NFS and
# Larry McVoy's NFS extension. If you run squid, add its port here.
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 53 \
-D 172.16.37.0/24 2049 2050
# answers to other user ports are okay
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 53 \
-D 172.16.37.0/24 53 1024:65535
# Reject incoming connections to identd
# We use 'reject' here so that the connecting host is told
# straight away not to bother continuing, otherwise we'd experience
# delays while ident timed out.
#
/sbin/ipfwadm -F -a reject -o -P tcp -S 0/0 -D 172.16.37.0/24 113
# Accept some common service connections from the 192.168.64 and
# 192.168.65 networks, they are friends that we trust.
#
/sbin/ipfwadm -F -a accept -P tcp -S 192.168.64.0/23 \
-D 172.16.37.0/24 20:23
# accept and pass through anything originating inside
#
/sbin/ipfwadm -F -a accept -P tcp -S 172.16.37.0/24 -D 0/0
# deny most other incoming TCP connections and log them
# (append 1:1023 if you have problems with ftp not working)
#
/sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 -D 172.16.37.0/24
# ... for UDP too
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 -D 172.16.37.0/24
Good firewall configurations are a little tricky. This example should be a reasonable starting point for you. The ipfwadm manual page offers some assistance in how to use the tool. If you intend to configure a firewall, be sure to ask around and get as much advice from sources you consider reliable and get someone to test/sanity check your configuration from the outside.
The new firewalling code is accessed via ``IP Firewall Chains''.
See
the IP chanins home page for more information. Among other
things, you'll now need to use ipchains instead of ipfwadm
to configure your filters. (From Documentation/Changes in the
latest kernel sources).
We are aware that this is a sorely out of date statement and we are currently working on getting this section more current. You can expect a newer version in sometime 1999.
Why would you want to encapsulate IP datagrams within IP datagrams? It must seem an odd thing to do if you've never seen an application of it before. Ok, here are a couple of common places where it is used: Mobile-IP and IP-Multicast. What is perhaps the most widely spread use of it though is also the least well known, Amateur Radio.
Kernel Compile Options:
Networking options --->
[*] TCP/IP networking
[*] IP: forwarding/gatewaying
....
<*> IP: tunneling
IP tunnel devices are called `tunl0', `tunl1' etc.
"But why ?". Ok, ok. Conventional IP routing rules mandate that an IP network comprises a network address and a network mask. This produces a series of contiguous addresses that may all be routed via a single routing entry. This is very convenient, but it means that you may only use any particular IP address while you are connected to the particular piece of network to which it belongs. In most instances this is ok, but if you are a mobile netizen then you may not be able to stay connected to the one place all the time. IP/IP encapsulation (IP tunneling) allows you to overcome this restriction by allowing datagrams destined for your IP address to be wrapped up and redirected to another IP address. If you know that you're going to be operating from some other IP network for some time you can set up a machine on your home network to accept datagrams to your IP address and redirect them to the address that you will actually be using temporarily.
192.168.1/24 192.168.2/24
- -
| ppp0 = ppp0 = |
| aaa.bbb.ccc.ddd fff.ggg.hhh.iii |
| |
| /-----\ /-----\ |
| | | // | | |
|---| A |------//---------| B |---|
| | | // | | |
| \-----/ \-----/ |
| |
- -
Linux router `A' would be configured with a script like the following:
#!/bin/sh
PATH=/sbin:/usr/sbin
mask=255.255.255.0
remotegw=fff.ggg.hhh.iii
#
# Ethernet configuration
ifconfig eth0 192.168.1.1 netmask $mask up
route add -net 192.168.1.0 netmask $mask eth0
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.1.1 up
route add -net 192.168.2.0 netmask $mask gw $remotegw tunl0
Linux router `B' would be configured with a similar script:
#!/bin/sh
PATH=/sbin:/usr/sbin
mask=255.255.255.0
remotegw=aaa.bbb.ccc.ddd
#
# Ethernet configuration
ifconfig eth0 192.168.2.1 netmask $mask up
route add -net 192.168.2.0 netmask $mask eth0
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.2.1 up
route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
The command:
route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
192.168.1.0/24 inside an
IPIP encap datagram with a destination address of aaa.bbb.ccc.ddd'.
Note that the configurations are reciprocated at either end. The tunnel device
uses the `gw' in the route as the destination of the IP datagram
in which it will place the datagram it has received to route. That machine
must know how to decapsulate IPIP datagrams, that is, it must also be
configured with a tunnel device.
It doesn't have to be a whole network you route. You could for example route
just a single IP address. In that instance you might configure the tunl
device on the `remote' machine with its home IP address and at the A end just
use a host route (and Proxy Arp) rather than a network route via the tunnel
device. Let's redraw and modify our configuration appropriately. Now we
have just host `B' which to want to act and behave as if it is both
fully connected to the Internet and also part of the remote network supported
by host `A':
192.168.1/24
-
| ppp0 = ppp0 =
| aaa.bbb.ccc.ddd fff.ggg.hhh.iii
|
| /-----\ /-----\
| | | // | |
|---| A |------//---------| B |
| | | // | |
| \-----/ \-----/
| also: 192.168.1.12
-
Linux router `A' would be configured with:
#!/bin/sh
PATH=/sbin:/usr/sbin
mask=255.255.255.0
remotegw=fff.ggg.hhh.iii
#
# Ethernet configuration
ifconfig eth0 192.168.1.1 netmask $mask up
route add -net 192.168.1.0 netmask $mask eth0
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.1.1 up
route add -host 192.168.1.12 gw $remotegw tunl0
#
# Proxy ARP for the remote host
arp -s 192.168.1.12 xx:xx:xx:xx:xx:xx pub
Linux host `B' would be configured with:
#!/bin/sh
PATH=/sbin:/usr/sbin
mask=255.255.255.0
remotegw=aaa.bbb.ccc.ddd
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.1.12 up
route add -net 192.168.1.0 netmask $mask gw $remotegwtunl0
This sort of configuration is more typical of a Mobile-IP application. Where a single host wants to roam around the Internet and maintain a single usable IP address the whole time. You should refer to the Mobile-IP section for more information on how that is handled in practice.
Many people have a simple dialup account to connect to the Internet. Nearly everybody using this sort of configuration is allocated a single IP address by the Internet Service Provider. This is normally enough to allow only one host full access to the network. IP Masquerade is a clever trick that enables you to have many machines make use of that one IP address, by causing the other hosts to look like, hence the term masquerade, the machine supporting the dialup connection. There is a small caveat and that is that the masquerade function nearly always works only in one direction, that is the masqueraded hosts can make calls out, but they cannot accept or receive network connections from remote hosts. This means that some network services do not work such as talk and others such as ftp must be configured to operate in passive (PASV) mode to operate. Fortunately the most common network services such as telnet, World Wide Web and irc do work just fine.
Kernel Compile Options:
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
Networking options --->
[*] Network firewalls
....
[*] TCP/IP networking
[*] IP: forwarding/gatewaying
....
[*] IP: masquerading (EXPERIMENTAL)
Normally you have your linux machine supporting a slip or PPP dialup line just as it would if it were a standalone machine. Additionally it would have another network device configured, perhaps an ethernet, configured with one of the reserved network addresses. The hosts to be masqueraded would be on this second network. Each of these hosts would have the IP address of the ethernet port of the linux machine set as their default gateway or router.
A typical configuration might look something like this:
- -
\ | 192.168.1.0
\ | /255.255.255.0
\ --------- |
| | Linux | .1.1 |
NET =================| masq |------|
| PPP/slip | router| | --------
/ --------- |--| host |
/ | | |
/ | --------
- -
The most relevant commands for this configuration are:
# Network route for ethernet
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# Default route to the rest of the internet.
route add default ppp0
#
# Cause all hosts on the 192.168.1/24 network to be masqueraded.
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
This is similar to using IPFWADM but the command structure has changed:
# Network route for ethernet
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# Default route to the rest of the internet.
route add default ppp0
#
# Cause all hosts on the 192.168.1/24 network to be masqueraded.
ipchains -A forward -s 192.168.1.0/24 -j MASQ
You can get more information on the Linux IP Masquerade feature from the IP Masquerade Resource Page. Also, a very detailed document about masquesrading is the ``IP-Masquerade mini-HOWTO'' (which also intructs to configure other OS's to run with a Linux masquerade server).
IP transparent proxy is a feature that enables you to redirect servers or services destined for another machine to those services on this machine. Typically this would be useful where you have a linux machine as a router and also provides a proxy server. You would redirect all connections destined for that service remotely to the local proxy server.
Kernel Compile Options:
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
Networking options --->
[*] Network firewalls
....
[*] TCP/IP networking
....
[*] IP: firewalling
....
[*] IP: transparent proxy support (EXPERIMENTAL)
Configuration of the transparent proxy feature is performed using the ipfwadm command
An example that might be useful is as follows:
root# ipfwadm -I -a accept -D 0/0 telnet -r 2323
This example will cause any connection attempts to port telnet
(23) on any host to be redirected to port 2323 on this host. If you
run a service on that port, you could forward telnet connections, log
them or do whatever fits your need.
A more interesting example is redirecting all http traffic
through a local cache. However, the protocol used by proxy servers is
different from native http: where a client connects to
www.server.com:80 and asks for /path/page, when it
connects to the local cache it contacts proxy.local.domain:8080
and asks for www.server.com/path/page.
To filter an http request through the local proxy, you need to
adapt the protocol by inserting a small server, called
transproxy (you can find it on the world wide web). You can choose
to run transproxy on port 8081, and issue this command:
root# ipfwadm -I -a accept -D 0/0 80 -r 8081
transproxy program, then, will receive all connections meant
to reach external servers and will pass them to the local proxy
after fixing protocol differences.
Just when you thought you were beginning to understand IP networking the rules get changed! IPv6 is the shorthand notation for version 6 of the Internet Protocol. IPv6 was developed primarily to overcome the concerns in the Internet community that there would soon be a shortage of IP addresses to allocate. IPv6 addresses are 16 bytes long (128 bits). IPv6 incorporates a number of other changes, mostly simplifications, that will make IPv6 networks more managable than IPv4 networks.
Linux already has a working, but not complete, IPv6 implementation in
the 2.2.* series kernels.
If you wish to experiment with this next generation Internet technology, or have a requirement for it, then you should read the IPv6-FAQ which is available from www.terra.net.
The term "IP mobility" describes the ability of a host that is able to move its network connection from one point on the Internet to another without changing its IP address or losing connectivity. Usually when an IP host changes its point of connectivity it must also change its IP address. IP Mobility overcomes this problem by allocating a fixed IP address to the mobile host and using IP encapsulation (tunneling) with automatic routing to ensure that datagrams destined for it are routed to the actual IP address it is currently using.
A project is underway to provide a complete set of IP mobility tools for Linux. The Status of the project and tools may be obtained from the: Linux Mobile IP Home Page.
IP Multicast allows an arbitrary number of IP hosts on disparate IP networks to have IP datagrams simultaneously routed to them. This mechanism is exploited to provide Internet wide "broadcast" material such as audio and video transmissions and other novel applications.
Kernel Compile Options:
Networking options --->
[*] TCP/IP networking
....
[*] IP: multicasting
A suite of tools and some minor network configuration is required. Please check the Multicast-HOWTO for more information on Multicast support in Linux.
The traffic shaper is a driver that creates new interface devices, those devices are traffic-limited in a user-defined way, they rely on physical network devices for actual transmission and can be used as outgoing routed for network traffic.
The shaper was introduced in Linux-2.1.15 and was backported to
Linux-2.0.36 (it appeared in 2.0.36-pre-patch-2 distributed by Alan
Cox, the author of the shaper device and maintainer of Linux-2.0).
The traffic shaper can only be compiled as a module and is configured by the shapecfg program with commands like the following:
shapecfg attach shaper0 eth1
shapecfg speed shaper0 64000
The shaper device can only control the bandwidth of outgoing traffic, as packets are transmitted via the shaper only according to the routing tables; therefore, a ``route by source address'' functionality could help in limiting the overall bandwidth of specific hosts using a Linux router.
Linux-2.2 already has support for such routing, if you need it for
Linux-2.0 please check the patch by Mike McLagan, at
ftp.invlogic.com. Refer to
Documentationnetworking/shaper.txt for further information about
the shaper.
If you want to try out a (tentative) shaping for incoming packets,
try out rshaper-1.01 (or newer), from
ftp.systemy.it.