138
SLAVEACC This is the login name for the masters account on the slave. For us, its vpn1.
PPPD, REDIR, SSH Check the location of these utilities to make sure the paths match those on your
system.
When we were finished editing the file, our settings looked like this:
PATH=usrlocalsbin:sbin:bin:usrsbin:usrbin:usrbinX11: PPPAPP=homevpn1ppp
ROUTEAPP=homevpn1route PPPD=usrsbinpppd
NAME=VPN REDIR=usrlocalbinpty-redir
SSH=usrlocalbinssh MYPPPIP=192.168.1.1
TARGETIP=192.168.1.2 TARGETNET=192.168.4.0
MYNET=192.168.3.0 SLAVEWALL=slave-gw.ora-vpn.com
SLAVEACC=vpn1
The next useful item to look at in the script is the line that actually starts up pppd on the slave. It looks like this:
REDIR SSH -o Batchmode yes -t -l SLAVEACC SLAVEWALL\ sudo PPPAPP tmpdevice
As you can see, this is similar to what we did by hand earlier. The
-o Batchmode yes
option has been added to ssh to let it know its in a script and shouldnt ask for passwords or
passphrases. The
-t
option forces ssh to allocate a pseudo terminal on the slave which, as we said earlier, doesnt normally occur when ssh is used solely to execute a remote command.
The pseudo tty on the slave is required for pppds IO. The pty-redir program generates a new pseudo-terminal on the master, which is used to actually run the ssh program. The name of the
pseudo- terminal is redirected into the file called tmpdevice, which is used later by the master-side pppd in the script. Note that pty-redir outputs the tty name using STDERR. In
order for us to get the script to redirect the STDERR output to the tmpdevice file, we had to change it to look like this the 2 is the number for the standard error output:
REDIR SSH -o Batchmode yes -t -l SLAVEACC SLAVEWALL\ sudo PPPAPP 2tmpdevice
Another thing to note is that theres a ten-second sleep period after this command is run before execution continues. This is to give the SSH connection time to open, and the slave long
enough to start the PPP daemon. This value can be adjusted for your environment.
Once the VPN script is configured, you can place it in a startup directory, such as etc.rc.d. Youll want to change the permissions so that only root can execute it
rwx------
. It can be called from the rc.local file with the following command:
139 etcrc.dVPN start
It can also be started by hand this way.
8.4.2.8 Setting up the slaves scripts
On the slave, there are only two simple scripts. The first is called ppp, and the second is route. These both reside in the home directory of the masters account on the slave, in our case
homevpn1.
The ppp script is very simple, and has this single line:
binbash usrsbinppp
Remember that youve already put a .ppprc file with the single line of passive in the vpn1 users home directory.
The route script simply contains the route thats going to be added so that the slave machine knows how to get back to the masters LAN. For us, it will look like this:
binbash sbinroute add -net 192.168.3.0 gw 192.168.1.1
The permissions on both scripts should be changed so that vpn1 is the owner and has full permissions to both files, while nobody else does:
-rwx------ 1 vpn1 users 27 Jun 6 01:30 ppp -rwx------ 1 vpn1 users 1 Jun 6 01:40 route
8.4.3 Testing the Connection
Now that everything is in place, you can test your VPN connection. The first thing to do is start up the VPN script by hand. You should see something like this:
VPN start setting up vpn
tty is devttyp1
Thats it. It should be up and running now. From the master, attempt to ping the slaves VPN interface address of 192.168.1.2. You should get a reply. Next, attempt to ping the LAN
interface on the slave, and you should also get a reply. Finally, attempt to ping another machine on the slaves LAN, from which you should also get a reply.
Doing ifconfig on the master or slave should show you the PPP interface being used for the VPN. For instance, here is the output from our master:
ppp0 Link encap:Point-Point Protocol inet addr:192.168.1.1 P-t-P:192.168.1.2 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:61 errors:1 dropped:0 overruns:0
TX packets:61 errors:0 dropped:0 overruns:0
140
Similarly, the route command should show you all of the routes that have been added to whatever system you run it on.
8.5 Troubleshooting Problems
Now let us assume that everything didnt go as smoothly as planned. There are several points of failure along the way, but fortunately there are some good ways to pinpoint the problem.
8.5.1 Errors from the VPN Script
The following are errors that might occur when you execute the VPN script. All of these errors should appear directly on the screen. When looking at these errors, its important to
remember the essentials of what the VPN script does: it redirects a pseudo-terminal, launches the PPP daemon on the slave using SSH, launches the PPP daemon on the master, and sets up
routing on both the master and slave.
FAILED If you see this message, pty-redir failed to get a valid pseudo-terminal. You should
check the contents of the tmpdevice file and see if its empty. If it exists but is empty, and you actually saw pty-redir spit out a device name when you ran it by hand earlier,
STDERR output may not be redirected to that file. You will have to add a 2 as we showed under
Section 8.4.2.7 .
SIOCADDR: Network is unreachable This is a message from one of the route commands. It can mean there is a mistake
either in one of the IP addresses or networks in the VPN script settings, or in the slaves route script. Or it could mean that a PPP connection was never successfully
started, in which case youll need to check the logs see
Section 8.5.2 .
SIOCADDRT: Operation not permitted This is also a message from one of the route commands. It means that youre not
allowed to execute the route command in order to add a route, and is probably taking place on the slave. You should double-check your sudoers file on the slave to make
sure that your master account has permission to execute the route command as root.
8.5.2 Connection Problems
If you get the Network is unreachable error from the VPN script, you might want to look at a process list on the slave using the ps command to see if the PPP daemon is running. If it
isnt, either the SSH connection wasnt completely successful, or the PPP daemon failed to start up. The best place to look for problems with both of these is in varadmmessages on the
slave. A normal ssh and pppd startup on the slave should look like this in the logs:
Jun 6 04:01:40 slave-lan sshd[18745]: log: Connection from 1.0.0.1 port 1 Jun 6 04:01:41 slave-lan sshd[18745]: log: RSA authentication for vpn1
accepted Jun 6 04:01:41 slave-lan sshd[18747]: log: executing remote command as
user vpn1
