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/.
In the conversation logged above, we invoked ssh on the command line and directed it to remote computer 22.214.171.124. The first line in the remote log shows:
Nov 7 20:21:43 localhost sshd: log: Connection from 126.96.36.199 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.
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.
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.
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!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide