With the ease of use though, there are some downfalls. PPTP is known to be less secure than other VPN’s such as OpenVPN and IPSEC, but for most uses it should be fine. One advantage over my hamachi VPN is that you will end up with an IP on the remote LAN (instead of the 5.0.0.0/8 address you have from hamachi), meaning you don’t need to do any routing tweaks.

First, set up the server:

apt-get install pptpd

That’s it! Now, to configure, you just need to edit 2 files:

/etc/pptpd.conf
Just add 2 lines to the bottom of the file, for the internal IP address of the server, and a range of IP’s which the remote connections will use.
localip 10.1.0.50
remoteip 10.1.0.90-99

The comments at the bottom of the file show some other ways of assigning ranges of IP’s in the remoteip section.

Finally, to add a user, edit /etc/ppp/chap-secrets and add a line for a remote user in the format:

username pptpd password *

To limit connections from specific hosts, use them instead of the * at the end.

To set up the connection on a windows XP client, do the following (from Control Panel):

Network Connections
Create a New Connection
Next
Connect to the network at my workplace
Virtual Private Network connection
Enter your connection name
Do not dial the initial connection
Enter the IP of your server

Then run the connection with the username and password you entered into /etc/ppp/chap-secrets

By default this will route all your traffic (including normal web browsing) through the tunnel. If you don’t want this, go to the connection properties, then the networking tab. Choose TCP/IP properties, and click ‘Advanced’, then finally untick the ‘Use default gateway on remote network’ tickbox.

That should be all you need.

Soon, I’ll give OpenVPN a try, and try to write up a nice guide here.

Most of the information above came from other sites, and by googling. If anyone knows of a better or more secure way of using PPTP then please post comments below.

I’ll also give instructions for using screen to keep downloads going when you logout of the machine.

1, Install the dependancies and other useful packages:

# sudo apt-get install python-wxgtk2.6 python-twisted python-crypto python-psyco python-zopeinterface screen

2, Get the bittorrent .deb file

# wget http://download.bittorrent.com/dl/bittorrent_5.0.8_python2.4.deb
# dpkg -i bittorrent_5.0.8_python2.4.deb

3, Download torrents!

You’ve now got a command line, and curses interface for bittorrent installed. To download a file, run:

# bittorrent-curses http://path/to/file.torrent
(you can also use local paths for torrent files).

To use the command line interface:

# bittorrent-console http://path/to/file.torrent

If you want to leave a file downloading while you’re logged out, use screen. Simply type screen before your preferred command above, ie:

# screen bittorrent-curses http://path/to/file.torrent

To detach from the screen, press “Ctrl+A”, then “D”, and you will be returned to the shell. To re-attach to the screen, run “screen -r”

Bittorrent downloads will be stored in “~/Bittorrent Downloads” when they are complete. While they are being downloaded, they will be in “~/.bittorrent/incomplete/”

Packages for different distributions can be found here, along with source code.

This is very easy to get in all distributions, and it’s one of the first things I do on new installs.

The file you need to edit is ~/.bashrc, and if you want it to apply to all new users, /etc/skel/.bashrc.

Simply add the following lines to the bottom of the file:

//////

eval `dircolors -b`
alias ls=’ls –color=auto’

if [ "`id -u`" -eq 0 ]; then
PS1=’\[\033[01;31m\]\h \[\033[01;34m\]\w \$ \[\033[00m\]‘
else
PS1=’\[\033[01;32m\]\u@\h \[\033[01;34m\]\w \$ \[\033[00m\]‘
fi

//////

This will give you a light green prompt for standard users, and red for root. To use different colours, change the numbers in the [01;32m] sections. You will need to logout and login again to see the changes.

Personally, I prefer to use the stock debian kernel because it supports most hardware and makes upgrading through apt easier. Occasionally though, I like to test the newest kernel releases, and here’s how I do it.

1, Install necessary tools:

# apt-get install kernel-package ncurses-dev bzip2 module-init-tools initrd-tools procps fakeroot

2, Download the latest kernel source:

# cd /usr/src
# wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.1.tar.bz2
# tar -xjvf linux-2.6.22.1.tar.bz2
# cd linux-2.6.22.1

3, Unzip any extra patches and apply them:

# bzip2 -dc patch-xxx.bz2 | patch -p1

5, Configure the kernel.

a, Using the current config as a base:

# cp /boot/config-x.x.x /usr/src/linux-2.6.22.1/.config
# make oldconfig
[ answer all the questions]

b, Using the menu interface (you can do the cp line above to use the old config as a base but make changes):

# make menuconfig

If you have multiple processors/cores, you can speed up the compile by utilising them all (this is similar to the -j flag when compiling the non debian way). To find out the number of cores you have, run:

# grep -c ‘^processor’ /proc/cpuinfo

Then to make sure all cores are used:

# export CONCURRENCY_LEVEL=4
replace 4 with the number of processors.

6, Compile and install:

# make-kpkg clean
# time fakeroot make-kpkg –initrd –revision=1 –append-to-version=.kris kernel-image

This will usually take between 5 minutes and over an hour, depending on how many modules there are to compile, and how fast your hardware is.

Once this has finished, you will be left with a .deb file which you can install using dpkg:

# dpkg -i linux-image*.deb

Because of the –initrd flag earlier, the initrd image will be created when you install the kernel. This command will also update grub, so all you need to do to use your new kernel is reboot.

Parts of this guide (the chroot mainly) are taken from a longer guide at howtoforge.

Lines in italic are to be entered into the shell.

apt-get update
apt-get install bind9
/etc/init.d/bind9 stop
vim /etc/default/bind9

Change:
OPTIONS=”-u bind”
To:
OPTIONS=”-u bind -t /var/lib/named”

vim /etc/bind/named.conf.options

Change the ‘forwarders’ line to the DNS of your ISP
forwarders { x.x.x.x; };

mkdir -p /var/lib/named/etc
mkdir /var/lib/named/dev
mkdir -p /var/lib/named/var/cache/bind
mkdir -p /var/lib/named/var/run/bind/run
mv /etc/bind /var/lib/named/etc
ln -s /var/lib/named/etc/bind /etc/bind
mknod /var/lib/named/dev/null c 1 3
mknod /var/lib/named/dev/random c 1 8
chmod 666 /var/lib/named/dev/*
chown -R bind:bind /var/lib/named/var/*
chown -R bind:bind /var/lib/named/etc/bind
vim /etc/init.d/syslogd

Change:
SYSLOGD=”"
To:
SYSLOGD=”-a /var/lib/named/dev/log”

echo “nameserver 127.0.0.1 > /etc/resolv.conf

/etc/init.d/sysklogd restart
/etc/init.d/bind9 start

ping www.google.com

If that works, then you’ve got a running BIND master server!

This can all be done using the free hamachi version. I have a premium license so I can make the network more secure by having to authorise new members.

This guide covers connecting a windows XP machine to private networks with linux and windows machines acting as the routing nodes.

I have 2 networks in my office, 10.1.0.0 and 10.2.0.0. I use the VPN for connecting my laptop to these networks from home.

Setting up the ‘client’ XP machine (the one which needs to VPN into the networks)
- Download and install hamachi
- Create a new network specifically for the VPN.
- Add ‘RoutedTunneling 1′ to hamachi-override.ini and restart Hamachi. You may need to create this file by clicking Configure, Preferences, System, Open Configuration Folder - then create hamachi-override.ini
- Click Start, Run and type ‘regedit’, then set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter to 1
- Reboot and open hamachi.

First ’server’ - Windows (10.1.0.53 is the example local IP)
Follow the instructions above, but instead of creating a new network, join the one you previously created. That’s all you need to do to get a windows server set up.

Linux ’servers’ (10.2.0.201 on my local network)
- cd /opt
- wget http://files.hamachi.cc/linux/hamachi-0.9.9.9-20-lnx.tar.gz
- tar -zxvf hamachi-0.9.9.9-20-lnx.tar.gz
- cd hamachi-0.9.9.9-20-lnx/
- mkdir /dev/net
- make install
- tuncfg/tuncfg
- hamachi-init
- hamachi start
- hamachi set-nick servername
- hamachi login
- hamachi join networkname networkpassword
- hamachi go-online networkname
- echo 1 > /proc/sys/net/ipv4/ip_forward

Note that whenever the linux machines are rebooted, /proc/sys/net/ipv4/ip_forward will reset to 0.

The server nodes are now setup to forward IPv4 packets around the network.

This next step is where most problems will occur. The server nodes will forward packets to the network, but other machines on the local networks don’t know where to send data to 5.x.x.x addresses. I set up rules on our firewall which work something like:
Requests to 5.0.0.0/8 need to be routed to 10.1.0.53 on the 10.1 network
Requests to 5.0.0.0/8 need to be routed to 10.2.0.201 on the 10.2 network
This is one rule for each of the networks I need to access. I’m not sure how to do this in different firewall setups so I’m not much help here.

Everything is now setup, but the ‘client’ node doesnt know where to send packets to any of the 10.1 or 10.2 networks. To fix this, we need to create routes on the machine. I created 2 batch files, one to connect the VPN, and one to disconnect.

Connect batch file

Obviously you’ll need to put the hamachi IP’s of each of the server nodes in this file.

Disconnect batch file

At this point everything is set up and ready to connect. You will need full connectivity to all the server nodes which you are using (green icons in hamachi).

Then you run the batch file to connect the VPN (or just type the route commands into a command prompt manually). Test pinging the local address of the server nodes, then other addresses inside the remote network.

Diagnostics
First, try pinging the local address of one of the server nodes (10.1.0.53 in my example). If this doesnt work, then my guess is that the route command hasn’t been done correctly.
Next, try pinging another machine on the local network (10.1.0.50 for example). If this doesnt work, then it’s likely that the server node isn’t forwarding the packets correctly, or the responses from the machine you’re pinging aren’t being sent back to the server node properly - check the firewall routing and make sure you’ve set /proc/sys/net/ipv4/ip_forward to 1.

Note that this whole setup will only work if the client node is actually off of the local network at the time you try to connect. By this, I mean that when I am at work, my laptop has the IP 10.1.0.56 and it connects out via 10.1.0.1 - obviously the VPN wont work while I’m at work because the route command will override the default gateway route and stop me connecting out at all.

When copying or connecting between Linux servers, the most straightforward solution is to use SSH or SCP. The only problem is that you’ll need to enter the password for the remote machine every time you connect, making this not very useful for scheduled scripts such as backups.

The easiest way to do this is to use public/private keys. To create a key on the local machine, do the following:

ssh-keygen -t rsa

Then just press enter at all of the prompts. This will create a keyfile called ~/.ssh/id_rsa.pub which you will need to copy to the remote machine.

ssh user@host “cat >> .ssh/authorized_keys” < ~/.ssh/id_rsa.pub

If the file ~/.ssh/authorized_keys doesn’t exist, you’ll need to create it, and ensure that it’s permissions are correct:

-rw-r–r– 1 root root 1412 2007-04-25 08:36 authorized_keys

Once this is done, you should be able to SSH and SCP to the remote machine without a password.

Obviously, from a security point of view this is a bad idea (especially if you’re doing it as root), but there are a lot of occasions where it can be useful.