Linux DevCenter    
 Published on Linux DevCenter (http://www.linuxdevcenter.com/)
 See this if you're having trouble printing code examples


Using Linux as a Small Business Internet Gateway, Part 2

by Alexander Prohorenko
12/18/2003

Installing and Configuring DNS

After installing and configuring a Linux Internet Gateway, as described in part one of this series, sometimes workstations inside of the network suffer strange lags while attempting to connect to network resources (printers, common access directories) on other workstations. This happens because in TCP/IP, remote computer names must be converted to and from IP addresses using DNS. Unfortunately, the DNS of your provider knows nothing about the names of computers inside of your network!

Your provider sends the request to other DNS servers. It takes some time. Of course, if the Internet connection isn't up at the moment, DNS isn't available at all. Things will be even worse if network addresses in use within your local network are used by other providers on the global Internet. (This is one good reason to use a non-routable address block.) In this case, you will see hard-to-trace defects and mistakes. For example, your network may stop working after connecting your gateway to the Internet.

We can solve this problem by installing a local DNS service. If we also configure it as caching server, we will be able to minimize our traffic a bit — solving one problem of any dial-up connection.

As before, we need a few packages from the distribution:

# rpm -ihv bind-9.2.1-16.i386.rpm caching-nameserver-7.2-7.noarch.rpm
Prepearing...            ########################################### [100%]
1:bind                   ########################################### [ 50%]
2:caching-nameserver     ########################################### [100%]

The main configuration files are located in two places: /etc/named.conf and database records in /var/named/. Everything is already configured to work as a caching server. We only need two little modifications.

In the options section of /etc/named.conf, add the line:

listen-on { 127.0.0.1; 192.168.0.1; };

This argument causes the server to accept only requests that come from the local interface (the server itself) or the internal network interface. For security reasons, it will not accept requests that come from the Internet.

As usual, the iptables configuration will need a little modification to allow DNS traffic to the gateway and through it to our provider's DNS servers. The new file looks like this:

# Simple firewall for internet gateway
*filter
:INPUT ACCEPT [0:0]

# Deny forward for security reasons
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:RH-FW-INPUT - [0:0]

# Redirect all input-forwarded packets to our special rule
-A INPUT -j RH-FW-INPUT

# Accept all packets for local interface (lo)
-A RH-FW-INPUT -i lo -j ACCEPT

# Define custom rules
# Access to mail services
-A RH-FW-INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 110 -i eth0 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 143 -i eth0 -j ACCEPT

# Access to DNS service
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 53 -i eth0 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p udp -m udp --dport 53 -i eth0 -j ACCEPT

# This part equal to some part from generated by Lokkit utility
-A RH-FW-INPUT -p tcp -m tcp --dport 143             -j ACCEPT
-A RH-FW-INPUT -p tcp -m tcp --dport 0:1023    --syn -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 2049      --syn -j REJECT
-A RH-FW-INPUT -p udp -m udp --dport 0:1023          -j REJECT
-A RH-FW-INPUT -p udp -m udp --dport 2049            -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 6000:6009 --syn -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 7100      --syn -j REJECT

# Allow access to external mail/news/DNS
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 25  -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 110 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 143 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 119 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 53  -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p udp -m udp --dport 53  -j ACCEPT
COMMIT

# Enable masquarading
*nat
:PREROUTING  ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT      ACCEPT [0:0]
-A POSTROUTING -p tcp -s 192.168.0.0/24 -o ppp0 -j SNAT
    --to-source 123.123.123.123
-A POSTROUTING -p udp -s 192.168.0.0/24 -o ppp0 -j SNAT
    --to-source 123.123.123.123
COMMIT

Don't forget to reload iptables:

# service iptables restart

Unfortunately, caching DNS server mode alone isn't enough, because the problem of converting names into IP addresses isn't solved. We'll need to configure the service to support the internal network. As explained in part one of this series, the internal network is 192.168.0.0/255.255.255.0. The gateway address is 192.168.0.1, with a machine name of gateway. The domain name is ourcompany.com. Finally, there are two PCs on the network, named buh and dir, with addresses of 192.168.0.11 and 192.168.0.12, respectively.

We need a few more modifications to configure DNS. First, in /etc/named.conf, describe two zones for direct and reverse conversion:

zone "ourcompany.com" IN {
    type master;
    file "ourcompany.com.zone";
    allow-update {
		none;
	};
    allow-query  {
        192.168.0.0/24;
    };
};
            
zone "0.168.192.in-addr.arpa" IN {
    type master;
    file "named.192.168.0";
    allow-update {
		none;
	};
    allow-query  {
        192.168.0.0/24;
    };
};

The argument type master means that our server is the primary, not secondary, server for this zone. The file argument defines the file name that contains names and addresses for this zone. The allow-update { none; } argument denies base updates from foreign DNS servers. The allow-query { 192.168.0.0/24; } argument allows requests only from our local net clients.

You may find it strange to record zone names for converting addresses to names. The format (0.168.192.in-addr.arpa) comes from the time of a little ARPA network, before the Internet. You just need to remember the syntax.

Next, we will create bases. If there is no full pathname specified, the base directory will be /var/named. This path is defined when the server is compiled and may vary for different Linux distributions. Here's /var/named/ourcompany.com.zone:

$TTL    86400
$ORIGIN ourcompany.com.
@       1D IN SOA       @ root (
            2002092501      ; serial
            3H              ; refresh
            15M             ; retry
            1W              ; expiry
            1D )            ; minimum
                                                                                                    
            1D IN NS        192.168.0.1
            1D IN A         192.168.0.1

gateway     1D IN A         192.168.0.1
buh         1D IN A         192.168.0.11
dir         1D IN A         192.168.0.12

I will not get into details about the file format, describing only the information needed to control services in our little company.

O'Reilly Open Source Convention.

In /var/named/named.192.168.0:

$TTL    86400
@     IN    SOA    ourcompany.com. root.ourcompany.com.  (
                   2002092501 ; Serial
                   28800      ; Refresh
                   14400      ; Retry
                   3600000    ; Expire
                   86400 )    ; Minimum

      IN    NS     192.168.0.1
                                                                                
1     IN    PTR    gateway.ourcompany.com.
11    IN    PTR    buh.ourcompany.com.
12    IN    PTR    dir.ourcompany.com.

This database defines the conversions from addresses to names. Its format resembles that of the previous database, with some differences, such as a "new" SOA record type and PTR. It also uses only the last portion of IP addresses within the network.

Pay attention to the final dots. If you miss them, the server will automatically add a domain name to your symbol name (ourcompany.com or 0.168.192.-in-addr.arpa). If the dot is in place, the name will be accepted as is.

It's time to run our server:

# service named start
Starting named:                           [  OK  ]

After startup, please explore the log file /var/messages. You'll find detailed reports there in case of any bugs or errors with your DNS configuration.

Now, let's check how our server works:

$ nslookup -sil
> gateway.ourcompany.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   gateway.ourcompany.com
Address: 192.168.0.1
> 192.168.0.1
Server:         127.0.0.1
Address:        127.0.0.1#53

1.0.168.192.in-addr.arpa        name = gateway.ourcompany.com.
> 192.168.0.11
Server:         127.0.0.1
Address:        127.0.0.1#53

11.0.168.192.in-addr.arpa       name = buh.ourcompany.com.
>exit
$

Everything is all right, your server is functioning. If you need to make changes to DNS, you can do it easily any time you like, by modifying database files. Do not forget to update the serial number. The command:

# service named reload

will reload all databases and the server will be able to continue.

Monitoring Systems

To tell the truth, running a web server on the gateway is not necessary. Everything will be fine without it. Nevertheless, many modern monitoring systems use a web server to visualize their reports. This is why we'll install one. However, we shouldn't forget to deny web access from the external network.

Almost every Linux distribution includes the Apache web server, a very powerful, multi-function server. For our purpose (monitoring) we do not need all of its power, but, because of its popularity and modest resource needs, we'll install it.

Installing the minimal number of packages produces:

# rpm -ihv httpd-2.0.40-21.i386.rpm httpd-manual-2.0.40-21.i386.rpm
Preparing...             ########################################### [100%]
1:httpd                  ########################################### [ 50%]
2:httpd-manual           ########################################### [100%]

Please note that the latest version of Apache 2 at the time of writing is 2.0.48, with some critical bug fixes. Don't forget to upgrade!

Apache's main configuration file is /etc/httpd/conf/httpd.conf. This file includes many different arguments. We'll need to modify a few before running our server. Later, while describing the monitoring system, we'll need to modify a few more.

You need to change only few arguments:

You may not believe it, but that's all for now. As usual, we need to slightly restrict the iptables rules.

# Simple firewall for internet gateway
*filter
:INPUT ACCEPT [0:0]

# Deny forward for security reasons
:FORWARD DROP [0:0]
:OUTPUT  ACCEPT [0:0]
:RH-FW-INPUT - [0:0]

# Redirect all input-forwarded packets to our special rule
-A INPUT -j RH-FW-INPUT

# Accept all packets for local interface (lo)
-A RH-FW-INPUT -i lo -j ACCEPT

# Define custom rules
# Access to mail services
-A RH-FW-INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 110 -i eth0 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 143 -i eth0 -j ACCEPT

# Access to DNS service
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 53 -i eth0 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p udp -m udp --dport 53 -i eth0 -j ACCEPT

# Access to HTTP service
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 80 -i eth0 -j ACCEPT

# This part equal to some part from generated by Lokkit utility
-A RH-FW-INPUT -p tcp -m tcp --dport 143             -j ACCEPT
-A RH-FW-INPUT -p tcp -m tcp --dport 0:1023    --syn -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 2049      --syn -j REJECT
-A RH-FW-INPUT -p udp -m udp --dport 0:1023          -j REJECT
-A RH-FW-INPUT -p udp -m udp --dport 2049            -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 6000:6009 --syn -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 7100      --syn -j REJECT

# Allow access to external mail/news/DNS
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 25  -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 110 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 143 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 119 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 53  -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p udp -m udp --dport 53  -j ACCEPT
COMMIT

# Enable masquarading
*nat
:PREROUTING  ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT      ACCEPT [0:0]
-A POSTROUTING -p tcp -s 192.168.0.0/24 -o ppp0 -j SNAT
    --to-source 123.123.123.123
-A POSTROUTING -p udp -s 192.168.0.0/24 -o ppp0 -j SNAT
    --to-source 123.123.123.123
COMMIT

Do not forget to reload iptables!

# service iptables restart

At last, we can start the httpd service:

# service httpd start
Starting httpd:                         [  OK  ]

Let's check it now. In any web browser, try to open the page http://gateway.ourcompany.com/. If everything is all right, you will see Apache's introduction page. To change it to something else, you will need to put other pages into /var/www/html. The default CGI directory is /var/www/cgi-bin. Again, this will change, based on distribution and configuration options.

Monitoring Proxy Activity

There are two ways to monitor and control our proxy. The first is by analyzing our log files. This allows us to produce reports about the number of hits of any Internet resource over time. This data can be useful for system administrators and managers. This also allows administrators to control which sites users can visit during work hours.

The second approach is to monitor and to control all current open connections. This can be helpful to figure out why things are slow at times.

The sarg package fits the first approach. It generates readable and suitable reports and is easy to configure. However, it's not included in our distribution, so we will have to download it ourselves. I recommend sarg-1.1.1 (RPM linking by Sergei Dushenkov), because in 1.2.1 and 1.2.2 I found a bug — on some systems, only the daily report works properly.

Let's begin with installation:

# rpm -ihv sarg-1.1.1-2.i386.rpm 
Preparing...             ########################################### [100%]
1:sarg                   ########################################### [100%]

Configuration files live in /etc/sarg. You will also find there examples of commands to add to /etc/crontab to run recurring reports. Executable files are in /usr/sbin. Reports will be written into subdirectories under /var/www/html/squid daily, weekly, and monthly.

Related Reading

Linux Network Administrator's Guide
By Olaf Kirch, Terry Dawson

Let's now configure sarg. We need to edit the file /etc/sarg/sarg.conf. All necessary commands are described below.

You also need to delete the file /etc/logrotate.d/squid or comment out all of its lines. Log file rotation will happen monthly with the help of the sarg.monthly script. It can't happen more often, or the monthly reports will not work.

To crown it all, let's configure the report generator to run automatically. This takes the following command:

# crontab -u squid /etc/sarg/sarg.cron

If you look at sarg.cron, you can see that sarg.monthly will run weekly. That's not a mistake; everything is okay.

Now we must configure proxy monitoring. Squid includes the cachemgr.cgi utility to provide a lot of information about the proxy's state. Copy this file into /var/www/cgi-bin directory. Now, browsing to http://192.168.0.1/cgi-bin/cachemgr.cgi will prompt for authorization to view the proxy manager interface. By default, there's no password. We just need to check the hostname and port number of the proxy. To set a password or otherwise restrict access, see the cachemgr_password option in squid's configuration file.

After authorization, you'll see the proxy manager interface. It provides a lot of data, but for beginners, the only interesting data is in the Client-side Active Requests section. Choose it. You will see a list of current client connections, including client IP addresses, requested URLs, times of connection, and the sizes of transferred information.

It's a pity, but the current form of this information is unsuitable for analysis. (Of course, you can try, but it's a question of habits and time). That's why other programs exist to convert this data into more useful views. SquidMon is one example. This program is for Microsoft Windows; nevertheless, it works fine under Wine. The author's site describes how to configure this application.

Monitoring Traffic Balance

Monitoring traffic balance is really only two tasks: taking care of speed of loading of our channel and counting all traffic for a period of time. For the first task we can use mrtg, conveniently included in the distribution.

Before installation, you'll also have to install SNMP support.

# rpm -ihv net-snmp-5.0.6-17.i386.rpm  mrtg-2.9.17-13.i386.rpm
Preparing...            ########################################### [100%]
1:net-snmp               ########################################### [ 50%]
3:mrtg                   ########################################### [100%]

Let's first configure snmp. We need to modify file /etc/snmp/snmpd.conf. Add the following lines to the Access Control section:

# Minimal setup for MRTG at localhost:
com2sec local 127.0.0.1 system
group ROView v1  local
group ROView v2c local
view  roview     included .1.3.6.1.2.1
access ROView    ""      any       noauth    exact      roview none   none

Then start snmp:

# service snmpd start
Starting snmpd:                                         [  OK  ]

We can now check how snmp works:

$ snmpwalk localhost public

If everything is all right, the results will be something like this:

system.sysDescr.0 = Linux localhost.localdomain 2.4.20-8asp #1
    Thu Mar 13 20:16:12 EEST 2002 i686
system.sysObjectID.0 = OID: enterprises.ucdavis.ucdSnmpAgent.linux
system.sysUpTime.0 = Timeticks: (10408) 0:01:44.08
system.sysContact.0 = Root <root@localhost>
    (configure /etc/snmp/snmp.local.conf)
system.sysName.0 = localhost.localdomain
system.sysLocation.0 = Unknown (edit /etc/snmp/snmpd.conf)
system.sysORLastChange.0 = Timeticks: (30) 0:00:00.30
system.sysORTable.sysOREntry.sysORID.1 = OID: ifMIB

Now we need to configure mrtg. Its package includes a utility to create configuration files. Connect to the Internet and issue the next command:

# cfgmaker --global 'WorkDir: /var/www/html/mrtg' \
    --global 'Options[_]: growright, unknaszero, bits' \
    --global 'Language: russian' \
    --global 'AddHead[_]: <META http-equiv="Content-Type"
        content="text/html; charset=koi8-r">' \
    --output '/etc/mrtg/mrtg.cfg' \
    system@localhost

This creates the /etc/mrtg/mrtg.cfg file. We need to change it a bit, because the speed of the PPP interface (ppp0, ppp1, etc.) cannot be correctly determined. The generator just comments out these lines. We need to uncomment the PPP section to set the maximal speed (argument MaxBytes) correctly. As a result, we should get something like:

### Interface 2 >>: 'ppp0' | Name: '' | Ip: '123.4.5.6' | Eth: '' ###
### The following interface is commented out because:
### * has a speed of 0 which makes no sense
#
 Target[localhost_2]: 2:system@localhost:
 SetEnv[localhost_2]: MRTG_INT_IP="123.4.5.6" MRTG_INT_DESCR="ppp0"
 MaxBytes[localhost_2]: 115200
 Title[localhost_2]: Traffic Analysis for dialup -- localhost.localdomain
 PageTop[localhost_2]: <H1>Traffic Analysis for dialup -- localhost.localdomain</H1>
  <TABLE>
    <TR><TD>System:</TD>     <TD>localhost.localdomain in Unknown </TD></TR>
    <TR><TD>Maintainer:</TD> <TD>Root <root@localhost></TD></TR>
    <TR><TD>Description:</TD><TD>ppp0  </TD></TR>
    <TR><TD>ifType:</TD>     <TD>ppp (23)</TD></TR>
    <TR><TD>ifName:</TD>     <TD></TD></TR>
    <TR><TD>Max Speed:</TD>  <TD>115.2 KBytes/s</TD></TR>
    <TR><TD>Ip:</TD>         <TD>123.4.5.6 (123.dialup.provider.net)</TD></TR>
  </TABLE>

Everything is almost ready for the first start. First, move the contents of /var/www/html/mrtg into /usr/share/doc/mrtg-2.9.17/doc. This is the documentation, for some reason placed into a web directory.

Let's start mrtg manually:

# /usr/bin/mrtg /etc/mrtg/mrtg.cfg
Rateup WARNING: /usr/bin/rateup could not read the primary log file
    for localhost_2
Rateup WARNING: /usr/bin/rateup The backup log file for localhost_2 was invalid 
    as well
Rateup WARNING: /usr/bin/rateup Can't remove localhost_2.old updating log file
Rateup WARNING: /usr/bin/rateup Can't rename localhost_2.log to localhost_2.old 
    updating log file
# /usr/bin/mrtg /etc/mrtg/mrtg.cfg
Rateup WARNING: /usr/bin/rateup Can't remove localhost_2.old updating log file

All error messages during the first two starts are normal — all data files and backup files must be created. You will not get these errors again. Reports will be generated in the /var/www/html/mrtg directory, with a separate file for each interface, following the pattern localhost_<interface_number>.html. During analysis, you can easily create a page of cumulative information about all interfaces. You can also turn on automatic report updating. In /etc/cron.d/mrtg, uncomment the line:

0-59/5 * * * * root /usr/bin/mrtg /etc/mrtg/mrtg.cfg

and append the path where we will keep the log:

--logging /var/log/mrtg.log

Truthfully, you can even skip this step. If so, any errors will just be emailed to the administrator.

Now it's time to solve the traffic counting problem. Honestly, I was unable to find any easy-to-configure package that could count all of the things I wanted to count. For example, my provider counts my incoming traffic from foreign resources, but traffic from the provider's resources shouldn't be counted.

As I discovered, there is no such problem. Everything can be easily solved using just iptables and little calculation utility. In theory, iptables can count traffic; we just need to create rules for counting. Pay close attention to the rule changes here:

# Simple firewall for internet gateway
*filter
:INPUT ACCEPT [0:0]

# Deny forward for security reasons
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:RH-FW-INPUT - [0:0]
:trafin   - [0:0]
:trafout  - [0:0]
:trinloc  - [0:0]
:troutloc - [0:0]

# special counter rules
-A trafin   -j RETURN
-A trafout  -j RETURN
-A trinloc  -j RETURN
-A troutloc -j RETURN

# Redirect all input packets to our special rule
-A INPUT                  -i ppp0 -j trafin
-A OUTPUT                 -o ppp0 -j trafout
-A INPUT  -s 123.4.0.0/16 -i ppp0 -j trinloc
-A OUTPUT -d 123.4.0.0/16 -o ppp0 -j troutloc
-A INPUT                          -j RH-FW-INPUT

# Accept all packets for local interface (lo)
-A RH-FW-INPUT -i lo -j ACCEPT

# Define custom rules
# Access to mail services
-A RH-FW-INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 110 -i eth0 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 143 -i eth0 -j ACCEPT

# Access to DNS service
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 53 -i eth0 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p udp -m udp --dport 53 -i eth0 -j ACCEPT

# Access to HTTP service
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 80 -i eth0 -j ACCEPT

# This part equal to some part from generated by Lokkit utility
-A RH-FW-INPUT -p tcp -m tcp --dport 143             -j ACCEPT
-A RH-FW-INPUT -p tcp -m tcp --dport 0:1023    --syn -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 2049      --syn -j REJECT
-A RH-FW-INPUT -p udp -m udp --dport 0:1023          -j REJECT
-A RH-FW-INPUT -p udp -m udp --dport 2049            -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 6000:6009 --syn -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 7100      --syn -j REJECT

# Allow access to external mail/news/DNS
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 25  -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 110 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 143 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 119 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 53  -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p udp -m udp --dport 53  -j ACCEPT
COMMIT

# Enable masquarading
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -p tcp -s 192.168.0.0/24 -o ppp0 -j SNAT
	--to-source 123.123.123.123
-A POSTROUTING -p udp -s 192.168.0.0/24 -o ppp0 -j SNAT
	--to-source 123.123.123.123
COMMIT

Now, after reloading iptables, you can easily see all traffic size:

# iptables -L trafin -vxn
Chain trafin (1 references)
pkts      bytes target     prot opt in     out     source               destination
44     3008 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

# iptables -L trafout -vxn
Chain trafout (1 references)
pkts      bytes target     prot opt in     out     source               destination
44     5008 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

and for local traffic:

# ipchains -L trinloc
Chain trinloc (1 references)
pkts      bytes target     prot opt in     out     source               destination
0        0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

# iptables -L troutloc -vxn
Chain troutloc (1 references)
pkts      bytes target     prot opt in     out     source               destination
0        0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Please note that when you reload iptables, all counters will reset. Besides, it's useful to see daily, weekly, and monthly traffic balances in a good visible presentation.

That's the purpose of the attached iptrafcount.pl program. This program accumulates data in /var/log. You can receive a short help message by running it with the -h argument. To use it, you should also do the following:

That's all. Soon, you will be able to check reports (for example, for March 2003):

# iptrafcount.pl -w common -d 03/2003

The program outputs HTML. You can easily include it in your custom CGI script.

Conclusion

The two parts of this article have explained how to use Linux as an Internet gateway server. Having installed several similar installations, I'm confident that Linux does its job perfectly well. Furthermore, in many cases, I personally economize my time and the time of my clients by working from home without having to come into the office.

Over time, any organization or company interested in diving more deeply into the Internet can easily expand its gateway into a fully functioning web or DNS server.

Alexander Prohorenko is a certified professional, who holds Sun Certified System Administrator and Sun Certified Java Programmer certifications.


Return to the LinuxDevCenter.com.

Copyright © 2009 O'Reilly Media, Inc.