Workings of a Virtual Private Network in Linux—Part 2
Now let's run the script to automate and complete what we did by hand. Here is a local screen capture:
[root@localhost /root]# /etc/rc.d/init.d/VPN start setting up vpn tty is /dev/ttyp1 [root@localhost /root]#
The simultaneous remote log is shown in Listing 1, which shows that sshd agrees to run the command requested by ssh; sshd puts the conversation on port 1022 this time. The requested command (see VPN HOWTO script line 33) is sudo, not pppd. Within the remote machine, sudo in turn runs pppd, which prepares to use an interface called ppp2 and associates it with pseudo-terminal /dev/ttyp1. Just about this time, somebody runs pppd at the local machine (see line 39). Two pppd's meet in the middle, and the local pppd (through ssh, then sshd) tells the remote pppd what IP address numbers it wants to use for each end of this connection. Remote pppd agrees, and records those addresses in the log. At that point, the secure link is in place, bilaterally. The script then proceeds to run route. It informs each VPN server by address which additional machines are available to be reached through the new connection beyond the other server (i.e., the address of the network the opposite server is on). In reaction to script line 46, the log shows sshd reinvoked under new process ID number 1439, this time to have sudo run sshroute, a script (see end of HOWTO section 4.10) that contains the appropriate route command.
The dust has settled. The secure link is now in place. How can we see and use it? It takes the form of a new PPP interface. See it by running ifconfig. Use it by referring certain addresses to it in the routing table (already done), then referring applications to those addresses.
ifconfig now shows two ppp interfaces on each machine, old and new. A screen capture on the local machine looks like that in Listing 2. A screen capture on the remote machine is shown in Listing 3. Local-machine's ppp1 and remote-machine's ppp2 are opposite ends of the same connection, or interfaces to one another. This connection is the one just constructed. Note interface number assignment is machine-specific, and the numbers need not be identical. Local and remote ppp0, the machines' respective ISP connections, aren't directly related.
To refer to the other, each VPN server now has a choice of IP addresses. Local-machine can still contact the remote machine at its public Internet address 206.170.217.204, but has the additional option of calling it 192.168.0.2. If the remote machine is running a web server, for example, a browser on the local machine will pull up exactly the same page by addressing itself to http://206.170.217.204 or http://192.168.0.2. The remote machine can be pinged using either address. To all appearances, our two ppp interfaces seem independent and equivalent. Logically, they are, and you can use them as if they were; physically, they are not.
What's the difference? Primarily, that packets to 192.168.0.2 don't travel on the same footing as those to 206.170.217.204. Rather, the former are carried as data “freight” inside the latter. That's why I depicted the PPP connection as tributary to the public ISP connection in the network diagram in Part 1. The arrangement is called tunneling, because once freight packets arrive at their destination, they emerge from their enclosing packets as from a tunnel. They're released onto the destination network as functional packets, not just passive data.
You may have noticed that the 192.168.0.0 IP addresses chosen for the secure link belong to the “reserved” range prohibited for use on the Internet (PPP HOWTO section 2), yet we are using these on the Internet. Tunneling is what allows us to get away with it. While on the Internet, packets bearing these addresses travel only as data. The Internet need not route them according to those addresses—they piggyback on packets addressed legitimately.
Tunneling enters the discussion of all VPN protocols. Some reflect it in their name, such as Microsoft's PPTP or Point-to-Point Tunneling Protocol. Tunneling is a characteristic of VPNs; if the data being tunneled also gets encrypted, you have a VPN.
That's the other difference here—encryption. Ping packets and web pages going to and from 192.168.0.2 get encrypted and decrypted. Those going to 206.170.217.204, even though it is the same place, do not. But you would not know about the encryption or tunneling, because they're transparent. Since both are present, this is a VPN.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Home, My Backup Data Center
- What's the tweeting protocol?
- New Products
- One Hand Slapping
- Readers' Choice Awards
- The Secret Password Is...
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.




6 hours 26 min ago
8 hours 58 min ago
10 hours 16 min ago
10 hours 51 min ago
11 hours 13 min ago
16 hours 2 min ago
16 hours 48 min ago
18 hours 22 min ago
19 hours 59 min ago
21 hours 57 min ago