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.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- Weechat, Irssi's Little Brother
- New Products
- Developer Poll
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?





1 hour 31 min ago
2 hours 17 min ago
2 hours 27 min ago
2 hours 32 min ago
4 hours 42 min ago
4 hours 43 min ago
5 hours 28 min ago
6 hours 17 min ago
6 hours 41 min ago
8 hours 17 min ago