Workings of a Virtual Private Network in Linux—Part 2

This is the place to contrast connections made by pppd versus ssh and other daemons. The VPN uses both symmetrical and asymmetrical connections to achieve “tunneling”. ssh is asymmetrical and uses the TCP/IP service-port connections; pppd is symmetrical and uses device-port connections.

The PPP HOWTO section 14, “Setting up the PPP connection manually”, illustrates pppd's requirements. It has to run simultaneously on both computers: the two output streams “meeting in the middle”, so they can negotiate the connection setup. pppd's output stream, visible above, may look like garbage; however, it is pppd's signature and is very meaningful to another copy of pppd. (The PPP HOWTO section 9.5 introduces “ppp garbage”.)

“Meeting in the middle” means getting opposite pppd's to run over terminal or port devices (/dev/ttyX) that connect, with the output of each coming in as input to the other. The idea is to get the incoming data stream fed into an identifiable local device, then launch a local pppd into that same device. The outgoing stream moves into the same “pipeline” from which the incoming one emerges. Any available terminal or serial port device will do. Since Linux provides /dev/ttypx pseudo-terminals that are serial port emulators, they will work just as well. That's essentially what the pty-redir program is doing; it arranges for opposing pppd data streams to meet in the middle. Once that happens, handshaking and negotiation ensue, ultimately manifesting as a pppx interface viewable with the ifconfig command.

This highlights one big difference between pppd and other daemons: symmetry. Last month, we said daemons belong to a matched pair of distinct programs: one the client, one the server or daemon. With pppd there's no distinction, i.e., no client. The program pppd talks to is always another copy of pppd itself, a conversation symmetrical with itself rather than asymmetrical with a different program.

The other difference is that other daemons such as sshd talk over TCP/IP connections involving TCP/IP ports. pppd talks over a connection and uses ports too, but it builds its own kind of connection with its own protocol, not TCP/IP. It uses port devices, not the numbered service ports (sockets) of TCP/IP.

Since computers can multitask, TCP/IP provides for simultaneous conversations between multiple pairs of processes on any given pair of computers. The conversations are broken into data packets. Each packet has a label (header) bearing the destination computer's IP address and port number. Of the (possibly) many conversations the destination computer might be conducting, the port number identifies the one to which this packet belongs. A conversation is uniquely defined by a set of four items in the header: IP address at each end and TCP port number at each end. The packets look like those in Figure 1 (simplified). See “Introduction to the Internet Protocols” at http://oac3.hsc.uth.tmc.edu/staff/snewton/tcp-tutorial/.

Figure 1

In the conversation logged above, we invoked ssh on the command line and directed it to remote computer 206.170.217.204. The first line in the remote log shows:

Nov  7 20:21:43 localhost sshd[1406]: log: Connection from 206.170.218.30 port 1023

ssh launched a packet to sshd on the remote computer. sshd is set up to “reside” at port 22, as ssh knows. The packet it launched looked like that in Figure 2.

Figure 2

sshd on remote port 22 heard this and answered with packets of its own, swapping the above destination and port values left to right. A conversation was underway. The main order of business was encryption key negotiation and authentication, but before getting into that, it looks like sshd told ssh to change port numbers from 22 to 1406 (according to that log entry, which is “signed” by sshd). Thereafter, a flurry of packets like those shown in Figure 3 flew back and forth.

Figure 3

Certain server applications conventionally run on defined port numbers, known publicly so that clients have a place to contact them. These are called “well-known” or “privileged” ports and range from 0 to 1023. (See /etc/services. Port 80 is reserved for httpd, for instance, port 21 for ftpd.) Once contacted, servers often ask clients to switch port numbers to clear its well-known port for other incoming conversations. Port 22 is the main sshd switchboard. The operator there offloads you to another line as quickly as possible (“Please hold while I transfer you”), so she can handle other incoming calls.

It should now be clear that pppd could never use TCP/IP service ports, since no TCP/IP connection generally exists when pppd runs. The connection pppd has to work with is physical—a phone line or direct serial cable. TCP/IP is a transport-layer protocol. pppd (based on HDLC) runs at the lower data-link communications layer, and pppd packets are carriers or envelopes for TCP/IP (or other) packets. Because of these fundamental differences, the overlapping references to “daemons” and “ports” is unfortunate.