File: lg_answer27.html

package info (click to toggle)
lg-issue27 2-1
links: PTS
area: main
in suites: hamm
size: 2,924 kB
ctags: 132
sloc: sh: 35; makefile: 30
file content (934 lines) | stat: -rw-r--r-- 39,378 bytes
parent folder | download | duplicates (2)
<!--startcut =======================================================  -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>The Answer Guy Issue 27</title>
</head>

<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#A000A0"
ALINK="#FF0000">
<!--endcut =========================================================  -->
<H4>"Linux Gazette...<I>making Linux just a little more fun!</I>"
</H4>
<P> <hr> <P>

<!-- ===============================================================  -->
<center>
<H1><A NAME="answer">
<img src="../gx/ans.gif" alt="" border=0 align=middle>
The Answer Guy
<img src="../gx/ans.gif" alt="" border=0 align=middle>
</A></H1> <BR>
<H4>By James T. Dennis,
<a href="mailto:answerguy@ssc.com">answerguy@ssc.com</a><BR>
Starshine Technical Services, <A HREF="http://www.starshine.org/">
http://www.starshine.org/</A> </H4>
</center>

<p><hr><p>
<H3>Contents:</H3>
<ul>
<li><a HREF="./lg_answer27.html#mccluan">Regarding Compile Errors with
Tripwire 1.2</a>
<li><a HREF="./lg_answer27.html#karsh">Applix Spreadsheet ELF Macro
Language</a>
<li><a HREF="./lg_answer27.html#geene">Answer Guy Issue 18 -- Procmail Spam
Filter</a>
<li><a HREF="./lg_answer27.html#geene2">Great Procmail Article</a>
<li><a HREF="./lg_answer27.html#sindona">Linux Cluster Configuration</a>
<li><a HREF="./lg_answer27.html#holloway">IP Masquerading/Proxy?</a>
</ul>

<p><hr><p>
<!--================================================================-->

<a name="mccluan"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Regarding Compile Errors with Tripwire 1.2
</h3>
<P> <B>
From: Tc McCluan, <A HREF="mailto:tc@4dcomm.com">tc@4dcomm.com</A>
</B> <P><B> 
<img align=bottom alt=" " src="../gx/ans2.gif">
I was on http://www.starshine.org/linux/ and since I am unable to
compile Tripwire 1.2 on my system (redhat 4.2 with 2.0.33 kernel)
I am trying all avenues of help.
</B> <P><B> 
I have tried the recommendation in the /contrib/README.linux but
I still get the same error message.  I have tried many combinations,
but still no luck.
</B> <P><B> 
Following are the list of errors I am getting, hopefully you can spot where
this compile is failing.
Thanks in advance,
</B> <P>
<img align=bottom alt=" " src="../gx/ans2.gif">
 You could look for my Tripwire patch at
<P>
	http://www.starshine.org/linux/
<P>
 ... or you could grab the RPM file from any Red Hat "contrib"
 mirror like:
<P>
	ftp://ftp.redhat.com/pub/contrib/i386/tripwire-1.2-1.i386.rpm
<P>
 ... for a precompiled binary or:
<P>
	 ftp://ftp.redhat.com/pub/contrib/SRPMS/tripwire-1.2-1.src.rpm
<P>
 ... for sources that you should be able to build cleanly.
<P>
 So far I really haven't found a tripwire configuration that I really
 like.  I can never quite get the balance between what aspects to ignore
 (permission and ownership changes on /dev/tty*, /dev/pty*, etc) and
 which ones I need to watch.
<P>
 So, if anyone out there as a really good tw.config file that really
 minimizes the superfluous alerts and maximized the intrustion detection,
 I'd like to hear about it.
<P>
 Also if anyone has a YARD or other rescue disk builder that is customized
 for creating write-protected tripwire boot/root diskette sets (for
 periodic integrity auditing of Linux systems) I'd like to see a step-by-step
 Mini-HOWTO or tutorial (maybe as a submission to Linux Gazette).
<P>
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="karsh"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Applix Spreadsheet ELF Macro Language
</h3>
<P> <B> 
From: Paul T. Karsh ITTC-237B 8-286-xxxx, <A
HREF="mailto:karchpte@acm.org">karchpte@acm.org</A>
</B> <P><B>  
I happened on the Linux Gazette in the process of searching
for some information on "scripting" macros in the Applixware
spreadsheet.  Although this is not strictly a Linux question,
I hope you can help me with some "pointers" (links ?) on how to learn
this language.  The Applixware help is no help and the company
at which I consult does not have the on-line Applixware books nor
the hardcopy "macro" manual.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	I played with Applixware a little bit -- but was highly
	discouraged to find that its file conversion package
	couldn't handle more recent versions of MS Word and Excel.
	That was my main interest in the product since I occasionally
	get file attachments in these proprietary formats -- and
	sometimes they are potential customers.
<P>
	As for the issue of learning this Macro language without
	having the appropriate documentation.  I would ask your
	client where their manuals and/or installation CD is --
	if they can't produce it and are unwilling to order a
	replacement then I would question their decision to use
	the product.
<P>
	Applixware is a commercial product.  Assuming this is
	on a Linux system you'd probably want to contact Red Hat
	Corporation to order replacement manuals (I think RH is
	the sole Linux distributor for Applixware -- just as
	Caldera is the sole distributor for the Linux version
	of WordPerfect).
<P>
	If they have the installation CD -- borrow it and install
	its online documentation on some system somewhere (long
	enough to get the information your need).  Be sure to remove
	that installation unless the appropriate licensing arrangements
	are made, of course.
<P> <B> 
<img align=bottom alt=" " src="../gx/ques.gif">
Is there somewhere on the net (FTP or anything) where I can get an intro
to this?  I tried the Applixware site; it just seems to be page after
page of PR.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	I would like to see far more technical content on their
	web site as well.  (The same desire applies to other hardware
	and software company sites).
<P>
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="geene"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Answer Guy Issue 18 -- Procmail Spam Filter
</h3>
<P> <B> 
From: Anthony E. Geene, <A HREF="mailto:agreene@pobox.com">
agreene@pobox.com</A>
</B> <P><B>  
I'm not a procmail user, but I've found that most spam is sent using
envelope addresses, the standard recipient headers are not addressed to
the actual recipient. So I set up filters to catch my mailing list mail
and any mail that is addressed to a list of my vailid addresses. Other
mail is put elsewhere for later review.
</B> <P><B>  
Such a method is relatively simple and would catch all but the
more sophisticated spammers.
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	It is a good suggestion.  It doesn't work if you have
	some people that prefer to Bcc: you (use "blind carbon
	copies").  Naturally many people's mail user agents
	(MUA's) like elm, pine, etc don't have obvious options for
	Bcc:'s --  others do (and most Unix/Linux MUA's allow
	some way to do it -- even if it isn't *obvious*).
<P>
	There are probably a number of other "false positive"
	situations.  As you say most automated mailing lists
	have headers that would trigger on your criteria.  The
	obvious response to these problems is to make a list of
	all the exceptional cases (of which you are aware) and
	add appropriate rules to precede your anti-spam filter.
<P>
	In addition it is important to ensure that your disposition
	of apparently bogus messages is a refile to a specific
	mail folder.  You don't want to file it to /dev/null!
<P>
	As you check your "probably junk" folder you can manually
	refile the exceptions -- and optionally add new rules to
	"pre-approve" lists of your favorite correspondents.
<P>
	Note:  if you keep a list of correspondents and a list of
	known spammers, and you write a recipe to check the list
	you may be concerned about the amount of time spent in
	'grep'.  Here's a hint:  keep the list sorted and use the
	'look' command.
<P>
	(The advantage of 'look' is that it does a "binary" search
	(think about successive approximation to "zero in on" the
	desired lines) on a sorted file -- and returns the lines
	that match.  While the overhead of 'grep' grows in a linear
	fashion (the search doubles in time as the file doubles
	in size) that of 'look' grows much more slowly (it's
	proportional to the square root of number of records/lines
	in the file).  Similar results would be attained if one
	used 'dbm' hashes (indexes) -- but there is greater overhead
	in programming (Perl offers modules to support dbm, gdbm,
	ndbm and other hashing libraries -- it also has much higher
	load time overhead as a result of it's generality).
<P>
	The point is that even on a small file (100 lines) I
	can see about a 10% difference in overhead.  After a
	few thousand lines the difference is substantial
	(grep takes twice as long to run).
<P>
	None of this matters much on your personal workstation
	which has only one active user and receives a couple
	hundred e-mail items per day.  However -- if you're
	filtering on the company mailhub, or at your ISP's
	location -- it's worth it to reduce your impact.
<P>
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="geene2"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Great Procmail Article!
</h3>
<P> <B> 
From: Anthony E. Geene, <A HREF="mailto:agreene@pobox.com">
agreene@pobox.com</A>
</B> <P><B>  
I read your procmail article in issue 14 of the Linux Gazette. It was
the best explanation of how procmail works that I've seen yet.
</B> <P><B>  
I just wanted to say Thanks,<BR> 
Anthony,
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	Thanks for the feedback.  BTW there is a new article on
	use TDG (The Dotfile Generator) as a GUI front end for
	creating procmail scripts.  I haven't finished reading
	it yet -- but it looks pretty good to me.
<P>
	In your earlier mail you mentioned that you aren't using
	procmail yet.  This article on TDG and my explanation of
	what's going on "under the hood" may yet change that.
	(Also, somewhere on that morass of half-baked pages that
	I keep as a "website" are some links to other procmail
	and mail filtering resources).
<P>
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="sindona"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
Linux Cluster configuration
</h3>
<P> <B> 
From: Antonio Sindona, <A HREF="mailto:Antonio.Sindona@trinacria.it">
Antonio.Sindona@trinacria.it</A> 
</B> <P><B>  
I'd like to create a *Linux cluster configuration* to have some degree of
fault-tolerance (Linux normally works ... hardware not always ! ;-)  ). Do
You know if somebody tried to develop something to solve this problem ?
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
 The first place I'd look for info on fault tolerance for
 Linux would be:
	Linux High Availability HOWTO<BR> 
        http://sunsite.unc.edu/pub/Linux/ALPHA/linux-ha/High-Availability-HOWTO.html
<P>
Then take a look at:
<P>
	Linux Parallel Processing HOWTO<BR> 
        http://yara.ecn.purdue.edu/~pplinux/pphowto.html
<P>
... and:
<P>
	MP and Clustering for Linux<BR> 
	http://linas.org/linux/mp.html
<P>
 One of the most famous Linux parallel computing projects (which has
 been written up in the _Linux_Journal_ among other places) is the
 Beowulf Project:
<P>
	http://sdcd.gsfc.nasa.gov/ESS/linux.html
<P>
 After you've been overwhelmed by reading all of that you can
 slog through all of the links at:
<P>
	Linux Parallel Processing Using Clusters<BR> 
        http://yara.ecn.purdue.edu/~pplinux/ppcluster.html
<P>
 .... which include links to some classic Unix projects like
 "Condor," PVM, and MPI.
<P>
 After reading all of those you'll undoubtedly decide that Linux
 is years ahead of Microsoft in the field of clustering.  (MS'
 "wolfpack" project is still vaporware last I heard).  However,
 lest we grow complacent we should consider some features that Linux
 needs to compete with mainframe and mini clustering technologies
 (like those in VMS, and the ones that HP managed to eke out of
 their aquisition of Apollo -- when they gutted DomainOS, from what
 I hear).
<P>
 The two features Linux needs in order to attain the next level
 of clustering capacity are "transparent checkpointing" and
 "process migration."
<P>
 "Transparent checkpointing" allows the kernel to periodically
 take a comprehensive snapshot of a process' state (to disk or
 to some network filesystem) and allows the OS to restart a
 process "where it left off" in the event of a system failure.
<P>
 (System failures that damage the checkpoint files notwithstanding,
 of course).
<P>
 "Process Migration" allows a node's kernel to push a process
 onto another (presumably less heavily loaded) system.  The process
 continues to run on the new system without any knowlege of the
 transition.
<P>
 At first it seems like "checkpointing" would cost way too much
 in performance.  However, it turns out that relatively little
 of your system's RAM has been modified from the disk images
 (binaries and libraries) in any given time frame.  I've heard
 reliable reports that this has almost trivial overhead on a
 Unix/Linux like system. 
<P>
 It's easy to see how "checkpointing" is a necessary feature
 to support process migration.  However, it's not enough.  You
 also need mechanisms to allow the target kernel to give the
 incoming process access to all of the resources that it had
 allocated (open file descriptors, other interprocess channels,
 etc).  For Unix like systems you also have to account for
 the process structure (the PID of the process can't change)
 -- and there has to be some implicit inter-node communications
 to maintain the process groups (to get a process' exit
 status to its parent and to allow members of a process group
 to get status and send signals to it.
<P>
 There have been a number of operating systems that have implemented
 checkpointing and process migration features.  Chorus Mi/X, Berkeley
 Sprite and Amoeba (a project that the father of Minix, Andrew S.
 Tanenbaum, collaborated on) come to mind. 
<blockquote> 
	(see http://www.am.cs.vu.nl/ for info on Amoeba,
         http://HTTP.CS.Berkeley.EDU/projects/sprite/ for
	 Sprite, and http://www.chorus.com for Chorus Mi/X
	 info).
</blockquote> 
 One Unix package that is supposed to offer these features is Softway Ltd's
 Hibernator II.  Just SGI and a Fujitsu mainframe version are supported.
 This is probably an expensive commercial package and we shouldn't
 hold our breath for a Linux port.
<P>
	* http://softway.com.au/softway/products/hibernator.html
<P>
 The MOSIX project also supports transparent process migration (imagine
 that copy of emacs being moved from one overloaded CPU to an idle
 machine while you were using it).  It is currently available on
 BSD/OS.  However we're in luck!  As I was typing this and checking
 my URL's and references I noticed the following statement on their
 pages:
<P>
	``MOSIX for Linux (RedHat) is now under development''
<P>
 (Yay!).
<P>
 You can read more about MOSIX (and see this note yourself) at:
<P>
        http://www.cs.huji.ac.il/mosix/
		(Hebrew University, Israel)<BR> 
        http://www.cnds.jhu.edu/mirrors/mosix/txt_main.html
<P> 
 One OS project that I've been keeping my eye on for awhile has been
 EROS (http://www.cis.upenn.edu/~eros/).  This isn't widely
 available yet -- but I have high hopes for it.  It will use a
 "persistence" model that implicitly checkpoints the state of the
 entire system (all processes and threads).
<P>
 EROS is not "Unix" though it should eventually support a Unix/Linux
 compatible subsystem (called Dionysix).  The major difference is that
 EROS is a pure "capabilities" system.   ``Capabilities'' are the key to a
 security model that is much different than the traditional identity/group
 (Unix),  process privileges (VMS and Posix.6), and ACL (NT, Netware,
 etc) that are common in other operating systems.  Read Mr. Shapiro's
 web pages for more info on that.
<P>
 I personally think we (in the Linux community) have quite a bit
 to learn from other operating systems -- their strengths and
 their weaknesses.  To anyone of us who would say "But those are
 just obscure systems.  Nobody is running those!"  I would point
 out that millions of PC users still have that same reaction to
 Linux.
<P>
 So, to learn *far* more than you ever wanted to know about
 operating systems *other* than DOS, MacOS, and Unix take a
 look at the links on my short page about OS':
<P>
	 http://www.starshine.org/jim/os/
<P>
-- Jim

<p><hr><p> 
<!--================================================================-->

<a name="holloway"></a>
<h3><img align=bottom alt=" " src="../gx/ques.gif">
IP Masquerading/Proxy?
</h3>
<P> <B> 
From: Jack Holloway, <A HREF="mailto:njh@cs.monash.edu.au">
njh@cs.monash.edu.au</A> 
</B> <P><B>  
Ok... I'm alittle foggy on the terminology... if I have a machine on an
ethernet network that is hooked to the internet, and I want all of the other
machines on the network to connect to the internet THROUGH the machine
connected to the internet, I need to use IP masquerading or proxy server
stuff?
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	You can use IP Masquerading and/or any sort of proxy systems.
<P>
	IP Masquerading is a particular form of NAT (network
	address translation).
<P> 
	The one machine (your Linux box) that is connected to
	your LAN and to the Internet is the "router" or "gateway."
	("routers" work at the "transport" layer, while "gateways"
	work at the "applications" layer of the OSI reference model).
	(More on that later).
<P>
	One "real" (IANA issued) IP address is assigned to the
	"outer" interface and attached to the Internet (through
	your ISP). This will typically be a PPP link through your
	router/gateway's modem -- though it might be any network
	interface that you can get Linux to use.
<P>
	One the other interface (typically an ethernet card) you
	assign one out of any of the "private" or "reserved for
	disconnected networks" IP address ranges as defined in
	RFC1918 (previously in RFC1597 and 16??).  These RFC1918
	addresses are guaranteed to never be issued to any
	Internet host (so those of use using them on our networks
	will never create an ambiguity with *our* router by attempting
	to access a machine *outside* our network that has an IP
	address that duplicates one *inside* of our network).
<P>
	The RFC1918 address blocks are:
<PRE>
		10.*.*.*				(one class A net)
		172.16.*.* through 172.31.*.*		(16 class B's)
		192.168.0.* through 192.168.255.*	(255 class C's)
</PRE>
	You can pick any of those RFC1918 address blocks and
	you can subnet them anyway that's convenient.  I use
	192.168.64.0 for my home LAN.
<P>
	Within my LAN I use the .1 address (192.168.64.1) for my
	Linux gateway/router's ethernet -- it gets its other (real)
	IP address dynamically from my ISP when 'diald' establishes
	a connection (diald is a daemon that automatically invokes my
	ppp connection whenever traffic routing to the network is
	required -- I actually have another RFC1918 address assigned
	to the SLIP connection that diald uses for internal purposes).  
	I run a caching nameserver on this box (which we'll call "gw"). 
<P>
	All systems on my LAN execute a line like the following:
<PRE>
		route add -net 192.168.64.0 eth0
</PRE>
	... in their rc scripts at some point.  This configures
	them to all agree where packets for this network go.
	This is called a "static" route.
<P>
	I then point the /etc/resolv.conf on all of the "client" machines
	on my LAN to "gw" and add a default route to each of them that
	looks like:
<PRE>
		route add default gw 192.168.64.1
			# other traffic goes to host named "gw"
</PRE>
	(the "client" machines don't have to be Linux and don't
	have to have any special support for IP Masquerading --
	you just assign them IP addresses like 192.168.64.2, etc.
	to each of them).
<P>
	In the "gw" server I have the kernel compiled with masquerading
	and "forwarding" support enabled (of course).  I don't put in
	the default static route -- that would be a loop.  "gw" also
	has a different /etc/resolv.conf file -- one that points to
	a couple of my ISP nameservers.
<P>
	Note:  One trick I've learned about resolv.conf files --
	You only get three nameserver entries (in most versions of
	the bind libraries) -- so I repeat the first and the last
	one.  When a query times out (for a client) it moves to the
	second nameserver.  Meanwhile the first nameserver still
	has a good chance of getting a response  (DNS over today's
	busy Internet times out more often than nameservers fail).
	So, a timeout on the second nameserver leads to a repeat
	request on the first one -- which has probably received
	and cached a response by this time.  I could explain that
	in more detail -- but the real gist is:  try it.  It helps.
<P>
	Now, back to masquerading:
<P>
	All it takes for masquerading to work is to run the command
<PRE> 	
		LAN="192.168.64.0/24"
		ipfwadm -F -a accept -m -S $LAN -D 0.0.0.0/0
</PRE>
	... which means:
<P>
		use the "IP firewall administrative" program to
		make the following change to the "forwarding"  (-F)
		table:
<blockquote>
			add/append (-a) a rule to accept for
			masquerading (-m) any packet from (-S
			or "source address") my LAN (which is a
			shell variable I defined in the preceding
			line) that is going to (whose "destination"
  			-D) is anywhere (0.0.0.0/0).
</blockquote>
	Here's how that works.  When the kernel receives a packet
	that's not destined for the localhost (the gateway itself)
	it checks to see if forwarding is enabled, then it looks in
	the routing table to see where the packet should go.  My
	gateway's default route is pointing to the sl0 interface
	(the SLIP interface that diald maintains to detect outgoing
	traffic) -- when diald detects traffic on sl0 -- it
	runs my PPP connection script which changes the default
	route to point to my ISP's routers (which is part of the
	information that's negotiated via PPP along with my
	dynamic IP address).  Now the packet is "forwarded" from
	interface to the other. Assuming that the packet came
	from my LAN (via the ethernet card in "gw" the kernel's
	packet filtering ("firewall") code takes over.
<P>
	ipfw inspects the packet to see if it was part of an
	existing TCP session (part of a connection that it has
	already been working with).  If it is than ipfw notes
	the TCP "port" that this session is assigned to, otherwise
	ipfw just picks another port.  If it picks a new port it
	adds an entry to it's masquerading table that records the
	packet's original source address and source port.  The
	"client" machine on my LAN is expecting any reply packets to
	come back to the appropriate source port (which is how it
	knows which process' "socket" to write the reply packets to)
	-- ipfw then re-writes the packet headers, changing the source
	address to match the one on ppp0 (the "real IP address for
	which my ISP knows a route), and changing the source port to
	the one it selected.
<P>
	When ipfw receives reply packets the kernel routes them to
	sockets which ipfw owns (the source port on my outgoing
	packets becomes the destination port on the reply packets).
	ipfw then looks that socket up in its table, retrieves the
	*original* source addr and port (for the outgoing packet that
	generated this reply) rewrites the destination fields (on the
	*reply* packet).  Finally the (now re-written) packet is
	routed to the LAN.
<P>
	Effectively IP Masquerading makes a whole LAN full of machines
	look like one really busy one to the rest of the Internet.
	While a typical workstation might only have a few dozen
	active network connections available, a masquerading gateway
	might have hundreds or thousands.  As a practical matter
	the TCP/IP protocol provides a 16 bit field for "ports" and
	Most Unix systems can't handle more than a few thousand
	concurrent open connections (sockets) and file descriptors.
	(This has to do with the tables that the kernel allocates
	for the data structures that manage all this -- regardless
	of whether masquerading is active or not).  Luckily you're
	unlikely to have enough bandwidth to approach Linux'
	capacity.
<P>
	I'm sorry for the length of that description.  Note that
	it is purely conceptual (I've never read the code, I've
	just deduced what it must be doing from what I know of
	how TCP works).
<P> <B> 
<img align=bottom alt=" " src="../gx/ques.gif">
Ouch!  That's a big question there!  Ok, firstly, do own IPs for every
machine on your network? (That is, do you have an internet unique IP for
each machine)  If so, all you want is routed.  If you don't, then to
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	'routed' is deprecated.  In addition he doesn't need routed
	or gated to talk to his ISP (and almost certainly can't
	use it with them -- they won't listen to his routes unless
	he goes out and gets an AS number and negotiates a contract
	for "peering" with them which would absurd unless he were
	becoming a multi-home ISP or something like that).
<P>
	The case where routed or gated makes sense is with his
	own internetwork of LAN's.  If he has several ethernet
	segments and is moving systems around them frequently
	(or adding new IP devices to them) then it would be
	be useful.  For simpler and for more structured LANs
	(each ether segment gets a subnet -- a global, static
	routing table is distributed to all routers) you don't
	need or want 'routed' or 'gated'.
<P>
	If he had a block of ISP (or IANA) issued IP addresses,
	his ISP would have to include routing to them (they
	don't make sense otherwise).  Usually this amounts to
	some static routes that they maintain in their systems
	-- specifically some entries that are invoked whenever
	your system authenticates on one of their terminal servers
	or routers.
<P>
	You don't have to run any software on your end to make
	use of this routing.  (That's a confusing statement --	
	you have to run PPP or SLIP to connect to them -- but
	once you're connected they will route packets to you
	even if your routes back to them are completely missing).
<P>
	As I've described above -- you just have to have your
	own LAN routing set up properly.  That means that each
	system on your LAN has "-net" routes unto your ethernet
	and a "default gw" route to your router/gateway (masquerading
	host).
<P> <B> 
<img align=bottom alt=" " src="../gx/ques.gif">
browse the web you can use a proxy server(which looks to the outside world
as if only the proxy is actually on the net.).  If you want to telnet etc.
out, you will need IP-Masquerading, which isn't the most reliable way of
doing things.  ask me further in email if you need more detail!
</B> <P> 
<img align=bottom alt=" " src="../gx/ans2.gif">
	I disagree with several points here.  Both masquerading *and*
	proxying look like "only the proxy is actually on the net."
	-- because only the router/gateway has an IP address with
	valid Internet routes.  The rest of your LAN is "hidden"
	(behind your "gw") because those IP addresses don't have
	valid Internet routes.  The are IP addresses but they are
	not *Internet* addresses!
<P>
	Proxying is an applications layer solution.  Masquerading
	and NAT are transport layer.  The difference is what
	data structures the software is dealing with. 
<P>
	At the network layer we're working with "data frames."  This
	is what an ethernet bridge or switch uses -- the MAC (BIA)
	addresses.  That's also the layer at which ARP (address
	resolution protocol) works.  It's how one host finds
	finds the ethernet card address of another system that's
	on the same LAN (how our client machines "find" our router/gw).
<P>
	At the transport layer we deal with packets. These have IP
	addresses (as opposed to the MAC -- media access control --
	addresses in the ethernet "frame" header).  This is where
	the masquerading happens.  As I've described masquerading
	involves a relatively "dumb" (mechanical) bit of packet
	patching with some table reference and maintenance. 
	Technically there are some details I left out -- like
	recomputing the packet checksums.
<P>
	The problem is that the transport layer conveys no information
	about the applications protocol for which it is a carrier.
	For "normal" TCP protocols (like HTTP and telnet) this is
	no problem.  However, FTP and a few other protocols do "bad"
	things.  In particular an FTP session consists of *two* TCP
	sessions (a control session which is initiated from the client
	to the server) and a data session which is initiated from the
	server back to the client!  The IP address and port to which
	this "return connection" goes is passed to the server via
	the control connection.  This last detail has caused more
	firewall designers and admins to rip out their hair than
	all the cheap combs from China.  In the context of masquerading
	it means that the masquerading server must monitor the
	*data* (the stuff in the payloads of the packets) and make
	some selective patches therein.  In the other cases we only
	touched the headers of each packet -- never the contents of
	their payloads.
<P>
	So, this is the part of Masquerading that is unreliable.
	Linux IP Masquerading is by no means the only flavor --
	though it's probably the most widely used by now.  Linux
	as several modules for dealing with unruly protocols --
	so the usually work. 
<P>
	However, I've found it more reliable to use the TIS FWTK
	ftp-gw (Trusted Information Systems http://www.tis.com,
	Firewall Toolkit).  This is a proxy.
<P>
	Proxy packages work at the applications layer.  You have
	to have support for each applications protocol (http, ftp,
	telnet, rlogin, smtp, etc) that you want to allow "through"
	your firewall.  They come in two forms:  SOCKS and FWTK
	(There are many of them besides these -- but all of them
	follow one *model* or the other).
<P>
	In the FWTK model the user opens his or her initial
	connection to the firewall (I 'ftp' to gw.starshine.org).
	The firewall (gateway) is running the FWTK proxy *instead
	of* (or *in addition to*) the normal server (ftpd).  If
	it is "in addition to" than one or the other must be on a
	different port or using a different IP Alias on the machine
	(more on that later).  Now my FTP server (ftp-gw) prompts
	me to "login"
<P>
	For a normal FTP server I'd type my name (or "ftp" or "anonymous"). 
	For ftp-gw I'm trying to go *though* this machine and unto
	one that's on the other side (on the Internet).  So I have to
	provide more information.  So I type:
<P>
		ftp@sunsite.unc.edu
<P>
	... or
<P> 
		webauthor@www.svlug.org
<P>
	... or whatever.  The gateway ftp server then opens a connection
	to my target (everthing *after* the @ sign) and passes my
	name (everything before the @ sign) to *its* login prompt.
<P>
	The TIS FWTK comes with a number of other small proxies --
	and most of them work in a similar fasion.  (There are
	also options to limit *who* can access *what* and *when*
	(via administrator edited access control lists).
<P>
	The key point here is that FWTK doesn't require any special
	client software support.  The users have to be trained how
	to traverse the firewall and the have to remember how to do it.
<P>
	FWTK is only appropriate for relative small groups of technically
	savvy users (who are easy to train in this and won't make the
	sysadmin's life a constant hell of walking everyone through this
	extra connectivity step).
<P>
	SOCKS has a model that works for larger groups of less savvy
	users.  However, it requires that you install SOCKS aware
	versions of your client applications.  So you have to replace
	your normal telnet, ftp, rlogin, etc with a  "socksified"
	version.  In many cases it is possible to effectively
	"socksify" all of your client utilities by replacing a shared
	library (Unix/Linux) or a DLL (Windows).  Many commercial
	TCP clients and utilities are built with SOCKS support
	(Netscape Navigator and Communicator are prime examples). 
	I think the Trumpet shareware utilities for Windows are
	another.
<P> 
	The hassle is installing and configuring this software on every
	client system.  However, the advantage is that none of the users
	has to remember, or even know, about the firewall.  The SOCKS
	applications will automatically negotiate sessions through the
	firewall.
<P>
	There are some protocols that are inherently easy or even
	unnecessary to proxy. For example DNS doesn't need to
	be proxied.  You run your caching copy of named and let
	all of the client machines talk to and trust it.  This
	gives a great performance boost to most of the clients
	and saves quite a bit of bandwidth on the critical link
	to the ISP.  There is no reason that I can think of not
	to run a caching nameserver somewhere on your Internet
	connected LAN.
<P>
	HTTP is a protocol that benefits quite a bit from proxying.
	It is trivial to add caching features a web proxy -- and
	I think just about all of them do so. 
<P>
	SMTP is a protocol that doesn't need proxying (from the
	standpoint of the clients on your LAN).  You configure
	an internally accessible system to accept mail and
	it will relay it to your gateway via whatever means
	you configure.   A typical model would be that outgoing
	mail is collected on an internal hub, which is configured
	to relay it to the external gateway, which, in turn,
	relays it to the ISP and on to the world.  To see what
	this looks like read the "Received" headers in some of your
	mail.
<P>
	The externally visible mail gateway can route mail
	back to the internal hub -- which can run POP and/or
	IMAP servers for the clients to use to actually get
	their mail.  (You could have the internal hub route
	all of the mail directly to people's desktops via
	SMTP too.
<P>
	The reason you generally don't need proxying for
	SMTP is that most sites use some form of masquerading
	(mail appears to come from the "domain" rather than from
	a particular host whithin the domain).  FWTK includes
	smapd -- and there is an independent and free smtpd
	which act as proxies for sendmail.  Here the intend is
	to have a small simple program receive mail and
	pass it along to the larger, vastly more complicated
	'sendmail' itself.  (I don't want to get into the
	raging debates about sendmail vs. qmail etc -- suffice
	it to say there are many alternatives).
<P>
	Note that masquerading and proxying are not mutually
	exclusive.  I use masquerading and I have ftp-gw and
	squid (caching web service) installed.  I could
	also install SOCKS on the same gateway.
<P>
	Incidentally I mentioned that it's possible to run ftpd
	and ftp-gw on the same machine without putting them on
	different ports.  Here's two ways of doing that:
<P>
	IP Aliasing method:
<ol>
<li>		You install ftpd and ftp-gw
<li>		You create an IP Alias (you add an extra address
		    to your gateway system's internal interface with
		    a command like:
<PRE>
				ifconfig eth0:1 192.168.64.129
</PRE>
<li>		You configure your TCP Wrappers to virtual host
		    a service by adding a line like this to your
		    /etc/hosts.allow file:
<PRE>
     in.ftpd@192.168.64.129: 192.168.64. : twist  /usr/local/fwtk/ftp-gw
</PRE>
		   This will "twist" any ftp request *to that IP alias*
		   into an ftp-gw session.  FTP requests to any other
		   interface address will be handled in the usual way
		   (tcpd will launch the ftp daemon that's listed in
		   inetd.conf).
</ol>
	   That's all there is to that method.  Note that you can
	   to other interesting things with this sort of virtual
	   hosting, if you're clever.
<P>
	Loopback Twist method:
<ol>
<li>		Install ftpd and ftp-gw (as you would for
		  the other method).
<P>
<li>		Configure tcp wrappers to allow normal ftp
		  access *from* the localhost address (127.0.0.1)
<P>
<li>		Configure tcp wrappers to twist any other
		  ftp requests into ftp-gw
</ol>
	   That looks like this (in the /etc/hosts.allow file):
<PRE>
in.ftpd: 127.0.0.1 : ALLOW
in.ftpd : ALL : twist  /usr/local/fwtk/ftp-gw
</PRE>
	    WARNING! This second line would allow *anyone*
	    (from inside or outside) of your LAN to access the
	    proxy.  However, ftp-gw reads a file --
            /usr/local/etc/netperm-table according to the way I
	    compiled mine -- to determine who is allowed to access
	    each of its proxy services.
<P>
	    So, this line is neither as dangerous as it looks
	    nor as safe as it should be.  Changing it to:
<PRE> 		
in.ftpd : LOCAL : twist  /usr/local/fwtk/ftp-gw
</PRE>
	   ... is safer and more appropriate.
<P>
	One key point here is that you can use proxies on
	your masquerading route/gateway to allow access from
	the "outside" back *into* services inside your LAN.
	Usually you want to prevent this (the whole point of
	a firewall).  However you can use tcpd and netperm to
	allow specific 'friendly' networks to get to servers
	on one of your LAN's, despite the fact that there are
	no routes directly to those machines.
<P>
	This brings us back to other forms of NAT.  I mentioned
	at the get-go that masquerading is one form of NAT.  It
	specifically involves a "many to one" arrangement.
	(The "many" clients on your LAN appearing as "one" connection
	to the Internet). 
<P>
	Another form of NAT is "many to many" -- where you have a
	table translations.  Thus each of your systems might be
	configured to use one address, and be translated to appear as
	if it came from anoter.  I personally don't see much use for
	this arrangement.  The one case I could see for it might be
	if you had a net of devices that you couldn't renumber, which
	had "illegal" or "invalid" addresses.
<P>
	One other form of NAT involves a different "many to many"
	translation -- its not currently available for Linux but
	it's used in the Cisco Local Director product.  This is a
	trick for doing IP level load balancing.   You have a
	"reverse masquerade" host accept requests to "a" busy
	server (one service on one IP address) and you have it
	masquerade the session to any of multiple "inside" machines
	that have the same service and content available.
<P>
	For load balancing it's trivially easy to use DNS "round
	robin records" -- so I don't see much application for this
	form of NAT either.
<P>
	Anyway -- that's all I have the energy to type for now.
<P>
	I hope this explains the terms and concepts and gives you
	enough examples to set up what you want.  For the most part
	you can just use the one magic ipfwadm command to "turn on"
	masquerading.  The rest is just the configuration of your
	network and of your ISP connection -- which you've presumably
	already done.
<P>
-- Jim

<!--================================================================-->
<P> <hr> <P>
<center><H5>Copyright &copy; 1998, James T. Dennis <BR>
Published in <I>Linux Gazette</I> Issue 27 April 1998</H5></center>
<P> <hr> <P>
<!--================================================================-->
<A HREF="./lg_toc27.html"><IMG SRC="../gx/indexnew.gif" ALT="[ TABLE OF
CONTENTS ]"></A> <A HREF="../index.html"><IMG SRC="../gx/homenew.gif"
ALT="[ FRONT PAGE ]"></A>
<A HREF="lg_bytes27.html"><IMG SRC="../gx/back2.gif" ALT=" Back "></A>
<A HREF="./kodis.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
<!--startcut =======================================================  -->
</body>
</html>
<!--endcut =========================================================  -->