Machen wir in meiner kleinen Pi Serie weiter. Auf normalen Desktop Computern hat man eigentlich immer AdBlock im Browser aktiviert um lästige Werbung loszuwerden. Auf den “neuen” Geräten wie Smartphone oder Tablet sind diese nicht verfügbar und man muss einen kleinen Umweg gehen.

Was bietet sich also nicht eher an als einen Proxy aufzusetzen und unerwünschten Inhalt zu filtern? Zensur im eigenen Netzwerk, basierent auf der Anleitung von calomel.org! Dank an pgl.yoyo.org gibt es eine ordentliche Liste die auch noch immer aktualisiert wird. Man kann sich die Liste in mehrere Formate ausgeben lassen und die Domains/IPs auch gerne per iptables sperren. Ich gehe den Weg des Proxies, weil zum Beispiel mein Blackberry Playbook kein IPv6 kann (ARGH!) (muss nur im Wlan Profil aktiviert werden) und ich durch den Proxy wenigstens sekundär v6 benutzen kann. Also erstmal Squid3 installieren, weil Squid2 kein v6 kann:

# apt-get install squid3

In der Konfiguration /etc/squid3/squid.conf müssen wir folgenden Eintrag hinzufügen. Dieser muss vor allen anderen acl Einträgen stehen (ungefähr Zeile: 693) und sieht folgendermaßen aus:

acl ads dstdom_regex "/etc/squid3/ad_block.txt"
http_access deny ads

Damit haben wir Squid gesagt, dass es allen Zugriff auf die Domains in der txt Datei sperren soll. Die Liste der zu sperrenden Domains erhalten wir durch einen Cronjob den wir uns schreiben:

#!/bin/bash
# script: update ad server list
# get new ad server list
wget -q -t 5 'http://pgl.yoyo.org/adservers/serverlist.php?hostformat=squid-dstdom-regex&showintro=0&mimetype=plaintext' -O /etc/squid3/ad_block.txt

# refresh squid
/usr/sbin/squid3 -k reconfigure

Das Script speichern wir unter /etc/squid3/fetch_adserver.sh. Es lädt sich die Liste herunter und Squid wird dazu gezwungen die Liste neu einzulesen. Ein einfacher Cronjob führt das Script alle drei Tage aus:

35   5    *   *   */3 /etc/squid3/fetch_adserver.sh >> /dev/null 2>&1

Erstmalig das Script per Hand ausführen und die Datei erstellen. Squid wird automatisch neu geladen und schon kann man surfen. Ach auf dem Playbook macht es wieder mehr Spaß :)

Vorher:

Nachher:

Damit man nicht zu viele Fehlermeldungen vom Squid im Browser sieht, sollte man noch die Datei ” /usr/share/squid3/errors/English/ERR_ACCESS_DENIED” bearbeiten und die Fehlermeldungen entfernen. Dabei sollte man den Inhalt einfach durch ein “<a>” ersetzen.

Mein Pi soll als mein IPv6 Gateway dienen, weil mein normaler Router leider nichts kann. Momentan muss man leider noch _sehr_ darauf achten welches Image man benutzt, weil nicht alle IPv6 unterstützen und ip6tables. Es sieht also noch sehr düster aus. Wenn man aber endlich eins gefunden hat und sich irgendwo einen Tunnel besorgt hat. Am Ende habe ich mich für eine Private Lösung entschieden, weil Sixxs einfach zu lange braucht :)

Bei ipv6 ist es eigentlich normal das man eine IP + ein 64er Netz bekommt. Warum? Die einzelne IP dient dazu die Verbindung zum Anbieter aufzubauen und das Netz kann dazu benutzt selber zu announcen oder als Service IPs zu benutzen. Man wirft also sprichwörtlich mit IP Adressen um sich… wenn man es hat…

Wenn man also seine IP und vielleicht später sein Netz bekommen hat kann man anfangen sein Pi in einen IPv6 Router umzuwandeln. Als erstes sollten wir dem Kernel erlauben v6 Pakete weiterzuleiten:

/sbin/sysctl -w net.ipv6.conf.all.forwarding=1

Es empfiehlt sich dies in der /etc/sysctl.conf zu verewigen, damit es auch nach einem Neustart automatisch gesetzt wird. In meinem Beispiel werde ich mein v6 Netz über ein tap0 Gerät laufen, dass kann bei jedem anders sein. Es ist keine Hexerei und einfacher geht es eigentlich nicht:

# single ip address
/sbin/ip -6 a a 2c01:118:a315:12::13/64 dev tap0
# default route to my provider
/sbin/ip -6 route add default via 2c01:118:a315:12::1 dev tap0
# my 64 network
/sbin/ip -6 a a 2c01:118:a315:44::1/64 dev eth0

Wie man erkennen kann habe ich meine einzelne IP auf dem tap0 Gerät und mein Netz auf eth0, damit ich das später in meinem “privaten” Netzwerk announcen kann. Jetzt sollte es schon möglich sein v6 Adressen zu erreichen. Dies testen wir mit einem simplen ping Test:

# ping6 itbert.de -c 5
PING itbert.de(2001:4d88:1ffc:4f6::1) 56 data bytes
64 bytes from 2001:4d88:1ffc:4f6::1: icmp_seq=1 ttl=56 time=22.9 ms
64 bytes from 2001:4d88:1ffc:4f6::1: icmp_seq=2 ttl=56 time=26.4 ms
64 bytes from 2001:4d88:1ffc:4f6::1: icmp_seq=3 ttl=56 time=20.4 ms
64 bytes from 2001:4d88:1ffc:4f6::1: icmp_seq=4 ttl=56 time=21.2 ms
64 bytes from 2001:4d88:1ffc:4f6::1: icmp_seq=5 ttl=56 time=23.0 ms

— itbert.de ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 20.427/22.810/26.405/2.062 ms

Sollte man keinen v6 Host pingen können, sollte man nochmal seinen Tunnel und die Adressen überprüfen. Ansonsten ist der kleine Pi bereit als Router zu dienen. Wie bekommen den unsere Clients dazu eine IP Adresse aus unserem Netz zu benutzen? Bei v6 gibt es an sich keinen DHCP wie man ihn von v4 kennt. Es gibt unter anderem auch keine NAT mehr. Das heißt, jeder Host aus dem ganzen Internet erreichbar ist, wenn man keine Firewall auf seinem Gateway einsetzt. Ich wette das wird noch ganz viel Spaß mit sich bringen, wenn erst mal alle Provider anfangen v6 Adressen auszuliefern. Also erstmal eine einfache Firewall einrichten:

#!/bin/bash
# script: ip6tables firewall script

IPV6T=”/sbin/ip6tables”
INFOUT=”tap0″
INFLOCAL=”eth0″
HOSTIP=”2c01:118:a315:12::13″

# First, delete all:
$IPV6T -F
$IPV6T -X

# Allow anything on the local link
$IPV6T -A INPUT  -i lo -j ACCEPT
$IPV6T -A OUTPUT -o lo -j ACCEPT

# Allow anything out on the internet
$IPV6T -A OUTPUT -o $INFOUT -j ACCEPT
# Allow established, related packets back in
$IPV6T -A INPUT  -i $INFOUT -m state –state ESTABLISHED,RELATED -j ACCEPT

# Allow the localnet access us:
$IPV6T -A INPUT -i $INFLOCAL -j ACCEPT
$IPV6T -A OUTPUT -o $INFLOCAL -j ACCEPT

# Filter all packets that have RH0 headers:
$IPV6T -A INPUT -m rt –rt-type 0 -j DROP
$IPV6T -A FORWARD -m rt –rt-type 0 -j DROP
$IPV6T -A OUTPUT -m rt –rt-type 0 -j DROP

# Allow Link-Local addresses
$IPV6T -A INPUT -s fe80::/10 -j ACCEPT
$IPV6T -A OUTPUT -s fe80::/10 -j ACCEPT

# Allow multicast
$IPV6T -A INPUT -d ff00::/8 -j ACCEPT
$IPV6T -A OUTPUT -d ff00::/8 -j ACCEPT

# Allow ICMPv6 everywhere
$IPV6T -I INPUT  -p icmpv6 -j ACCEPT
$IPV6T -I OUTPUT -p icmpv6 -j ACCEPT
$IPV6T -I FORWARD -p icmpv6 -j ACCEPT

# Allow forwarding
$IPV6T -A FORWARD -m state –state NEW -i $INFLOCAL -o $INFOUT -j ACCEPT
$IPV6T -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

# SSH in
$IPV6T -A INPUT -i $INFOUT -p tcp -d $HOSTIP –dport 22 -j ACCEPT

# Set the default policy
$IPV6T -P INPUT   DROP
$IPV6T -P FORWARD DROP
$IPV6T -P OUTPUT  DROP

Das Script verbietet jeden eingehen Traffic von $INFOUT und erlaubt nur SSH zu dem Host $HOSTIP. Ausgehender Verkehr bzw. Zugriff von $INFLOCAL ist ohne Einschränkungen möglich. Jetzt sind unsere Clients von Zugriffen aus dem bösen Internet sicher.

Wenn man die Firewall eingerichtet hat, können wir uns endlich um unserer Clients kümmern. Es gibt verschiede Dienste um v6 Netze zu announcen. Die bekanntesten sind quagga und radvd. Radvd ist wesendlich kleiner und wer nur Adressen announcen will ist damit besser beraten als mit quagga.

Die Konfiguration ist einfach in einer Datei untergebracht. Leicht zu verstehen und zu erweitern:

interface eth0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix 2c01:118:a315:44::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
route ::/0  {};
};

Bei diesem Beispiel wird das Netz 2c01:118:a315:44::/64 über eth0 announced und der default gw auf den Clients wird auch announced. Ist der Dienst gestartet, sollten auch schon die Clients eine v6 Adresse erhalten haben und der Standard Gateway ist gesetzt. Unter Archlinux funktionierte alles einwandfrei und ich musste nichts ändern. Ansonsten kann man die Route auf den Clients auch per Hand setzen:

/sbin/ip -6 r a ::/0 via 2c01:118:a315:44::1 dev eth0

Fehlen nur noch ein paar v6 Tests und man kann fröhlich in die Zukunft schauen…

Leider ist beim Pi nicht alles Opensource und es werden Firmwares benötigt. Zum Glück hat sich Hexxeh die mühe gemacht und ein kleines Update Script geschrieben. Mit diesem ist es möglich die Firmware ohne Probleme zu aktualisieren. Unter Debian musste ich noch ein paar Programme nachinstallieren:

apt-get install ca-certificates git-core binutils

Die Installation von rpi-update ist recht einfach und man kann eigentlich nichts falsch machen:

wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && chmod +x /usr/bin/rpi-update

Schon ist das Script einsatzbereit und es kann durch ein aufrufen durch: rpi-update gestatet werden. Der Rest geschieht automatisch oder man wird darauf hingewiesen noch Pakete zu installieren.

Dank des Updates wurde auch endlich ip6tables und andere Module aktiviert, die ich unbedingt braucht um ein vernünftiges IPv6 Gateway zu bauen.

Nachdem ich meine Desktop Distribution Archlinux auf dem Raspberry testete wollte ich Debian auch eine Chance geben. Die Installation ist die gleiche wie bei Archlinux, jedoch muss man noch die Swap Partition löschen UND was für mich unverständliches: Man muss SSH nachinstallieren. Es wird also unbedingt eine Tastatur und Monitor mit HDMI gebraucht. Wieso macht man so etwas? Argh!

Mein Pi soll für mich ein kleiner Gateway werden und wird in der nahen Zukunft mit IPv6, Proxy, VPN und anderen Spielereien bestückt. Dabei bin ich gespannt ob die Hardware ausreichend ist und wie man die Programme optimieren kann damit sie auf dem Pi ordentlich funktionieren.

Fangen wir mit einem IPv6 Tunnel von sixxs.net an.

Das “neue” Internet verbreitet sich immer weiter und als Administrator sollte man langsam anfangen sich damit auseinander zu setzen. Alle meine Server, Seiten und Dienste sind bereits per IPv6 erreichbar. Bis jetzt gibt es noch nicht viel zu erobern mit IPv6, aber die Infrastruktur muss erst einmal aufgebaut werden und das geschieht zur Zeit im Hintergrund mit einem parallelen laufen von IPv4 und IPv6.

Mein Provider bietet leider noch kein natives v6 und deswegen muss ich auf einen Tunnel von sixxs.net zurück greifen. Zum herumspielen und Testen sollte das vollkommen reichen. Auf dem Pi werde ich den Aiccu client installieren um den Tunnel aufzubauen. Dieser befindet sich schon im Debian Repository und kann einfach installiert werden:

apt-get install aiccu

Nach der Anmelden bei sixxs und ein paar Tage warten bekommt man die benötigten Zugangsdaten zugeschickt. Danach muss man sich noch für einen PoP entscheiden und diesen auch separat beantragen. Dies kann auch wieder ein paar Tage dauern oder auch nur Stunden.

Leider kommt das Debian Image ohne IPv6 Module und muss daher noch nachinstalliert werden. Entweder man kompiliert es sich oder man greift auf die Module auf github.com zurück. Die Installation ist recht einfach:

wget –no-check-certificate “https://github.com/raspberrypi/firmware/tarball/master” -O master.tar.gz
tar -xzf master.tar.gz
mv /lib/modules/3.1.9+/ old_modules
cp -rf raspberrypi-firmware-34c977e/modules/3.1.9+ /lib/modules/
# /boot muss gemounted sein!
cp raspberrypi-firmware-34c977e/boot/kernel.img /boot/
depmod -a
reboot

UPDATE: rpi-update

Funktioniert leider nicht und wir gehen einen anderen Weg und benutze ein anderes Image von linuxsystems.it. Wenn ihr das Image auch verwendet, dann folgt der Anleitung nach der Installation des Images und vergesst nicht die SSH host keys neu zu erstellen:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key

Und schon hat man ein minimal Debian Image mit SSH und IPv6 + Patches und neuster Firmware am laufen. Es fehlen noch die einen und anderen Module, aber warum nicht gleich so? Also weiter mit aiccu…

Damit wir bonding benutzen können müssen wir “ifenslave” installieren und danach können wir schon mit der Konfiguration loslegen.

Als erstes müssen wir festlegen welche Art von Bonding wir benutzen wollen. Ich benutze dafür “active-backup”. Das heist nur ein interface ist Aktiv. Damit wir das nicht nach jedem Boot machen müssen legen wir das beim laden des Modules fest

cat /etc/modprobe.d/aliases.conf
alias bond0 bonding
options bonding mode=1 miimon=10

Jetzt müssen wir nur noch unserer physikalischen Interfaces in /etc/network/interfaces konfigurieren:

auto bond0
iface bond0 inet static
        pre-up modprobe bond0
        address 192.168.1.10
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        gateway 192.168.1.1
        dns-nameservers 192.168.1.1
        up      ifenslave    bond0 eth0 eth1
        down    ifenslave -d bond0 eth0 eth1

Und Fertig! Man muss keine Konfiguration für die Netzwerkinterfaces vornehmen welche benutzt werden.

Vergangene Woche wurde ich ein glücklicher Besitzer eines Raspberry Pi. Ich war relative überrascht als ich die Versandbestätigung bekam – natürlich im positiven. Als erstes war ich sehr von der größe des kleinen überrascht. Der Pi ist wirklich nicht viel größer als eine Kreditkarte und sieht ordentlich kompakt aus. An RS habe ich inklusive Versand genau 39,89 EUR bezahlt. Der Preis ist unschlagbar jedoch braucht man noch eine SD Karte + Power. Als SD Karte habe ich mich für eine 16GB Transcend Class 10 entschieden. Als Stromlieferant kann fast jedes MicroUSB Ladegerät benutzt werden.

Als Betriebssystem habe ich mir für mein Haus-OS Archlinux entschieden. Das Image kann man sich bei Raspberry Pi direkt von der Homepage herunterladen. Ein aufspielen des Images geht problemlos mit dd:

# dd bs=1M if=archlinuxarm-29-04-2012.img of=/dev/sde

Wobei /dev/sde die angeschlossene SD Karte ist. Das Image ist für eine zwei Gigabyte große Karte. Deswegen müssen wir das Image noch anpassen. Dies können wir Problemlos mit fdisk erledigen:

# fdisk /dev/sde + p + d + 2 + n + p + 2 + (start der zweiten partition von der ersten ausgabe) + <enter> + w

# resize2fs /dev/sde2

Somit hat man schon die Partition angepasst. Wenn man möchte kann man sich noch eine swap Datei anlegen und sie einbinden. Das war auch schon die Installation von dem OS und man kann beginnen mit dem Pi zu spielen…

Die meisten Projekte fangen meistens mit einer guten Idee an und man fängt drauf los zu arbeiten. Sobald das Projekt ein paar Monate alt ist und man vielleicht dem einen oder anderen darüber erzählt hat, wollen mehr mitarbeiten. Dann stellt sich die Frage wie stellt man den anderen die Daten zur Verfügung damit jeder immer aktuell ist und ungestört arbeiten kann. Mit einer Versionskontrolle wie GIT geht das Wunderbar. Jetzt muss man nur seine lokalen Daten auf einen für alle erreichbaren Server zur Verfügung stellen. Mit ein paar Befehlen kann man ein lokales Repository erstellen, seine Daten hinzufügen und auf einen entfernten Server ablegen.

Server:

cd /home/ordner/pfad/zum/repo.git
git --bare init

Lokal:

git init
git add *
git commit -m "first"
git config --global user.email "meine.email@example.org"
git config --global user.name "Mein Name"
git remote add master ssh://name@example.org/home/ordner/pfad/zum/repo.git
git push master master
git push master

Als erstes muss auf dem Server ein Repository erstellt werden, damit wir unsere Daten auch ablegen können. Ich benutze hier als Protokoll SSH. Jetzt kann man glücklich drauf los commit’en und alle sind glücklich…