“UbuntuHelp:SSH VPN”的版本间的差异
来自Ubuntu中文
小 |
小 |
||
| 第1行： | 第1行： | ||
| − | {{From|https://help.ubuntu.com/community/ | + | {{From|https://help.ubuntu.com/community/SSH_VPN}} |
| − | {{Languages|UbuntuHelp: | + | {{Languages|UbuntuHelp:SSH_VPN}} |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | This page details how to set up an SSH VPN. | |
| − | + | NB: You MUST be using OpenSSH version 4.3 or better to do this-- this means that this will NOT work with Ubuntu 6.06 or less's default packages -- it will only work with the recently released Edgy, or with a locally compiled SSH version 4.3 or better. | |
| − | + | ||
| − | + | == Introduction == | |
| − | + | ||
| − | + | OpenSSH version 4.3 introduced a new feature: the ability to create on-the-fly "Virtual Private Networks" via the tunnel driver, or "tun" driver. This feature allows you to create a network interface that bridges two physically disparate network segments. A quick diagram: | |
| − | + | <pre><nowiki> | |
| − | + | +---------------+ OpenSSH 4.3 +---------------+ | |
| − | + | | Machine A | tun0 -- Tunnel Interface -- tun0 | Machine B | | |
| − | + | | Has a tunnel | <------------------------------->| Has a tunnel | | |
| − | + | | and ethernet | 10.0.0.100 10.0.0.200 | and ethernet | | |
| − | + | +-------+-------+ point to point connection +-------+-------+ | |
| − | + | eth0 | creates a bridge | eth0 | |
| − | + | *0.0.100 | that plugs machine B | 192.168.0.100 | |
| − | + | port 22 | into network A | | |
| + | forwarded | | | ||
| + | here | | | ||
| + | +-------+-------+ +-~-~-~-~-~-~-~-+ +-------+-------+ | ||
| + | | Network A | | | | Network B | | ||
| + | | 10.0.0.1/24 | 1.2.3.4 | The Internet | | 192.168.0.1/24| | ||
| + | | Has internet |<-------->| |<----->| Has internet | | ||
| + | | NAT gateway | Routable | | | NAT gateway | | ||
| + | +---------------+ Address +-~-~-~-~-~-~-~-+ +---------------+ | ||
| + | </nowiki></pre> | ||
| + | What does this diagram represent? In this case, we have two machines, machine A and machine B. Machine A is connected to network A via ethernet, and machine B is connected to network B via ethernet. Machine A's IP address on Network A is 10.0.0.100, and Machine B's IP address on Network B is 192.168.0.100. Each network has an internet NAT gateway to allow for internet connectivity. | ||
| − | + | In this example, we are connecting machine B to network A via an ssh tunnel interface. Machine A already has an IP addresses on network A: its ethernet interface address (10.0.0.100). Machine B must also be allocated one IP address on network A: its tunnel interface address (10.0.0.200). | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Also, Machine B must have some access to the ssh server on Machine A; the most direct way for this to happen is that Machine A must have either a globally routable address itself; or (as is diagramed), port 22 (or whatever port ssh is running on) must be forwarded to Machine A by the NAT system. There are other ways to allow Machine B access to Machine A's ssh server, but I will leave these as an exercise for the reader. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Once the tunnel is set up, Machine B will be able to directly access Network A. In other words, Machine B would be "plugged in" to Network A via its tunnel with Machine A. Of couse, the devil's in the details: how do you set all this up? | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | == IP Forwarding == | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Of course the first and most obvious thing is that you'd better have IP forwarding enabled. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | < | + | on Machine A (and it wouldn't hurt on B), execute: |
| − | < | + | <pre><nowiki> |
| − | + | # echo 1 > /proc/sys/net/ipv4/ip_forward | |
| − | + | </nowiki></pre> | |
| − | + | (# is the root prompt, not a character to type) | |
| − | < | + | |
| − | < | + | |
| − | + | ||
| − | + | == The SSH Command == | |
| − | + | The actual SSH command that gets the ball rolling is quite simple: | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | on Machine B, execute: | |
| − | + | <pre><nowiki> | |
| − | + | # ssh -w 0:0 1.2.3.4 | |
| − | + | </nowiki></pre> | |
| − | + | ||
| − | < | + | |
| − | + | ||
| − | + | ||
| − | < | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | / | + | |
| − | </ | + | |
| + | This command creates a tunnel interface named tun0 on both the client and server systems. In keeping with our diagram above, the server is Machine A (with a globally routable IP address of 1.2.3.4), and the client is Machine B. | ||
| − | + | Note that you will more than likely need to be root on both systems in order for ssh to be able to create these interfaces. Additionally, you will need the following settings in your sshd_config on Machine A (the server): | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | </ | + | <pre><nowiki> |
| + | PermitRootLogin yes | ||
| + | PermitTunnel yes | ||
| + | </nowiki></pre> | ||
| − | + | If no errors occur, then you should be able to see a tun0 interface on both systems as existing, but unconfigured: | |
| − | < | + | Machine A: |
| − | + | <pre><nowiki> | |
| + | # ifconfig tun0 | ||
| + | tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 | ||
| + | POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1 | ||
| + | RX packets:0 errors:0 dropped:0 overruns:0 frame:0 | ||
| + | TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 | ||
| + | collisions:0 txqueuelen:500 | ||
| + | RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) | ||
| + | </nowiki></pre> | ||
| − | </ | + | Machine B: |
| + | <pre><nowiki> | ||
| + | # ifconfig tun0 | ||
| + | tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 | ||
| + | POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1 | ||
| + | RX packets:0 errors:0 dropped:0 overruns:0 frame:0 | ||
| + | TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 | ||
| + | collisions:0 txqueuelen:500 | ||
| + | RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) | ||
| + | </nowiki></pre> | ||
| − | + | == Configuring the Interfaces == | |
| + | At this point, we've got interfaces, but they're unconfigured. All we need to do to configure them is give them each an IP address: | ||
| − | + | Machine A: | |
| − | < | + | <pre><nowiki> |
| − | < | + | # ifconfig tun0 10.0.0.100 pointopoint 10.0.0.200 |
| − | + | </nowiki></pre> | |
| − | + | ||
| − | + | ||
| − | < | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | < | + | Machine B: |
| − | < | + | <pre><nowiki> |
| + | # ifconfig tun0 10.0.0.200 pointopoint 10.0.0.100 | ||
| + | </nowiki></pre> | ||
| − | + | Once each interface is configured, we've essentially got the VPN set up; it's just minor details from here. In fact, we can now ping from Machine B to Machine A: | |
| − | < | + | Machine B: |
| + | <pre><nowiki> | ||
| + | # ping 10.0.0.100 | ||
| + | PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data. | ||
| + | 64 bytes from 10.0.0.100: icmp_seq=1 ttl=64 time=74.8 ms | ||
| + | 64 bytes from 10.0.0.100: icmp_seq=2 ttl=64 time=73.6 ms | ||
| + | 64 bytes from 10.0.0.100: icmp_seq=3 ttl=64 time=74.3 ms | ||
| + | --- 10.0.0.100 ping statistics --- | ||
| + | 3 packets transmitted, 3 received, 0% packet loss, time 2001ms | ||
| + | rtt min/avg/max/mdev = 73.649/74.278/74.880/0.549 ms | ||
| + | </nowiki></pre> | ||
| − | + | And of course we can also ping from Machine A back to Machine B: | |
| − | + | Machine A: | |
| − | + | <pre><nowiki> | |
| − | + | # ping 10.0.0.200 | |
| − | + | PING 10.0.0.200 (10.0.0.200) 56(84) bytes of data. | |
| − | + | 64 bytes from 10.0.0.200: icmp_seq=1 ttl=64 time=75.2 ms | |
| − | + | 64 bytes from 10.0.0.200: icmp_seq=2 ttl=64 time=74.0 ms | |
| − | + | 64 bytes from 10.0.0.200: icmp_seq=3 ttl=64 time=74.0 ms | |
| + | --- 10.0.0.200 ping statistics --- | ||
| + | 3 packets transmitted, 3 received, 0% packet loss, time 2002ms | ||
| + | rtt min/avg/max/mdev = 74.029/74.424/75.208/0.554 ms | ||
| + | </nowiki></pre> | ||
| − | </ | + | == Plugging Into the Network == |
| − | </ | + | |
| − | </ | + | At this point, we've created the actual link that allows Machine B to be plugged into Network A, but we haven't set up any routing information to actually get packets back and forth between Machine B and Network A. The first thing we need to do is to tell Machine B about Network A: |
| + | |||
| + | Machine B: | ||
| + | <pre><nowiki> | ||
| + | # route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.200 tun0 | ||
| + | </nowiki></pre> | ||
| + | |||
| + | This allows us to send packets from Machine B to any IP address on Network A, via Machine A. However, to ensure that packets have a route back to Machine B, we need to set some things up on Machine A. | ||
| + | |||
| + | Machine A: | ||
| + | <pre><nowiki> | ||
| + | # arp -sD 10.0.0.200 eth0 pub | ||
| + | </nowiki></pre> | ||
| + | |||
| + | This ensures that other machines plugged into Network A will know to send packets destined for 10.0.0.200 to Machine A (so that it can forward them back to Machine B). | ||
| + | |||
| + | At this point, we do have two way communication betweek Network A and Machine B. Therefore, we can ping another machine on Network A from Machine B: | ||
| + | |||
| + | Machine B: | ||
| + | <pre><nowiki> | ||
| + | # ping 10.0.0.123 | ||
| + | PING 10.0.0.123 (10.0.0.123) 56(84) bytes of data. | ||
| + | 64 bytes from 10.0.0.123: icmp_seq=1 ttl=127 time=74.3 ms | ||
| + | 64 bytes from 10.0.0.123: icmp_seq=2 ttl=127 time=74.3 ms | ||
| + | 64 bytes from 10.0.0.123: icmp_seq=3 ttl=127 time=74.5 ms | ||
| + | |||
| + | --- 10.0.0.123 ping statistics --- | ||
| + | 3 packets transmitted, 3 received, 0% packet loss, time 2001ms | ||
| + | rtt min/avg/max/mdev = 74.307/74.416/74.577/0.335 ms | ||
| + | </nowiki></pre> | ||
| + | |||
| + | == Expanding the scope of the VPN == | ||
| + | |||
| + | At this point, we have successfully plugged Machine B into Network A, and Machine B can access Network A's resources and vice versa. However, what if we want to expand the scope of this VPN-- what if we want to pretend that Machine B's only network connection is through network A? | ||
| + | |||
| + | If we did this, then all packets coming from or going to Machine B would route through Network A; this would complete Machine B's integration into the private network. So, how do we do this? | ||
| + | |||
| + | Simple: we just switch Machine B's default gateway. | ||
| + | |||
| + | However, first, we must create a host-based route to Machine A's globally routable IP address; all packets except for the packets that actually create the link must go through the tunnel, but of course the packets that create the tunnel cannot go through the tunnel. | ||
| + | |||
| + | Machine B: | ||
| + | <pre><nowiki> | ||
| + | # route add 1.2.3.4 gw 192.168.0.1 eth0 | ||
| + | </nowiki></pre> | ||
| + | |||
| + | In this case, 192.168.0.1 is Machine B's current default gateway; it is the gateway on Network B that provides internet connectivity. Before we switch Machine B's default gateway away from Network B, we must set up this explicit route so that tunnel packets will continue to flow. | ||
| + | |||
| + | After that route is in place, we can switch Machine B's default gateway: | ||
| + | |||
| + | Machine B: | ||
| + | <pre><nowiki> | ||
| + | # route add default gw 10.0.0.1 tun0 | ||
| + | # route del default gw 192.168.0.1 eth0 | ||
| + | </nowiki></pre> | ||
| + | |||
| + | In this case, again, 192.168.0.1 is Network B's default gateway, and 10.0.0.1 is Network A's default gateway. Since Machine B is now connected to Network A, we are telling it to use Network A's default gateway instead of its usual default gateway on Network B. At this point, the conversion is complete, and Machine B is now completely on Network A and has all the resources available to Network A, through the SSH tunnel. We can verify this by looking at the output of a tracepath: | ||
| + | |||
| + | Machine B: | ||
| + | <pre><nowiki> | ||
| + | # tracepath example.com | ||
| + | 1: 10.0.0.200 (10.0.0.200) 0.291ms pmtu 1500 | ||
| + | 1: 10.0.0.100 (10.0.0.100) 168.589ms | ||
| + | 2: 10.0.0.1 (10.0.0.1) asymm 3 87.542ms | ||
| + | 3: 1.2.3.4 (1.2.3.4) 157.360ms | ||
| + | </nowiki></pre> | ||
| + | |||
| + | == Automating it all with ifup/down == | ||
| + | |||
| + | At this point, we have successfully created a virtual private network using SSH 4.3's tunnels. Can we automate this process with ifup/down? The answer is: yes! | ||
| + | |||
| + | Machine A: | ||
| + | <pre><nowiki> | ||
| + | iface tun0 inet static | ||
| + | pre-up sleep 5 | ||
| + | address 10.0.0.100 | ||
| + | pointopoint 10.0.0.200 | ||
| + | netmask 255.255.255.0 | ||
| + | up arp -sD 10.0.0.200 eth0 pub | ||
| + | </nowiki></pre> | ||
| + | |||
| + | Machine B: | ||
| + | <pre><nowiki> | ||
| + | iface tun0 inet static | ||
| + | pre-up ssh -f -w 0:0 1.2.3.4 'ifdown tun0; ifup tun0' | ||
| + | pre-up sleep 5 | ||
| + | address 10.0.0.200 | ||
| + | pointopoint 10.0.0.100 | ||
| + | netmask 255.255.255.0 | ||
| + | up route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.200 tun0 | ||
| + | up route add 1.2.3.4 gw 192.168.0.1 eth0 | ||
| + | up route add default gw 10.0.0.1 tun0 | ||
| + | up route del default gw 192.168.0.1 eth0 | ||
| + | down route add default gw 192.168.0.1 eth0 | ||
| + | down route del default gw 10.0.0.1 tun0 | ||
| + | down route del -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.200 tun0 | ||
| + | down route del 1.2.3.4 gw 192.168.0.1 eth0 | ||
| + | </nowiki></pre> | ||
| + | |||
| + | These example /etc/network/interface snippets show how you would, on Machine B, simply have to execute: | ||
| + | |||
| + | Machine B: | ||
| + | <pre><nowiki> | ||
| + | # ifup tun0 | ||
| + | </nowiki></pre> | ||
| + | |||
| + | And the system would automatically make the ssh connection, set up the tunnel, and turn on the VPN. Additionally, the ifdown command can be used to put the routes back to normal, or turn off the VPN. | ||
| + | |||
| + | Note that the sleep commands in the snippet are there to allow ssh time to set the tunnel interface up, as it will not be instantaneous. | ||
| + | |||
| + | == Where do I go from here? == | ||
| + | |||
| + | There are many other possible ways to use SSH 4.3's tunnels besides creating a VPN to connect machine B to network A. For example, you could connect machine B to network A, and then route back on machine A to network B, creating a sort-of reverse VPN. Or you could connect machine B to network A, and then redirect traffic from network A to machine B to another system on network B. The possibilities are only limited by the amount of root access you have. | ||
| + | |||
| + | ---- | ||
| + | [[category:CategoryDocumentation]] | ||
[[category:UbuntuHelp]] | [[category:UbuntuHelp]] | ||
2007年5月24日 (四) 14:49的版本
 |
点击翻译: |
English |
This page details how to set up an SSH VPN.
NB: You MUST be using OpenSSH version 4.3 or better to do this-- this means that this will NOT work with Ubuntu 6.06 or less's default packages -- it will only work with the recently released Edgy, or with a locally compiled SSH version 4.3 or better.
目录
Introduction
OpenSSH version 4.3 introduced a new feature: the ability to create on-the-fly "Virtual Private Networks" via the tunnel driver, or "tun" driver. This feature allows you to create a network interface that bridges two physically disparate network segments. A quick diagram:
+---------------+ OpenSSH 4.3 +---------------+ | Machine A | tun0 -- Tunnel Interface -- tun0 | Machine B | | Has a tunnel | <------------------------------->| Has a tunnel | | and ethernet | 10.0.0.100 10.0.0.200 | and ethernet | +-------+-------+ point to point connection +-------+-------+ eth0 | creates a bridge | eth0 *0.0.100 | that plugs machine B | 192.168.0.100 port 22 | into network A | forwarded | | here | | +-------+-------+ +-~-~-~-~-~-~-~-+ +-------+-------+ | Network A | | | | Network B | | 10.0.0.1/24 | 1.2.3.4 | The Internet | | 192.168.0.1/24| | Has internet |<-------->| |<----->| Has internet | | NAT gateway | Routable | | | NAT gateway | +---------------+ Address +-~-~-~-~-~-~-~-+ +---------------+
What does this diagram represent? In this case, we have two machines, machine A and machine B. Machine A is connected to network A via ethernet, and machine B is connected to network B via ethernet. Machine A's IP address on Network A is 10.0.0.100, and Machine B's IP address on Network B is 192.168.0.100. Each network has an internet NAT gateway to allow for internet connectivity.
In this example, we are connecting machine B to network A via an ssh tunnel interface. Machine A already has an IP addresses on network A: its ethernet interface address (10.0.0.100). Machine B must also be allocated one IP address on network A: its tunnel interface address (10.0.0.200).
Also, Machine B must have some access to the ssh server on Machine A; the most direct way for this to happen is that Machine A must have either a globally routable address itself; or (as is diagramed), port 22 (or whatever port ssh is running on) must be forwarded to Machine A by the NAT system. There are other ways to allow Machine B access to Machine A's ssh server, but I will leave these as an exercise for the reader.
Once the tunnel is set up, Machine B will be able to directly access Network A. In other words, Machine B would be "plugged in" to Network A via its tunnel with Machine A. Of couse, the devil's in the details: how do you set all this up?
IP Forwarding
Of course the first and most obvious thing is that you'd better have IP forwarding enabled.
on Machine A (and it wouldn't hurt on B), execute:
# echo 1 > /proc/sys/net/ipv4/ip_forward
(# is the root prompt, not a character to type)
The SSH Command
The actual SSH command that gets the ball rolling is quite simple:
on Machine B, execute:
# ssh -w 0:0 1.2.3.4
This command creates a tunnel interface named tun0 on both the client and server systems. In keeping with our diagram above, the server is Machine A (with a globally routable IP address of 1.2.3.4), and the client is Machine B.
Note that you will more than likely need to be root on both systems in order for ssh to be able to create these interfaces. Additionally, you will need the following settings in your sshd_config on Machine A (the server):
PermitRootLogin yes PermitTunnel yes
If no errors occur, then you should be able to see a tun0 interface on both systems as existing, but unconfigured: Machine A:
# ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Machine B:
# ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Configuring the Interfaces
At this point, we've got interfaces, but they're unconfigured. All we need to do to configure them is give them each an IP address:
Machine A:
# ifconfig tun0 10.0.0.100 pointopoint 10.0.0.200
Machine B:
# ifconfig tun0 10.0.0.200 pointopoint 10.0.0.100
Once each interface is configured, we've essentially got the VPN set up; it's just minor details from here. In fact, we can now ping from Machine B to Machine A:
Machine B:
# ping 10.0.0.100 PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data. 64 bytes from 10.0.0.100: icmp_seq=1 ttl=64 time=74.8 ms 64 bytes from 10.0.0.100: icmp_seq=2 ttl=64 time=73.6 ms 64 bytes from 10.0.0.100: icmp_seq=3 ttl=64 time=74.3 ms --- 10.0.0.100 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 73.649/74.278/74.880/0.549 ms
And of course we can also ping from Machine A back to Machine B:
Machine A:
# ping 10.0.0.200 PING 10.0.0.200 (10.0.0.200) 56(84) bytes of data. 64 bytes from 10.0.0.200: icmp_seq=1 ttl=64 time=75.2 ms 64 bytes from 10.0.0.200: icmp_seq=2 ttl=64 time=74.0 ms 64 bytes from 10.0.0.200: icmp_seq=3 ttl=64 time=74.0 ms --- 10.0.0.200 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 74.029/74.424/75.208/0.554 ms
Plugging Into the Network
At this point, we've created the actual link that allows Machine B to be plugged into Network A, but we haven't set up any routing information to actually get packets back and forth between Machine B and Network A. The first thing we need to do is to tell Machine B about Network A:
Machine B:
# route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.200 tun0
This allows us to send packets from Machine B to any IP address on Network A, via Machine A. However, to ensure that packets have a route back to Machine B, we need to set some things up on Machine A.
Machine A:
# arp -sD 10.0.0.200 eth0 pub
This ensures that other machines plugged into Network A will know to send packets destined for 10.0.0.200 to Machine A (so that it can forward them back to Machine B).
At this point, we do have two way communication betweek Network A and Machine B. Therefore, we can ping another machine on Network A from Machine B:
Machine B:
# ping 10.0.0.123 PING 10.0.0.123 (10.0.0.123) 56(84) bytes of data. 64 bytes from 10.0.0.123: icmp_seq=1 ttl=127 time=74.3 ms 64 bytes from 10.0.0.123: icmp_seq=2 ttl=127 time=74.3 ms 64 bytes from 10.0.0.123: icmp_seq=3 ttl=127 time=74.5 ms --- 10.0.0.123 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 74.307/74.416/74.577/0.335 ms
Expanding the scope of the VPN
At this point, we have successfully plugged Machine B into Network A, and Machine B can access Network A's resources and vice versa. However, what if we want to expand the scope of this VPN-- what if we want to pretend that Machine B's only network connection is through network A?
If we did this, then all packets coming from or going to Machine B would route through Network A; this would complete Machine B's integration into the private network. So, how do we do this?
Simple: we just switch Machine B's default gateway.
However, first, we must create a host-based route to Machine A's globally routable IP address; all packets except for the packets that actually create the link must go through the tunnel, but of course the packets that create the tunnel cannot go through the tunnel.
Machine B:
# route add 1.2.3.4 gw 192.168.0.1 eth0
In this case, 192.168.0.1 is Machine B's current default gateway; it is the gateway on Network B that provides internet connectivity. Before we switch Machine B's default gateway away from Network B, we must set up this explicit route so that tunnel packets will continue to flow.
After that route is in place, we can switch Machine B's default gateway:
Machine B:
# route add default gw 10.0.0.1 tun0 # route del default gw 192.168.0.1 eth0
In this case, again, 192.168.0.1 is Network B's default gateway, and 10.0.0.1 is Network A's default gateway. Since Machine B is now connected to Network A, we are telling it to use Network A's default gateway instead of its usual default gateway on Network B. At this point, the conversion is complete, and Machine B is now completely on Network A and has all the resources available to Network A, through the SSH tunnel. We can verify this by looking at the output of a tracepath:
Machine B:
# tracepath example.com 1: 10.0.0.200 (10.0.0.200) 0.291ms pmtu 1500 1: 10.0.0.100 (10.0.0.100) 168.589ms 2: 10.0.0.1 (10.0.0.1) asymm 3 87.542ms 3: 1.2.3.4 (1.2.3.4) 157.360ms
Automating it all with ifup/down
At this point, we have successfully created a virtual private network using SSH 4.3's tunnels. Can we automate this process with ifup/down? The answer is: yes!
Machine A:
iface tun0 inet static pre-up sleep 5 address 10.0.0.100 pointopoint 10.0.0.200 netmask 255.255.255.0 up arp -sD 10.0.0.200 eth0 pub
Machine B:
iface tun0 inet static pre-up ssh -f -w 0:0 1.2.3.4 'ifdown tun0; ifup tun0' pre-up sleep 5 address 10.0.0.200 pointopoint 10.0.0.100 netmask 255.255.255.0 up route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.200 tun0 up route add 1.2.3.4 gw 192.168.0.1 eth0 up route add default gw 10.0.0.1 tun0 up route del default gw 192.168.0.1 eth0 down route add default gw 192.168.0.1 eth0 down route del default gw 10.0.0.1 tun0 down route del -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.200 tun0 down route del 1.2.3.4 gw 192.168.0.1 eth0
These example /etc/network/interface snippets show how you would, on Machine B, simply have to execute:
Machine B:
# ifup tun0
And the system would automatically make the ssh connection, set up the tunnel, and turn on the VPN. Additionally, the ifdown command can be used to put the routes back to normal, or turn off the VPN.
Note that the sleep commands in the snippet are there to allow ssh time to set the tunnel interface up, as it will not be instantaneous.
Where do I go from here?
There are many other possible ways to use SSH 4.3's tunnels besides creating a VPN to connect machine B to network A. For example, you could connect machine B to network A, and then route back on machine A to network B, creating a sort-of reverse VPN. Or you could connect machine B to network A, and then redirect traffic from network A to machine B to another system on network B. The possibilities are only limited by the amount of root access you have.
