Downloading Files Quickly with aria2

At University, I have been blessed with a 1gb Ethernet connection, which is great for downloading large datasets and ISOs etc. However, I often find that the bandwidth of the server from which I am downloading a file is the limiting factor, meaning I cannot always max out the connection.

After some searching, I came across the tool aria2c, which has quickly become my wget replacement. Aria2 is a cross-platform tool that allows you to download files using multiple connections, allowing you to take full advantage of CDNs and load balancing.

Where you might normally run the command:


the aria2 equivalent is:

aria2c -x4

This tells aria2 to use 4 concurrent connections to download the ISO.

Aria2 supports more than just the http/https protocols — it comes with support for SFTP, BitTorrent and Metalink. Aria2 automatically detects the correct connection type based on the URL scheme. Additionally, aria2 can be controlled using remotely over an API.

As per the documentation, aria2 can be used to download batches of files. By placing a list of URLs in a text file, separated by newline, and then calling aria2c -i urls_filename.txt, aria2 will chomp through and download each entry.

All major platforms are supported, including most flavours of Linux, OS X, Windows and Android.

Under Ubuntu/Debian, aria2 can be installed with:

sudo apt-get install aria2

under CentOS/Fedora/Scientific Linux with:

sudo yum install aria2

or under OS X (using brew) with:

brew install aria2

For other platforms, see the guide listed on the aria2 website.

Quick and Dirty VPN Server with pptpd

I’ve recently found myself wanting to be able to quickly create a VPN server, with minimal client-side setup. Normally, my VPN Server of choice is OpenVPN, but this doesn’t really fill those criteria – server side, you’ve got to generate keyfiles, certificates, config files. This wouldn’t be so bad – but it’s a similar story client-side. If your grandma want’s a VPN connection, then having to send over OpenVPN installers, certificate files and configs isn’t ideal.

Most operating systems have built-in support for a VPN Protocol called “PPTP”, or Point-to-Point Tunneling Protocol, so I decided to investigate. It turns out that minimal effort is required to set up a PPTP server, and virtually NO effort is required on the client side. PPTP is supported by OS X, Windows, Android, iOS natively, and can clients are easily obtainable for Linux and various BSD distributions.

Before I go any further – I’d like to clarify that PPTP is NOT terribly secure. I wouldn’t use it for transferring any particularly sensitive information; I’m using it purely for convenience reasons. I’d recommend it for watching Netflix or Hulu from outside the US, but not for transferring mega secret nuclear launch-codes. Services exist that allow the cracking of MS-CHAPv2, the protocol that PPTP uses for encrypting communications.

OK, now that you know not to use PPTP/MS-CHAPv2 as a security measure, lets move on.

These instructions were tested on Debian 7.0 – but installation aside, should be valid for any distro.

Install PPTPD. This can be done via a simple apt-get install pptpd.

Open up /etc/pptpd.conf in your editor of choice. At the end of the file, add these lines:

localip x.x.x.x
remoteip y.y.y.y-z

where x.x.x.x is the external IP of your server, and remoteip y.y.y.y-z, where y.y.y.y is the first address in the range you wish to assign to your clients, and z is the last octet of the last address you wish to assign to clients. For instance, if I wanted client IPs to lie in the range, I’d enter remoteip You don’t need to do anything special to be able to assign these IPs, it’s all handled for you. Just make sure you use private address space, it’d be rude not to.

You should also append:


to the file, in order to specific the DNS servers you want your clients to use. You can, of course, substitute the with DNS servers of your choice.

Now that the pptpd is configured, we need to allow our server to forward IPv4 traffic. This can be done by editing /etc/sysctl.conf, and uncommenting the line that reads #net.ipv4.ip_forward=1. We then need to reload the sysctl.conf file – this can be done by running sudo sysctl -p.

We also need to configure iptables to perform NAT – this can be done by running iptables -A POSTROUTING -t nat -j SNAT --to-source z.z.z.z, where z.z.z.z is the external IP of your VPS. It’s worth noting that iptables rules aren’t persisted to disk – check out this article to see how to make them survive a reboot.

We’re almost set – all that’s left to do is to create a pptpd user. This is done by editing the file /etc/ppp/chap-secrets. Entries are stored in the form username service password ip – so if I wanted to add a user called bob, with the password bananna and the IP, I’d add the line:

bob pptpd bananna

(Bear in mind that passwords in /etc/ppp/chap-secrets are stored in plaintext.)

Your pptpd VPN server is now configured – all that’s left to do is to run /etc/init.d/pptpd restart to make the changes take effect.

Tunneling OpenVPN Through SSH

I have recently discovered that it is fairly easy to tunnel OpenVPN through SSH. This is useful if you are behind a restrictive firewall that uses SPI to block services rather than plain old port blocking. An SPI firewall is able to distinguish between one packet type and another, without just checking the port that is in use. You can, of course, get a much more in-depth and accurate account of what SPI does/doesn’t do from Wikipedia, however that it’s really the purpose of this post.

You’ll need root access to the OpenVPN Server, as you have to change some of the server config files

So, on to the technical part of the procedure. You need to do the folllowing:

  1. Set the OpenVPN server config file to use TCP rather than UDP. This is done by changing the line proto udp to proto tcp in the server config file (normally located at /etc/openvpn/server.conf).
  2. Set the OpenVPN client config file to use TCP rather than UDP. You can do this by changing the line proto udp to proto tcp-client in the client config file.
  3. Change the OpenVPN client config to connect to localhost rather than the remote server address. This is done by changing the “remote” line of the server to remote localhost 1194
  4. Create an SSH tunnel between the client machine and the OpenVPN Server, and forward from remote:1194 to localhost:1194. This can be done by running the command:
    ssh user@server -L 1194:localhost:1194 on the client machine (assuming you’re running Linux/Unix with the OpenSSH client binary installed)

All being well, after making those config file changes and creating your SSH tunnel, you’ll be able to tunnel OpenVPN through SSH.

It’s not the ideal solution – the is a lot more overhead when running OpenVPN in TCP mode, and even more when tunneling TCP over TCP, which is what you’re doing by using an SSH tunnel with VPN Traffic. However, needs must – and this is one way of getting round an SPI Firewall when SSH connections are allowed

Dedicated to VPS Migration

If you’re reading this, then my blog has successfully been migrated to a different server!

I decided that it didn’t make much sense to have my old dedicated server any more, now that I’ve got a VPS node – so I span up a Debian Instance, and setup nginx, mysql and php-fcgi, and started migrating my sites over. So far, it’s been a great experience – there have been no issues, and I’m pretty sure that the site is much much faster. Just try out the search function!

I’m also hosting the previously mentioned VPS wiki on this machine, and have plenty of resources left to host several more dynamic sites.

I hope to do a quick writeup for the VPS wiki in the near future.

Getting into VPS Hosting…

So, I have taken things a step further. I started off being interested in buying VPS machines – I then turned to low end Dedicated Servers, and now, I’m dabbling in hosting my own VPS machines.

To start off with, I am doing this not for profit. I will not be offering any formal support for my customers, and have negotiated a deal with RapidSwitch, who are providing me with a discount (because I’m not making any money from it). I will be offering OpenVZ VM’s to people on my University course for £5.00/m, with the following spec: 18GB hard disk space, 400MB Ram, 128MB VSwap, and 750GB Bandwidth.

I’ve chosen to use the OpenVZ Web Panel control panel software, as it is easy to use and free.

If this is a successful endeavor, then I may go on to provide commercial VPS’s to customers. Who knows!

You can probably expect some  OpenVZ/CentOS based posts in the not too distant future…



I had to go with SolusVM, due to OWP’s lack of bandwidth tracking. This meant increasing the price by £0.50 to £5.50/m – however, I think the users are probably getting a slightly better experience with the commercial control panel.