IP Masquerading Code Follow-up
Over a year ago this magazine graciously allowed me to write a couple of articles for them. One of them concerned the topic of IP Masquerading (July 1996, Issue 27) as supported by the Linux kernel. Since that time a number of changes have occurred during the ongoing development of Linux. I'd like to bring the Linux Journal readers up to date on what changes have taken place, explain a few of the technical details and take some guesses at where things are going in the future. Many of the technical details of functionality will not be revisited because overall the functionality hasn't changed. The previous article still applies in that area.
IP Masquerading is a way of performing address hiding. It may be that a company does not have enough registered IP addresses to connect all of its computers to the Internet or, if you're like me, you have one address through a local dial-up account, but three computers. Each of these circumstances can be solved by using masquerading to allow the “internal” computers access via the one external connection point. The external connection point will use masquerading to hide addresses. Figure 1 is a diagram of the local network I have as my setup.
Using masquerading is still as easy as ever. I have one network where I want all of my hosts to have access to the Internet. Since they are on 192.168.1.0 (the network), I can masquerade the entire class C address space. You'll notice, being the good administrator that I am, I'm using a private address as defined by RFC 1918.
To start masquerading, I defined an rc.masq file in my /etc/rc.d/ directory and added it to execute in /etc/rc.d/rc.local. The rc.masq file looks like this:
#!/bin/sh # PATH=/usr/local/bin; export PATH
# # setup system forwarding policy ipfwadm -F -p deny # # masquerading rules ipfwadm -F a m -S 192.168.1.0/24 -D 0.0.0.0/0 # # list out the current ruleset ipfwadm -F -l -n,
First, you'll notice the command to set up masquerading is the ipfwadm (version 2.3.0) command. This is noticeably different from the previous article when only the ipfw command could be used. Since kernels 1.3.66 ipfwadm is the only command to manipulate masquerading rules and is available from http://www.xos.nl/linux/ipfwadm/.
There are really just two statements given. The first one:
ipfwadm -F -p deny
defines the forwarding policy (-F) of this machine—deathstar from Figure 1. It sets the policy to deny all packets to be forwarded by deathstar. Forwarding is the situation where a packet has a source address and destination address different from any of deathstar's interfaces and is to be routed through.
The second statement:
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
added a masquerading rule for the source (-S) network 192.168.1.0. We can tell it is for the entire network by the 24-bit netmask associated with it. 24 bits equates to 255.255.255.0 to indicate the network versus the host portion of an IP address. The destination (-D) address is the all encompassing 0.0.0.0 network, which is used to identify any network. That's it.
The last command allows me to look at the rules set for deathstar. The output looks like this:
IP firewall forward rules, default policy: deny type prot source destination ports acc/m all 192.168.1.0/24 0.0.0.0/0 n/a
Briefly, the output indicates that it will masquerade for all protocols from source 192.168.1.* to anywhere for all source and destination ports.
The ipfwadm program is primarily used to set the rules for the firewalling code in the Linux 2.x kernels.
Masquerading takes a small amount of effort to get configured. Before kernel 2.0.30 the masquerading code was still considered experimental. As such, many pieces of the code were not included with the full distribution, but only included as patches. If you are running a 2.0.x kernel where is x is 29 or lower, see the “Code Maturity Level” sidebar for patching the kernel to include masquerading. My kernel is set up running version 2.0.30 with masquerading included. The configuration options related to masquerading are shown in Listing 1.
You'll notice that parts of the masquerading code can only be included as kernel modules. These are for specific protocols or applications; examples include FTP, VDOLive and Real Audio.
Currently, IP Masquerading has support for TCP and UDP, FTP, Real Audio, IRC, ICMP (configuration option), VDOLive, CUSeeMe and Quake. Normal TCP and UDP applications like TELNET or DNS are supported directly in the kernel masquerading code. The abnormal (i.e. pathological) protocols such as FTP and IRC (which have IP addresses as a part of the message stream) and Real Audio (because the control protocol needs to know where you are) are supported via kernel modules. VDOLive, CUSeeME and Quake are also kernel modules.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Interview with Patrick Volkerding
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server