I finally had the opportunity to implement this Lifehacker tip last night. It's a great idea and works very well; recommended.

I'll add that I took the opportunity to rationalize my power strips. Now everything that doesn't need to be on all the time—monitor, printer, powered USB hub, etc.—is plugged into a single power strip, which can be switched off to save power (that Apple display, in particular, really sucks it down even when off). Everything network-related, which needs to be up all the time, is plugged into a different power strip or the wall.



My office, now with more desk space

Read More...

I'd been running bind on a local server for some time, and was using that to forward DNS requests through my assorted VPN tunnels; but it never worked properly, and I had to set search domains in /etc/resolv.conf manually on all my boxes. I felt this was stupid. I felt that strongly.

When my router died a few weeks ago, I got another, and of course immediately flashed it with dd-wrt; this time around, however, I noticed the DNSMasq options. dd-wrt can use DNSMasq as an alternative to dhcpd. I looked into it. Suffice it to say, I got my local DNS working perfectly for the first time (after some Googling; the docs weren't terribly helpful to a networking novice like me). Multiple search domains, DNS forwarding, everything. Here's what I did.

I have eight boxes locally—a server, two MacBooks, an Apple TV, and four VMs serving as my Zenoss VPN gateway, torrent server (also a VPN gateway, to another endpoint), CentOS dev box, and Zenoss server. Local domain is "mcb.loc", but I also interact extensively with the "zenoss.loc" domain, resolution requests for which I need forwarded through the Zenoss VPN connection to another DNS server.


First, I set up all my static DHCP leases—the last time I changed my subnet I cursed myself for having my boxes set their own IPs. That's done under the "Services" tab in dd-wrt. Next, I checked "Use DNSMasq for DHCP" and "Unse DNSMasq for DNS" and added my router's IP as "Local DNS", all under the "Setup" tab.
Routing was set up so that appropriate traffic would go through the VPN gateways (see how to do that here and here).

Then it was time for the DNSMasq setup. As I said before, docs were somewhat minimal and geared towards people not me. Several directives needed to be added to the "Additional DNSMasq Options" box under the "Services" tab. First, the easy ones:

local=/mcb.loc/
expand-hosts

These set up my local domain and tell it to treat requests to, for example, "iansmbp" as "iansmbp.mcb.loc". This got me halfway there. DNSMasq adds hostnames defined under the static leases section to DNS automatically, so local DNS was working perfectly. I still needed to add "zenoss.loc" as a search domain and have it forward requests to the remote DNS server. This was pretty difficult to find via Google, at least under the search terms I thought were appropriate at the time, but eventually I got it:

server=/zenoss.loc/10.175.211.10

That forwards all "zenoss.loc" lookups to the IP specified, which is the Zenoss DNS over the VPN.

dhcp-option=15,"zenoss.loc mcb.loc"

That was the part that was hard to find, because it isn't a default DNSMasq option. That sets the search domains for the resolv.conf of DHCP clients.

At this point, I renewed leases on my assorted boxes and was good to go! Way less effort than setting up bind, which is overkill for my needs anyway. I have yet to have an issue with this setup.

Read More...

Bell Canada throttles bittorrent traffic during "peak hours." This means that I'm limited to 30Kb/s evenings and weekends. This is not a situation with which I have been satisfied; besides being inconvenient, I don't much like being pushed around by Bell Canada in violation of our contract. I could have perfectly valid reasons for downloading via bittorrent, by golly, and they shouldn't be able just to shut me down without cause, etc. Plus I couldn't download Farscape fast enough when I was jonesing.

In the end, I figured the simplest solution was to download through a VPN, so Bell couldn't see that the packets were torrenty. I didn't really have any idea how to do this, but I have Google, and that generally gives me an inflated sense of ability, so I set to with a will. Here's what I did (let me also say off the bat that I was successful without too much trouble):

1. Get a VPN endpoint on the Internet somewhere. I'd used VPSLink before with perfectly adequate results, and their cheapest plan is like six bucks a month if you buy a year up front. I did so and installed Hardy. That was that.


2. Set up a torrent server locally. I have been using torrentflux-b4rt as my client for at least a year now, and it works great. In this case, I wanted it running on its own server, so I could just change its gateway to the VPN endpoint and be done with it. I set up a new VM, installed Apache and torrentflux-b4rt, made the downloads directory on my previous server available via NFS, mounted that on the VM, and disabled the original torrentflux instance. I ended up with the same setup as before, only on its own server.


3. Create a point-to-point VPN connection. To connect my torrent server to my VPN endpoint, I set up the simplest of OpenVPN configurations. No trouble there. That example worked without a hitch.


4. Route all traffic from the torrent server through the VPN endpoint. I was working on a bunch of fancy ways to do this when I learned that OpenVPN can already do it for you. I added:
   

   redirect-gateway

   
   to the config file on my client. Once I reconnected, it set up all the routes necessary to direct all traffic through the VPN connection. I tried a traceroute to Google, and the first hop was indeed the VPN endpoint, but of course it stalled there because that box wouldn't do IP forwarding yet.


5. Enable IP forwarding on the VPN endpoint. This was a little trickier than I expected, because the VPS didn't have MASQUERADE support. Luckily, it has a static IP, so I could use SNAT (it was just luck I figured out how to do this. I still don't know what any of this really does):
   

   # echo "1" > /proc/sys/net/ipv4/ip_forward
   # iptables -t nat -A POSTROUTING -o venet0 -j SNAT --to-source 209.59.210.206

   
   A traceroute from the torrent server to Google was now able to complete. And that was that!

Now I don't have any throttling problems. Also, if I connect my laptop to the VPN endpoint using redirect-gateway, I'll be able to watch US content that's blocked in Canada, like the Olympics stuff on NBC. Too bad that ended this weekend.

Read More...

Either the IPsec client I've been using to connect to the Zenoss colo or the VPN server on the other end kills my connection every twenty-five minutes. We've got an OpenVPN server running at the colo as well, and that connection's been much more stable. Since I have multiple boxes here that I'd like to have colo access, I decided to try to connect the two networks semi-permanently, as a fun weekend project. It actually turned out to take around two hours.

1. Set up the VPN connection. This ended up being very, very easy. My nameserver VM (IP: 10.42.1.2) was hardly overtaxed, so I decided to use that as the VPN gateway. First, I installed OpenVPN:
   

   ian@tryphon$ sudo apt-get install openvpn

   
   I already had an OpenVPN config, which I'd been using (via TunnelBlick) to connect to the OpenVPN server at the colo. I dumped that, along with the necessary keys and whatnot, into /etc/openvpn, and fired up the connection:
   

   ian@tryphon$ sudo /etc/init.d/openvpn start zenoss
* Starting virtual private network daemon.
* zenoss (OK)
...done.


   
   Then I verified connectivity by pinging a server at the colo:
   

   ian@tryphon:/etc/openvpn$ ping 10.175.211.10
PING 10.175.211.10 (10.175.211.10) 56(84) bytes of data.
64 bytes from 10.175.211.10: icmp_seq=1 ttl=62 time=52.5 ms
64 bytes from 10.175.211.10: icmp_seq=2 ttl=62 time=48.1 ms

--- 10.175.211.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 48.150/50.338/52.527/2.199 ms

   
   


2. Route colo traffic through the gateway. This was the only tricky part, mostly (I think) because my understanding of IP routing is nonexistent to limited, which is why I thought this would be a fun project in the first place.
   
   I should mention here that the <code>zenoss.conf</code> file I had sets routes appropriately (obviously, or step 1 wouldn't have worked):
   

   ian@tryphon$ netstat -rn
   Kernel IP routing table
   Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
   10.254.0.1      10.254.0.9      255.255.255.255 UGH       0 0          0 tun0
   10.254.0.9      0.0.0.0         255.255.255.255 UH        0 0          0 tun0
   10.175.211.0    10.254.0.9      255.255.255.0   UG        0 0          0 tun0
   10.42.1.0       0.0.0.0         255.255.255.0   U         0 0          0 eth0
   0.0.0.0         10.42.1.1       0.0.0.0         UG        0 0          0 eth0
   

   
   So I just needed to get the rest of the network to use that connection.
   
   First, I added a static route on my router, sending 10.175.211.0/24 traffic to my VPN box (user interfaces will vary, of course; mine's a Linksys with the default firmware. dd-wrt won't work on my router, which causes me no end of annoyance, but that's another story):
   

   

   
   That gets me to the box but not out through the VPN. Next I needed to enable IP forwarding on the VPN box:
   

   ian@tryphon$ sudo su -
root@tryphon# echo 1 > /proc/sys/net/ipv4/ip_forward
root@tryphon# echo "net.ipv4.ip_forward=1" > /etc/sysctl.conf
root@tryphon# sysctl net.ipv4.ip_forward=1


   
   I don't know if the first line is necessary given the sysctl stuff, but The Web seemed to think it was the way to go, and it didn't break anything. People who understand this stuff better may educate me if they so wish.
   
   I got to this point, and it wasn't working. I don't fully understand why, but comments from a co-worker led me to investigate how to tell the box to which interface it should forward things. Googling around led me to try installing iptables and adding a rule:
   

   ian@tryphon$ sudo apt-get install iptables
...
ian@tryphon$ sudo /sbin/iptables -A FORWARD -i tun0 -j ACCEPT

   
   This worked! From anywhere on my network, I was able to ping the colo. Hooray! In order to get it to work on boot, I added the above command to /etc/rc.local
   


3. Use the remote nameserver. This was simple. Since I'm already running BIND locally, I just added a forwarder to /etc/bind/named.conf.local:
   

   zone "zenoss.loc" IN {
type forward;
forwarders {10.175.211.10;};
};

   
   Restarted BIND, and all was well.
   
   Oh, I had to add zenoss.loc to the search line of /etc/resolv.conf. I have yet to find a good way around that, though I'm certain one exists. I may move DHCP from my router to that box, so I can specify more search domains.
   

Read More...

Bell Canada locks their DSL modems, making it impossible to put them in bridge mode. Also, their port forwarding stuff (or "Application Support") doesn't really work. At least, I couldn't get it to work. All I wanted was to be able to get into my private Subversion repository from the outside, but try as I might, forwarding the appropriate ports to my server had no effect.

I went to Future World in hopes of purchasing a third-party DSL modem, but was informed by an employee that DSL modems were always ISP-specific and completely unavailable from other sources. Despite my certainty that this claim was utterly without merit, all the other stores were closed, so I didn't have much choice other than to mess with the modem I already had.

Eventually I hit upon a solution that worked for reasons I don't fully understand: separate subnets. I set the modem to be 10.42.0.1 and limited its DHCP range to a single address, so that the router would be the only thing getting its IP from the modem (the modem's "DMZPlus" feature requires that its target receive an IP via DHCP). I then set my Linksys router to get its Internet connection via "Automatic Configuration - DHCP", then set its IP to be 10.42.1.1 (note the different subnet). Finally, I reconfigured the DSL modem, putting the Linksys router in the DMZ. The Linksys pulled an IP from the ISP, all my local boxes were in the 10.42.1.0 network, the Linksys did all the proper port forwarding, and everything worked swimmingly, though I really don't understand how.

Unfortunately, Bell Canada kind of sucks. Turns out they're too expensive and they throttle torrents. I may switch to Teksavvy in the near future, which, since you buy your own modem, will make this solution irrelevant. But I half-learned something new about networking, so it isn't a total loss.

Read More...