Hack 98 Using vtun over SSHConnect two networks together using vtun and a single SSH connection. vtun is a user space tunnel server, allowing entire networks to be tunneled to each other using the tun universal tunnel kernel driver. Using an encrypted tunnel such as vtun allows roaming wireless clients to secure all of their IP traffic using strong encryption. It currently runs under Linux, BSD, and Mac OS X. These examples assume that you are using Linux. The procedure described next will allow a host with a private IP address (10.42.4.6) to bring up a new tunnel interface with a real, live routed IP address (208.201.239.33) that works as expected, as if the private network weren't even there. Do this by bringing up the tunnel, dropping the default route, then adding a new default route via the other end of the tunnel. To begin with, here is the (pretunneled) configuration of the network: root@client:~# ifconfig eth2 As you can see, the local network is 10.42.3.0/26, the IP is 10.42.3.2, and the default gateway is 10.42.3.1. This gateway provides network address translation (NAT) to the Internet. Here's what the path looks like to yahoo.com: root@client:~# traceroute -n yahoo.com In this example, we are connecting to a tunnel server on the Internet at 208.201.239.5. It has two spare live IP addresses (208.201.239.32 and 208.201.239.33) to be used for tunneling. We'll refer to that machine as the server, and our local machine as the client. Now, let's get the tunnel running. To begin with, load the tun driver on both machines: # modprobe tun It is worth noting that the tun driver will sometimes fail if the kernel version on the server and client don't match. For best results, use a recent kernel (and the same version, e.g., 2.4.20) on both machines. On the server machine, save this file to /usr/local/etc/vtund.conf: options {Launch the vtund server like so: root@server:~# vtund -s Now, you'll need a vtund.conf file for the client side. Try this one, again in /usr/local/etc/vtund.conf: options {Finally, run this command on the client: root@client:~# vtund -p home server Presto! You now not only have a tunnel up between client and server, but also have added a new default route via the other end of the tunnel. Take a look at what happens when we traceroute to yahoo.com with the tunnel in place: root@client:~# traceroute -n yahoo.com This means that any server processes running on client are now fully available to the Internet, at IP address 208.201.239.33. This has happened all without making a single change (e.g., port forwarding) on the gateway 10.42.3.1. Here's what the new tunnel interface looks like on the client: root@client:~# ifconfig tun0 and here's the updated routing tablenote that we still need to keep a host route to the tunnel server's IP address via our old default gateway; otherwise, the tunnel traffic couldn't get out: root@client:~# route To bring down the tunnel, simply kill the vtund process on client. This restores all network settings back to their original state. This method works fine, if you trust vtun to use strong encryption and to be free from remote exploits. Personally, I don't think you can be too paranoid when it comes to machines connected to the Internet. To use vtun over SSH (and therefore rely on the strong authentication and encryption that SSH provides), simply forward port 5000 on client to the same port on server. Give this a try: root@client:~# ssh -f -N -c blowfish -C -L5000:localhost:5000 server In order to discourage connections to vtund on port 5000 of the server, add a net filter rule to drop connections from the outside world: root@server:~# iptables -A INPUT -t filter -i eth0 -p tcp --dport 5000 [RETURN] This allows local connections to get through (since they use loopback), and therefore requires an SSH tunnel to server before accepting a connection. As you can see, this can be an extremely handy tool to have around. In addition to giving live IP addresses to machines behind a NAT, you can effectively connect any two networks together if you can obtain a single SSH connection between them (originating from either direction). If your head is swimming from this vtund.conf configuration, or if you're feeling lazy and don't want to figure out what to change when setting up your own client's vtund.conf file, take a look at the automatic vtund.conf generator [Hack #99]. Tips and TricksWhile that should be enough information to get vtund up and running on your system, here are a couple of additional points to keep in mind. The session name (home in the preceding example) must match on the client and the server sides, or you'll get an ambiguous "server disconnected" message. The same goes for the password field in the vtund.conf file on both sides. It must be present and match on both sides, or the connection won't work. If you're having trouble connecting, make sure you're using the same kernel version on both sides, and that the server is up and running (try telnet server 5000 from the client side to verify that the server is happy). Try the direct method first, then get SSH working once you are happy with your vtund.conf settings. If you're still having trouble, check /etc/syslog.conf to see where your auth facility messages are going, and watch that log on both the client and server when trying to connect. It can be tricky getting vtun running the first time, but once it is properly configured, it works like a charm. |
لطفا منتظر باشید ...
