Homeserver mit dem Raspberry Pi

So ein Raspberry Pi ist schon was praktisches. Für einfache Netzwerk-Administrationsdienste hat es genug Leistung und dank seines ARM-Prozessors frisst es unter zwei Watt Strom, sodass man nicht mehr als 10 Euro für Strom ausgeben muss, um ein immer im Heimnetz erreichbaren Server zu besitzen. Da ich aber mit dem Netzwerkmonitoring via Nagios jetzt an die Leistungsgrenzen des alten Raspberry Pis gekommen bin, habe ich mir die neue Version zugelegt mit 1 GB RAM und Vierkernprozessor. Ein Grund mehr, beim Umziehen aller Dienste auf das neue Gerät einmal für Ordnung zu sorgen und die Installation zu dokumentieren. Folgende Dienste werde ich installieren und deren Einrichtung beschreiben:

  • DNS-Server
  • DHCP-Server
  • TFTP-Bootserver
  • VPN-Gateway mit openVPN
  • check_mk monitoring von Linux-Servern und einem managed Switch
  • FTP-Server
  • kleiner Webserver
  • VLAN-Gateway

Ein fertig installiertes Raspberry Pi mit dem Debian-Derivat Raspbian setze ich an dieser Stelle voraus. Eine Anleitung für alle gängigen Betriebssysteme findet man hier.

Bevor wir mit der Einrichtung der Dienste beginnen, müssen wir dem Gerät eine feste IP-Adresse zuweisen. Dies ist für einige Dienste notwendig. Die Konfiguration des Netzwerks erfolgt bei Raspbian in der Datei /etc/network/interfaces. Hier definieren wir für die Schnittstelle eth0 die IP-Adresse, die Subnetmask und das Internet-Gateway:

iface eth0 inet static
        address 192.168.2.2
        netmask 255.255.255.0
        gateway 192.168.2.1

Eventuell schon vorhandene Zeilen für eth0 müssen auskommentiert (mit einer #) oder gelöscht werden.

DNS-Server mit BIND9

Bind ist in der Version 9 einer der bekanntesten Nameserver. Für mich ist er eine besser konfigurierbare Alternative zur Fritzbox und verwaltet gleichzeitig die lokaln Domains intra und vpn meines Heimnetzes. Für ein kleineres Netz würde auch der einfache DHCP/DNS-Kombiserver dnsmasq verwenden, aber wir wollen es ja gleich richtig machen. Bind wird wie folgt einfach installiert:

sudo apt-get install bind9

Alle für die Konfiguration wichtigen Dateien finden wir in /etc/bind/. In den Dateien, die mit named. beginnen, wird die allgemeine Funktion des Servers konfiguriert. Die db.-Dateien sind dagegen die Zonendateien, in denen die eigentlichen DNS-Daten abgelegt werden. Bind fungiert zum einen als Relay-Server für DNS-Anfragen zu Webseiten. Primärer Aufgabe soll aber das hosten einer eigenen Domain für das Intranet sein, in meinem Fall intra.stoerte.net und vpn.stoerte.net. Für jede Domain müssen zwei Dateien erstellt werden: eine db.intra.stoerte.net für die Adressauflösung (typischerweise nutzt man die Endung .lan für das Heimnetz, wenn man keine eigene Domain besitzt) und eine db.2.168.192 für die Übersetzung einer IP in eine Domain (hierbei wird laut Konvention die IP des Netzwerkes rückwärts geschrieben). Für meine Domain sieht die Datei wie folgt aus:

;; db.intra.stoerte.net
;; Forwardlookupzone für intranet
;;
$TTL 1H
@       IN      SOA     raspberry.intra.stoerte.net. mail.intra.stoerte.net. (
                        1501091600      ; Serial
                                1H      ; Refresh
                                1H      ; Retry
                                1W      ; Expire
                                3H )    ; NX (TTL Negativ Cache)

@                               IN      NS      raspberry.intra.stoerte.net.
                                IN      MX      10 raspberry.intra.stoerte.net.

fritz                           IN      A       192.168.2.1
praspberry                      IN      A       192.168.2.2
....

Im untersten Bereich werden die Adressen mitsamt der IPs eingetragen. IN steht für Internet und A sagt, dass es sich um eine IPv4-Adresse handelt. Für eine IPv6-Adresse gibt es AAAA. Der erste Eintrag übersetzt die Adresse fritz.intra.stoerte.net in die IP 192.168.2.1. Um das Tutorial nicht allzu sehr in die Länge zu ziehen, verweise ich für eine ausführlichere Beschreibung der einzelnen Zeilen auf den BIND-Artikel auf ubuntuusers.de. Besonders wichtig an dieser Stelle ist eine Leerzeile am Ende der Datei!

Für den Reverse-Lookup (Übersetzen einer IP in einen Domain-Namen) ist die ähnlich aufgebaute Datei db.2.168.192 für mein heimisches Subnetz 192.168.2.0/24 von Nöten. Diese sieht bei mir so aus:

;; db.2.168.192
;; Reverselookupzone fuer intranet
;;
$TTL 1H
@       IN      SOA     raspberry.intra.stoerte.net. mail.intra.stoerte.net. (
                                1411052258      ; Serial
                                        1H      ; Refresh
                                        1H      ; Retry
                                        1W      ; Expire
                                        2D )    ; TTL Negative Cache

@       IN      NS      raspberry.intra.stoerte.net.

1       IN      PTR     fritz.intra.stoerte.net.
2       IN      PTR     raspberry.intra.stoerte.net.
...

Hier steht der letzte Block der IP-Adresse am Anfang und der Domain-Name rechts. Wichtig ist hier ein Punkt am Ende der Domain und auch wieder eine Leerzeile am unteren Ende der Datei.

Damit die neue Domain auch von BIND geladen wird, muss sie diesem zuerst bekannt gemacht werden. Dies geschieht in der Datei named.conf.local. Diese wird von der Datei named.conf referenziert. Für die oben erstellten Dateien sehen die Einträge so aus:

zone "intra.stoerte.net" {
        type master;
        file "/etc/bind/db.intra.stoerte.net";
};
zone "2.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.2.168.192";
};

Die Option Master sagt dem Server, dass er der Hauptverantwortliche für die Domain ist (der primäre Name-server). Mit einem Neustart werden die neuen Dateien geladen:
sudo /etc/init.d/bind9 restart
Zum Test kann nun mit Hilfe des Befehls dig getestet werden, ob die Domain fritz.intra.stoerte.net korrekt aufgerufen wird:
dig @127.0.0.1 fritz.intra.stoerte.net.

;  DiG 9.8.4-rpz2+rl005.12-P1  @192.168.2.192 fritz.intra.stoerte.net.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 26322
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;fritz.intra.stoerte.net.       IN      A

;; ANSWER SECTION:
fritz.intra.stoerte.net. 3600   IN      A       192.168.2.1

;; AUTHORITY SECTION:
intra.stoerte.net.      3600    IN      NS      raspberry.intra.stoerte.net.

;; ADDITIONAL SECTION:
raspberry.intra.stoerte.net. 3600 IN    A       192.168.2.2

;; Query time: 18 msec
;; SERVER: 192.168.2.192#53(192.168.2.192)
;; WHEN: Thu Mar 12 22:28:01 2015
;; MSG SIZE  rcvd: 97

DHCP-Server mit isc-dhcp
Doch was nützt uns der DNS-Server, wenn er keinem Client im Netz bekannt ist? Dazu kommt als nächstes ein DHCP-Server. DHCP steht für Dynamic Host Client Protocol und versorgt einen neuen Computer im Heimnetz mit allen nötigen Informationen, wie einer IP-Adresse, der IP des DNS-Servers und dem Internet-Gateway. Die Installation von isc-dhcp ist wieder sehr einfach:
sudo apt-get install isc-dhcp-server
Die Konfigurationsdatei ist /etc/dhcp/dhcpd.conf:

option domain-name "intra.stoerte.net";
option domain-name-servers 192.168.2.2;
authoritative;
## LAN
subnet 192.168.2.0 netmask 255.255.255.0 {

option subnet-mask 255.255.255.0;

range 192.168.2.100 192.168.2.199;

option routers 192.168.2.1;

host laptop{ hardware ethernet 73:A8:FC:59:17:4C; fixed-address 192.168.2.5; option host-name "laptop"; }

# PXE
next-server 192.168.2.3;
filename "pxelinux.0";
}

Die ersten beiden Zeilen geben Informationen über das aktuelle Subnetz und auf welcher IP der favorisierte DNS-Server zu finden ist. Das Flag authoritative besagt, dass dieser Server der primäre DHCP-Server im Netzwerk ist. Darunter werden die verwalteten Subnetz definiert. Mein LAN ist das Subnetz 192.168.2.0 mit der Subnetzmaske 255.255.255.0 und in der Range von 192.168.2.100 bis 199 werden IP-Adressen dynamisch vergeben. Eine Begrenzung des DHCP-Bereichs ist insofern sinvoll, als das man so noch einen freien IP-Bereich hat, in dem man feste Adressen vergeben kann (welche ja für eine Domain-Adressierung notwendig sind. Die mit host beginnende Zeile zeigt, wie man anhand der MAC-Adresse ein Gerät identifizieren und ihm immer die selbe IP-Adresse zuweisen kann. Die beiden nach dem Tag „PXE“ folgenden Zeilen sind für den TFTP-Bootserver notwendig, auf den ich im nächsten Kapitel eingehen werde. Wichtig ist hier die IP des Servers und die Datei, die geladen werden soll. Das genügt fürs Erste.

Vergewissert euch, dass euer bis dahin aktiver DHCP-Server (in meinem Fall die Fritzbox) deaktiviert wird und startet dann den DHCP-Server auf dem Raspberry Pi neu mit folgendem Befehl:

/etc/init.d/isc-dhcp-server start

PXE-Boot

Wenn man häufiger Computer neu installieren möchte oder keine CD/USB-Stick für ein Live-System zur Hand hat, kann ein Betriebssystem auch aus dem Netzwerk gebootet werden. PXE steht für PreExecution Enviroment und lädt eine Umgebung, von der aus weitere Aktionen ausgeführt werden können (wie die Installation von Linux). Clientseitig gibt es hier nur wenig einzustellen: Beim booten muss lediglich Netzwerk als erste Boot-Option ausgewählt werden. Bei vielen PCs kann man dies erreichen, indem man während des Bootvorgangs F11 oder F12 drückt (hierfür empfehle ich Google). Serverseitig benötigen wir dafür einen TFTP-Server, welcher die Dateien bereitstellt und den im vorherigen Kapitel erwähnten Eintrag im DHCP-Server, denn diese Bootoption wird über den DHCP-Server bekannt gemacht.

sudo apt-get install tftpd-hpa syslinux-common nfs-kernel-server

Während der Installation von tftp kann es zu einer Fehlermeldung kommen:

dpkg: Fehler beim Bearbeiten von tftpd-hpa (--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 71 zurück

Das liegt daran, dass der TFTP-Server nicht starten kann, weil auf dem raspberry kein IPv6 aktiv ist. Als Lösung des Problems genügt es einfach, die Datei /etc/default/tftpd-hpa zu bearbeiten und die Zeile TFTP_OPTIONS=“–secure“ zu TFTP_OPTIONS=“–secure –ipv4″ zu erweitern. Wenn man nun den Befehl zur Installation des Programms erneut ausführt, sollte alles normal installiert werden. Gestartet werden kann der TFTP-Server mit
sudo service tftpd-hpa start
Die benötigten Dateien werden mit folgendem Befehl in den Ordner /srv/tftp/ kopiert:
sudo cp /usr/lib/syslinux/chain.c32 /usr/lib/syslinux/menu.c32 /usr/lib/syslinux/vesamenu.c32 /usr/lib/syslinux/pxelinux.0 /srv/tftp/
Für die eigentliche Konfigurationsdatei, welche sich ein Client lädt, führen wir folgende Befehle aus und geben danach den darunter stehenden Codeblog in die Datei ein:

sudo mkdir /srv/tftp/pxelinux.cfg
sudo nano /srv/tftp/pxelinux.cfg/default

default vesamenu.c32
timeout 100
prompt 0
noescape 1

menu title PXE Boot Options

label hdd
  menu label Boot from local hard disk
  menu default
  localboot 0x80

Das so erstellte Menü besitzt einen Auswahlpunkt für das Booten von der Festplatte. Das hinzufügen weiterer Images für das installieren von Linux oder Live-Systeme werde ich in einem folgenden Tutorial beschreiben.
Für einige Programme ist es von nöten, einen Netzwerk-Mountpoint bereit zustellen, das geschieht mit Hilfe von NFS-Mount. Dafür muss die Datei /etc/exports editiert werden. Die folgende Zeile sorgt dafür, dass alle Computer aus meinem Heimnetz auf den Mountpoint /srv/nfs zugreifen können:

 /srv/nfs 192.168.2.0/24(rw,sync,no_root_squash,no_subtree_check)

Diesen Ordner erstellen wir nun noch mit sudo mkdir /srv/nfs und laden anschließend den NFS-Mount mit sudo exportfs -rv und starten den NFS-Server zur Sicherheit auch einmal neu: sudo /etc/init.d/nfs-kernel-server restart

OpenVPN-Client mit Routing

Die Einrichtung eines openVPN-Servers möchte ich hier ausklammern, dies wird in anderen Tutorials erklärt. An dieser Stelle möchte ich zeigen, wie das raspberry pi als Client an meinen openVPN-Server im Internet anbinde und die beiden Netze durch Routing mit einander verbinde. Ziel ist es, dass ich über den VPN-Tunnel jederzeit auf mein Heimnetz zugreifen kann. Dazu installieren wir uns zuerst den Client:
sudo apt-get install openvpn

Anschließend braucht ihr von eurem Server die erstellten Zertifikate. Auf dem Client werden drei Dateien benötigt: ca.crt (benötigt jeder Client), client01.crt, client01.key (muss für jeden Client generiert werden). Diese kopiert ihr in den Ordner /etc/openvpn/keys.

Die folgende Config ist ein Beispiel und enthält alle wesentlichen und nützlichen Parameter:

client
dev tun0
proto tcp
remote mein-server.de 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca keys/ca.crt
cert keys/client01.crt
key keys/client01.key
ns-cert-type server
comp-lzo
verb 3
log-append  openvpn.log

Die originale Konfigurationsdatei enthält eine gute Dokumentation.
Damit das pi auch Pakete von einem in das andere Netz forwarded, muss die folgende Datei editiert werden:
sudo nano /etc/sysctl.conf
Die folgende Zeile muss den Wert 1 erhalten:

net.ipv4.ip_forward = 1

Anschließend muss die Datei neu eingelesen und der openVPN-Server neugestartet werden:
sudo sysctl -p /etc/sysctl.conf
sudo /etc/init.d/openvpn restart

Damit sind alle Arbeiten am pi abgeschlossen. Um die Route in das LAN noch im VPN zu pushen (sodass jeder VPN-Client weiss, dass er über das pi in das Heimnetz kommt) muss noch eine kleine Änderung am openvpn-Server vorgenommen werden. Erstellt den Ordner /etc/openvpn/ccd und erzeugt darin eine Datei mit dem gleichen Namen, wie das Zertifikat des raspberry pis (in diesem Beispiel client01). In diese Datei kommt die Route

iroute 192.168.2.0 255.255.255.0

Danach muss noch die config-Datei des Servers erweitert werden um folgende Zeilen:

client-config-dir /etc/openvpn/ccd
route 192.168.2.0 255.255.255.0
push "route 192.168.2.0 255.255.255.0 vpn_gateway 100"

Der Parameter vpn_gateway 100 gibt an, dass die Route eine Metrik von 100 haben soll. Wenn ihr euch nämlich mit einem aktiven VPN-Tunnel im Heimnetz befindet, gibt es zwei Routen in das Netz 192.168.2.0/24 Damit nun die LAN-Daten nicht über das Internet gejagt werden, bekommt die Tunnel-Route eine höhere Metrik und die direkte LAN-Verbindung wird bei bestehen bevorzugt genutzt.
Anschließend muss auch der Server einmal neugestartet werden.

Monitoring mit check_mk

Mit check_mk (basierend auf Nagios) lassen sich diverse Systeme monitoren. Zu Hause nutze ich es für das Monitoring via SNMP von meinem Switch und der beiden Online-Server, welche über den VPN-Tunnel erreicht werden. Für check_mk ist das Raspberry Pi 2 zu empfehlen, die erste Version hat schlicht zu wenig Leistung und ist schon bei 1-2 überwachten Geräten derbe überfordert. Zur Installation fügen wir als erstes die Quellen hinzu und installieren das Paket anschließend:

sudo su
echo 'deb http://labs.consol.de/repo/stable/debian wheezy main' >> /etc/apt/sources.list
gpg --keyserver keys.gnupg.net --recv-keys F8C1CA08A57B9ED7
gpg --armor --export F8C1CA08A57B9ED7 | apt-key add -
apt-get update
apt-get install omd-1.00

Nach der Installation erstellen wir uns eine check_mk-Instanz:

omd create pimon
omd start pimon

Diese ist nun unter der Adresse des Pis erreichbar mit den Login-Daten omdadmin/omd. In meinem Fall diese Adresse: http://pi.intra.stoerte.net/pimon/

Um ein SNMP-Device (z.B. einen Managed-Switch) zu monitoren muss das entsprechende Modul aktiviert werden in check_mk. Dazu beenden wir zuerst das Programm (als root):

omd stop pimon
omd config pimon

In den Einstellungen gehen wir in Addons und aktivieren dort MKEVENTD. Anschließend alles abspeichern und die Instanz wieder neustarten.

omd start pimon

FTP-Server

Ein FTP-Server ist schnell eingerichtet und ideal, um große Mengen an Daten einfach zu übertragen. Man sollte jedoch bedenken, dass sämtliche Daten (sowohl login als auch übertragene Daten) im Klartext vorliegen. Für meine Zwecke hat sich vsFTP bewährt. Dieser installiert sich wie folgt:

sudo apt-get install vsftpd

Danach das Programm installiert und jeder Nutzer auf dem System kann sich mit diesen Daten auch via FTP einwählen. Es ist zu empfehlen, die config-Datei zu editieren, um die Schreibzugriffe für die Nutzer zu erlauben. Diese findet sich unter /etc/vsftpd.conf. Wichtig sind die folgenden zwei Parameter:

anonymous_enable=NO
local_enable=YES
write_enable=YES

Danach ein Neustart mit

sudo /etc/init.d/vsftpd restart

und der Login funktioniert. Die Konfigurationsdatei ist weitesgehend selbsterklärend und lohnt sich, sie mal durchzulesen.

kleiner Webserver

Dieses Tutorial wird bei Gelegenheit ergänzt. Das wohl bekannteste Programm hierfür ist (neben nginx) der Apache2 Webserver:

sudo apt-get install apache2

Nach der Installation können Webdateien im Ordner /var/www abgelegt werden.

VLAN-Gateway
Mit VLANs kann man mehrere getrennte Subnetze auf einem Switch getrennt von einander betreiben und via VLAN-Trunk über ein gemeinsames Kabel zu einem anderen switch leiten. Mein Setup zu Hause schaut folgendermaßen aus: ich habe ein normales LAN und ein LOM-Netz zur Remote-Administraion meiner Server. Beide möchte ich trennen. Damit ich vom Heimnetz in das LOM-Netz komme, wird mein Rasperry Router zwischen diesen Netzen spielen, dazu steckt es untagged im Heimnetz und tagged im VLAN Nummer 3900 (VLAN-Nummer ist frei wählbar zwischen 1-4096, 1 ist meist das default-VLAN). Als erstes muss das entsprechende Paket installiert werden:

sudo apt-get install vlan

Da die Konfiguration dauerhaft sein soll, schreiben wir sie in /etc/network/interfaces:

auto vlan3900
iface vlan3900 inet static
        address 192.168.10.254
        netmask 255.255.255.0
        vlan_raw_device eth0

Anschließend muss das Netzwerk noch neugestartet werden. Hierbei ist zu beachten, dass ihr nicht remote auf dem Gerät arbeiten dürft, da sich der Befehl sonst selbst das Netzwerk wegreisst und ihr das pi nicht mehr erreicht. In diesem Fall sollte lieber ein Neustart mit sudo init 6 ausgeführt werden. Arbeitet ihr direkt am pi, so hilft folgender Befehl weiter:
sudo /etc/init.d/networking restart
Danach genügt ein kurzer Blick in ifconfig um unser neues VLAN-Device zu sehen.
Um nun zwischen den Netzen zu routen muss die Route zum einen noch statisch in euer Default-Gateway (meist euer Router) eingetragen werden und zum anderen auf dem pi in der Datei /etc/sysctl.conf noch der Wert von net.ipv4.ip_forward auf 1 gesetzt und das Netzwerk neugestartet werden (oder analog wieder ein reboot).

Wenn mir noch weitere Dienste einfallen, die erklärungswürdig sind, werde ich den Artikel ergänzen. Bis dahin:

Stay Tuned
Støertebeker

Veröffentlicht unter Allgemein, Installationen, Linux, Netzwerk, Tutorials

Schreibe einen Kommentar