Nachdem mein Raspberry Pi jetzt schon etwas länger quasi ungenutzt herumlag, habe ich mich jetzt
mal wieder daran gemacht, diesen als zentrales VPN Gateway einzusetzen. Frühere Versuche mit
OpenVPN sind gescheitert, da der Raspi dafür scheinbar nicht leistungsfähig genug ist, über
3-4 MBit/s bin ich nie hinweg gekommen. Nun also ein neuer Versuch, diesmal über PPTP statt OpenVPN.

Hinweis: Ich bin mir bewusst, das PPTP im Grunde unsicher ist (siehe z.B. hier:
 http://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.html), für meine Zwecke
aber ausreichend. Es geht hier eher um den Wechsel der IP Adresse um z.B. hulu zu nutzen, denn
um Verschlüsselung meines Datenverkehrs.

Meine Schritte nach dem Klick.

PPTP Einwahl einrichten

Ich nutze die Standard Raspberry Pi Wheezy Distribution von 9.2.2013 (hier: http://www.raspberrypi.org/downloads
Nachdem alles eingerichetet ist, und das Raspi eine feste IP Adresse bekommen hat, wir pptp nachinstalliert:

sudo apt-get install pptp-linux

Wir brauchen eine Konfiguration, diese muss in /etc/ppp/peers liegen. Der Name ist im Grunde egal, ich habe meine vpn.conf genannt.
Meine Konfiguration sieht so aus:

pty "pptp $SERVERNAME --nolaunchpppd --debug"
name $USERNAME
password $PASSWORD
remotename PPTP
require-mppe-128
require-mschap-v2
refuse-eap
refuse-pap
refuse-chap
refuse-mschap
noauth
debug
persist
maxfail 0
defaultroute
replacedefaultroute
usepeerdns

$SERVERNAME, $USERNAME und $PASSWORD müssen natürlich in die entsprechenden Werte des VPN Providers geändert werden.
OK, Zeit für einen ersten Test. Mit

sudo pon vpn.conf

machen wir eine erste Einwahl. Ein ifconfig sollte nun ein ppp0 Interface mit entsprechender IP zeigen:

ppp0      Link encap:Point-to-Point Protocol
          inet addr:10.11.21.10  P-t-P:10.11.21.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1496  Metric:1
          RX packets:771 errors:0 dropped:0 overruns:0 frame:0
          TX packets:645 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:614730 (600.3 KiB)  TX bytes:144569 (141.1 KiB)

Fein! Das funktioniert also schon mal. Mit

sudo poff vpn.conf

trennen wir die Verbindung erstmal wieder.

Routing

Das wir den Traffic über ppp0 routen möchten, müssen wir noch ein paar Kleinigkeiten ändern.
Da wäre als erstes die sysctl.conf, in dieser muss die Einstellung

net.ipv4.ip_forward=1

auskommentiert werden.
Abschließend wird die neue Konfiguration mit

sysctl -p

aktiviert.

Der Rest wird über iptables geregelt, also legen wir die Datei /etc/iptables.rules an. Der Inhalt bei mir ist dieser:

*nat
-A POSTROUTING -o ppp0 -j MASQUERADE
COMMIT

*filter
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i ppp0 -j DROP
COMMIT

Damit wird der gesamte Traffic über ppp0 geroutet und zusätzlich eingehender Traffic von ppp0, sofern er nicht zu einer bestehenden Verbindung gehört, gedroppt.
Mit einem

sudo iptables-restore < /etc/iptables.rules

können die Regeln geladen werden.

Erster Test

Nachdem die PPTP Verbindung wiederhergestellt ist, können wir den ersten Test machen, indem das Gateway auf dem Testsystem auf die IP von eth0 des Raspi gesetzt wird.
Mittels traceroute google.de (bzw. tracert google.de unter Windows) können wir sehen, ob der Traffic nun über das VPN geht.

Vorher:

phil@philinux:~# traceroute google.de
traceroute to google.de (173.194.39.23), 30 hops max, 60 byte packets
 1  * * *
 2  dor002ibr010-xdsl.versatel.de (62.214.64.191)  55.429 ms  55.627 ms  55.880 ms
 3  ge-2-12-605.dor002isp005.versatel.de (62.214.111.193)  14.871 ms  15.964 ms  16.534 ms
 4  10g-8-4.hhb002isp005.versatel.de (62.214.110.122)  22.849 ms 10g-9-4.hhb002isp005.versatel.de (62.214.110.110)  23.829 ms  25.298 ms
 5  62.214.61.54 (62.214.61.54)  26.810 ms  26.821 ms  27.522 ms
 6  72.14.233.121 (72.14.233.121)  29.928 ms  22.878 ms  24.348 ms
 7  173.194.39.23 (173.194.39.23)  25.111 ms  25.700 ms  25.123 ms

Der Traffic geht also über meinen Provider raus, wenn das Gateway nicht umgestellt ist.

Nachher:

phil@philinux:~# traceroute google.de
traceroute to google.de (173.194.69.94), 30 hops max, 60 byte packets
 1  10.11.21.1 (10.11.21.1)  48.760 ms  50.103 ms  51.237 ms
 2  ip-static-94-242-250-1.as5577.net (94.242.250.1)  100.600 ms  101.161 ms  101.246 ms
 3  stnsl.lux.as5577.net (83.243.15.249)  101.276 ms  101.296 ms  101.329 ms
 4  ic-root.lux.as5577.net (199.59.206.101)  70.123 ms  69.895 ms  71.492 ms
 5  te3-2.r1.de.iptransit.com (199.59.206.129)  82.000 ms  83.168 ms  85.745 ms
 6  xe-0-1-3.r2.ams.tc2.nl.iptransit.com (199.59.206.126)  87.574 ms  117.699 ms xe-2-0-1.r2.ams.tc2.nl.iptransit.com (199.59.206.186)  56.274 ms
 7  core1.ams.net.google.com (195.69.144.247)  57.035 ms  56.204 ms  55.966 ms
 8  209.85.248.116 (209.85.248.116)  90.189 ms  57.361 ms  56.659 ms
 9  209.85.255.60 (209.85.255.60)  58.554 ms 209.85.255.70 (209.85.255.70)  59.210 ms 209.85.255.74 (209.85.255.74)  60.714 ms
10  216.239.43.126 (216.239.43.126)  67.722 ms  67.348 ms  66.935 ms
11  209.85.240.88 (209.85.240.88)  73.022 ms  72.494 ms  71.858 ms
12  216.239.48.53 (216.239.48.53)  59.627 ms 64.233.174.55 (64.233.174.55)  58.286 ms  58.785 ms
13  * * *
14  bk-in-f94.1e100.net (173.194.69.94)  60.726 ms  60.912 ms  61.197 ms

Tada, der Traffic geht über das VPN. Damit ist die Einrichtung im Grunde abgeschlossen, der Raspi kann sich ins VPN einwählen und diese Verbindung als Router wieder zur Verfügung stellen. Jetzt könnte man daher gehen und dem DHCP Server sagen, er solle doch bitte die IP der Raspi als Gateway verteilen und schon wird der gesamte Traffic im Netzwerk über das VPN geroutet.

Das Ganze soll natürlich automatisch funktionieren, wenn der Raspberry Pi gestartet wird, also:

Startscript einrichten

Legen wir eine Datei in /etc/init.d/ an, z.B. pptpdailin.
Meine hat diesen Inhalt:

#! /bin/sh

case "$1" in
  start)
    pon vpn.conf
    iptables-restore < /etc/iptables.rules
    echo "PPTP Started"
    ;;
  stop)
    poff vpn.conf
    iptables -F
    iptables -X
    iptables -t nat -F
    iptables -t nat -X
    iptables -P INPUT ACCEPT
    iptables -P FORWARD ACCEPT
    iptables -P OUTPUT ACCEPT
    echo "PPTP Stopped."
    ;;
  *)
    echo "Usage: /etc/init.d/pptpdailin {start|stop}"
    exit 1
    ;;
esac

exit 0

Dieses Script sorgt dafür, das (wenn mit Start aufgerufen) die PPTP Einwahl durchgeführt wird sowie unsere iptables Regeln geladen werden. Beim Stoppen schließen wir die Verbindung wieder und räumen ein wenig im iptables auf. Das muss nicht sein, schadet aber auch nicht.

Mit

sudo chmod +x /etc/init.d/pptpdailin
update-rc.d pptpdailin defaults

wird das Script ausführbar gemacht und bei jedem Start ausgeführt.

Performance

Jetzt interessiert mich die Performance, und ob ich die 3-4Mbit/s des vorherigen Versuches mit OpenVPN übertreffen kann, oder ob das Raspi einfach wirklich zu langsam für eine Anwendung wie diese ist.

Dazu verwende ich verschiedene Speedtest Webseiten, und vergleiche einmal die Verbindung ohne VPN, einmal mit Direkteinwahl von meinem Rechner und einmal die Route über den Raspi

Die Leistung des OpenVPN habe ich mit PPTP zwar geschlagen, richtig befriedigend ist das allerdings noch nicht.
Interessant ist, das die CPU Auslastung des Raspi während eines Datentransfers nicht über 70-80% steigt. Mir ist
es deswegen noch schleierhaft, warum die Leistung nach wie vor so miserabel ist.

CPU Takt

Obwohl die CPU nicht voll ausgelastet ist, versuche ich es mit Übertakten.
Wie das Übertakten im Einzelnen funktioniert führe ich hier nicht auf, da gibt es genug Anleitungen zu, z.B. diese:
http://www.jeremymorgan.com/tutorials/raspberry-pi/how-to-overclock-raspberry-pi/
Ich teste diesmal nur über speed.io, es geht mir ja um die Unterschiede zwischen den Taktfrequenzen.
Die CPU Last beobachte ich mit top, daher sind diese Werte natürlich nicht sehr genau.

Ich habe bei 900 MHz erstmal aufgehört, um zu einer anderen Tageszeit nochmal zu messen.
Alles in allem ist das Ganze allerdings nicht so richtig flott, die endgültige Lösung ist das so noch nicht.

UPDATE: 6.3.: Der RasPi läuft immer noch mit 900 MHz, die Geschwindigkeit steigt aber leider
noch immer nicht über 3569 MBit/s Down und 164 KBit/s Up.

Ich werde also einen weiteren Versuch mit dem HP ProLiant Microserver N46L starten, wobei der Stromverbrauch
bei dem Ding wohl in keinem Verhältnis zum Raspi steht…