Application
layer tunnels in Linux 2.2.x
As could be seen on figure I, the main reason of implementing application tunnel support in linux kernel, is to override possible inconvenient
firewall rules. But this is from the most often encountered practical view-point. Absolutely, the sense of those kind of tunnels is data relaying
(most of the tunnel types represent the same sense), provoked by one or another reason (security, changing route possibility, firewall overriding,
etc.).
Figure I shows the possible path of two types of packets, targeted to some destination service - "pure" datagram and encapsulated datagram.
There are two possibilities for non-encapsulated packet - to travel to the destination via whatever route or to be rejected by a firewall on the
trace. While the things for encapsulated packet are very different. The one could choose one or more proxies of different kind (HTTP, SOCKS4,
SOCKS5) and to force routing the packet through them to the final destination. The main advantages of this model are two - overriding firewall
rules (as is written above) and choose a possible "kind" of route for the packet (overriding the problem with unreachable networks for example).
Of course there are some restrictions, which are common for all types of relaying/tunneling. For "the real world", when using relays, the one's
host is represented by the relay. Every host, which is not within Source Host's (see Figure I) subnet, could see activity from the relaying host,
but not from Source Host. This is some kind of NAT (because for outer world our address is masqueraded with the address of the relay) and
as type of NAT, application layer tunneling has such limitations. For example - presume that our host is using application tunneling and there is
a FTP client, connected via the relay to FTP server. Because for the FTP Server the client is our relay, we should act as passive client (data
transfer port determination should be made by the server).
Figure I
