VPNs
Building virtual private networks (VPNs) with Globus
If we want a ppp-connection, we'll have to tell glogin to fire up the ppp-daemon.
Again, we use the -c parameter. We assume an already properly configured
ppp-daemon on pan: the file in the peers-directory looks like this:
hr@pan$ cat /etc/ppp/peers/globus
noauth
1.2.3.4:5.6.7.8
Note that, since we are starting pppd as non-root-user, the neccessary options have to be present in
a config-file, since pppd does not allow settings options on the command-line for non-root-users.
Additionally, it is required that pppd is setuid root, or else a "normal" user won't be able to start
the ppp-daemon. So, on clio, we type:
hr@clio$ glogin pan -t -c "/usr/sbin/pppd call globus"
}#!}!}!} }4}"}&} } } } }%}&9}9%}'}"}(}"J~~}#!}!}!} }4}"}&} } } }
}%}&9}9%}'}"}(}"J~~}#!}!}!} }4}"}&} } } }
}%}&9}9%}'}"}(}"J~~}#!}!}!} }4}"}&} } } } }%}&9}9%}'}"}(}"J~
The "modem-noise" you see is the output from the pppd on pan
. These are LCP configuration requests. These requests appear now in the terminal, which tells us, that the remote pppd is working properly. However, for a point-to-point-connection, we also have to have a local endpoint, that is, we need to run a local pppd, which will process this output. Like the remote pppd, the local pppd needs to allocate a pseudo-terminal, too (we don't have any modem), and somehow start the glogin-client. We are lucky, because as of pppd-2.4, the "pty" option for pppd has been introduced which does exactly *that*. To quote the manual-page:
pty script
Specifies that the command script is to be used to
communicate rather than a specific terminal device.
Pppd will allocate itself a pseudo-tty master/slave
pair and use the slave as its terminal device.
Since we are executing pppd as non-root-user, all neccessary options have to be present in a
peers-file already. There is not much required in this file:
hr@clio$ cat /etc/ppp/peers/globus.pan
noauth
nodetach
pty "glogin pan -t -c '/usr/sbin/pppd call globus'"
We already know about noauth. New is nodetach, which will prevent pppd
forking off into the background. This way, we'll see what pppd is doing in our terminal window.
The pty option instructs pppd to call glogin, which in turn logs into pan and starts
the remote pppd there. Easy, da?
So, how does this look like?
On clio, we do:
hr@clio$ pppd call globus.pan
Using interface ppp0
Connect: ppp0 <--> /dev/pts/4
Deflate (15) compression enabled
local IP address 5.6.7.8
remote IP address 1.2.3.4
and our ppp-device is ready. From another terminal window, we can see:
hr@clio$ /sbin/ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:5.6.7.8 P-t-P:1.2.3.4 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:72 (72.0 b) TX bytes:78 (78.0 b)
a ppp0-device on clio, while on pan we will see:
hr@pan$ ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:1.2.3.4 P-t-P:5.6.7.8 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:78 (78.0 b) TX bytes:72 (72.0 b)
another ppp0-device, but with local and remote addresses switched. Any traffic routed over these
device is GSS-encrypted, as our tcpdump reveals. On clio, we ping
the remote end of the ppp-device:
hr@clio$ ping -p c1c2c3c4 1.2.3.4
PATTERN: 0xc1c2c3c4
PING 1.2.3.4 (1.2.3.4): 56 octets data
64 octets from 1.2.3.4: icmp_seq=0 ttl=64 time=1.6 ms
64 octets from 1.2.3.4: icmp_seq=1 ttl=64 time=1.6 ms
64 octets from 1.2.3.4: icmp_seq=2 ttl=64 time=1.4 ms
64 octets from 1.2.3.4: icmp_seq=3 ttl=64 time=1.4 ms
64 octets from 1.2.3.4: icmp_seq=4 ttl=64 time=1.5 ms
In a root-window, we monitor the traffic and see:
root@clio# tcpdump -X -i ppp0
tcpdump: listening on ppp0
00:27:46.529798 5.6.7.8 > 1.2.3.4: icmp: echo request (DF)
0x0000 4500 0054 0000 4000 4001 2a96 0506 0708 E..T..@.@.*.....
0x0010 0102 0304 0800 2cbe 9807 0700 728a 0040 ......,.....r..@
0x0020 6f15 0800 c1c2 c3c4 c1c2 c3c4 c1c2 c3c4 o...............
0x0030 c1c2 c3c4 ....
00:27:46.531589 1.2.3.4 > 5.6.7.8: icmp: echo reply
0x0000 4500 0054 42ce 0000 4001 27c8 0102 0304 E..TB...@.'.....
0x0010 0506 0708 0000 34be 9807 0700 728a 0040 ......4.....r..@
0x0020 6f15 0800 c1c2 c3c4 c1c2 c3c4 c1c2 c3c4 o...............
0x0030 c1c2 c3c4 ....
that we are sending and receiving clear-text on the ppp-link. But how does this traffic
look like on our gss-link? We use tcpdump on the ethernet-device and see:
root@clio# tcpdump -X -i eth0 host pan
tcpdump: listening on eth0
00:31:06.331417 clio.gup.uni-linz.ac.at.47172 > pan.51590: P 3443683329:
3443683386(57) ack 3487254598 win 17376 <nop,nop,timestamp 249822817 1129697355> (DF)
0x0000 4500 006d b981 4000 4006 9855 8c4e 6804 E..m..@.@..U.Nh.
0x0010 8c4e 6813 b844 c986 cd42 7001 cfdb 4846 .Nh..D...Bp...HF
0x0020 8018 43e0 2e9d 0000 0101 080a 0ee3 fe61 ..C............a
0x0030 4355 d04b 0000 CU.K..
00:31:06.332607 pan.51590 > clio.gup.uni-linz.ac.at.47172: P 1:66(65) ack 57 win
11584 <nop,nop,timestamp 1129698084 249822817> (DF)
0x0000 4500 0075 3821 4000 4006 19ae 8c4e 6813 E..u8!@.@....Nh.
0x0010 8c4e 6804 c986 b844 cfdb 4846 cd42 703a .Nh....D..HF.Bp:
0x0020 8018 2d40 8a5c 0000 0101 080a 4355 d324 ..-@.\......CU.$
0x0030 0ee3 fe61 0000 ...a..
00:31:06.332645 clio.gup.uni-linz.ac.at.47172 > pan.51590: . ack 66 win 17376
<nop,nop,timestamp 249822817 1129698084> (DF)
0x0000 4500 0034 b982 4000 4006 988d 8c4e 6804 E..4..@.@....Nh.
0x0010 8c4e 6813 b844 c986 cd42 703a cfdb 4887 .Nh..D...Bp:..H.
0x0020 8010 43e0 4ebe 0000 0101 080a 0ee3 fe61 ..C.N..........a
0x0030 4355 d324 CU.$
that our nice hexadecimal pattern is no more! Everything passing over the network is encrypted by the GSS.
X11 tunneling with VPNs
Note that "everything" really means: everything! Any IP-traffic, be it ICMP, UDP, TCP, be it POP, SMTP, X11 ... is encrypted and transported securely. Let's assume we want to securely transmit the output of a legacy X11 application running on a grid-node. For the sake of easyness, we use "xhost + " to allow the remote host output X11-traffic (please don't try that at work: use "xauth" instead"). On the remote host, we have to adjust the DISPLAY variable and: hr@clio$ /sbin/ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:5.6.7.8 P-t-P:1.2.3.4 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:358 errors:0 dropped:0 overruns:0 frame:0
TX packets:328 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:99340 (97.0 Kb) TX bytes:52482 (51.2 Kb)
hr@clio$ xhost + 1.2.3.4
1.2.3.4 being added to access control list
On pan:
hr@pan$ export DISPLAY=5.6.7.8:0
hr@pan$ xterm
An xterminal from pan will now appear on clio. Note that this will work
with any X11-application, not just xterm!
Routing VPNs with glogin
Since we now have a ppp-link betweenclio and pan, we can attach arbitary
networks to the nodes. If we enable IP-forwarding, we can turn the machines into routers, which will
route traffic for their private networks over a GSS-connection. I personally don't see what we could
gain from this, maybe someone else will find it useful. After all, it's just a matter of adding
the proper routes to the nodes. Say, the network behind cliois 192.168.1.0/24, and
the network behind pan is 192.168.2.0/24, all that's neccessary is to execute two
"route"-commands:
pan root # route add -net 192.168.1.0/24 gw 5.6.7.8
root@clio# route add -net 192.168.2.0/24 gw 1.2.3.4
The routing table will look like this now:
pan root # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
5.6.7.8 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 5.6.7.8 255.255.255.0 UG 0 0 0 ppp0
140.78.104.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo
0.0.0.0 140.78.104.62 0.0.0.0 UG 0 0 0 eth0
root@clio# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
1.2.3.4 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.2.0 1.2.3.4 255.255.255.0 UG 0 0 0 ppp0
140.78.104.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 140.78.104.62 0.0.0.0 UG 0 0 0 eth0
To visualise the configuration:
The layering of data, as travelling over the network:
| Application Data | VPN Layer |
 encrypted data |
| TCP | ||
| IP | ||
| PPP | ||
| GSS |  unencrypted data |
|
| TCP | ||
| IP | ||
| Ethernet |
Do not forget to enable IP-forwarding (echo 1 > /proc/sys/net/ipv4/ip_forward) and probably proxy-ARP (arp -s IP-Addr HWAddr pub) in case you are useing PPP-adresses from the same subnet.
Allthough this solution is fully operational, it also has its downsides. One is the administrative cost: mortal users are not allowed to modify most parts of the configuration. They are not allowed to add network routes, the are not allowed to create ppp-peer files, the are not allowed to pass arbitrary parameters to ppp. The pppd has to be installed with root-permissions, which could be a security problem, should it contain bugs. If installed on a large site, there has to be a central authority keeping track of network assignment.
