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 126.96.36.199, 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://188.8.131.52 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 184.108.40.206. 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 220.127.116.11, 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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- KDE Reveals Plasma Mobile
- Embed Linux in Monitoring and Control Systems
- Shashlik - a Tasty New Android Simulator
- Purism Librem 13 Review
- diff -u: What's New in Kernel Development