Download Wireless-Hacks-100-strength-tips 4547KB
Transcript
tunnel server's IP address via our old default gateway; otherwise, the tunnel traffic couldn't get out: root@client:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 208.201.239.5 10.42.3.1 255.255.255.255 UGH 0 0 0 eth2 208.201.239.32 * 255.255.255.255 UH 0 0 0 tun0 10.42.3.0 * 255.255.255.192 U 0 0 0 eth2 10.42.4.0 * 255.255.255.192 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default 208.201.239.32 0.0.0.0 UG 0 0 0 tun0 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 root@client:~# vtund -p home localhost root@client:~# traceroute -n yahoo.com traceroute to yahoo.com (64.58.79.230), 30 hops max, 40 byte packets 1 208.201.239.32 24.715 ms 31.713 ms 29.519 ms 2 208.201.239.1 28.389 ms 36.247 ms 28.879 ms 3 208.201.224.194 48.777 ms 28.602 ms 44.024 ms 4 208.201.224.5 38.788 ms 35.608 ms 35.72 ms 5 206.24.221.217 37.729 ms 38.821 ms 43.489 ms 6 206.24.210.62 39.577 ms 43.784 ms 34.711 ms 7 206.24.226.103 110.761 ms 111.246 ms 117.15 ms 8 206.24.238.57 112.569 ms 113.2 ms 111.773 ms 9 206.24.238.26 111.466 ms 123.051 ms 118.58 ms 10 216.109.66.132 113.79 ms 119.143 ms 109.934 ms 11 216.33.98.19 111.948 ms 117.959 ms 122.269 ms 12 216.35.210.126 113.472 ms 111.129 ms 118.079 ms 13 64.58.77.41 110.923 ms 110.733 ms 115.22 ms 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] -j DROP 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 Tricks While 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. Page 271