So bleibt der Zugriff auf das eigene Netzwerk auch dann möglich, wenn der Server eines Tages mal nicht so funktioniert, wie er soll. Wenn mit der Box generell etwas nicht stimmt und die Internetverbindung komplett wegbricht, ist in der Regel ohnehin alles verloren. Zudem sind Portweiterleitungen in diesem Fall ebenso wenig notwendig wie ein zusätzlicher DynDNS-Dienst, das übernimmt AVM mit seinem MyFritz-Service.

WireGuard auf der Fritzbox einrichten

Einrichten lässt sich das Ganze in der Fritzbox unter Internet » Freigaben im Reiter VPN (WireGuard). Dort wählt man Verbindung hinzufügen und anschließend Einzelgerät verbinden. Den Namen der Verbindung könnt ihr frei wählen, üblicherweise nutzt man hier den Namen des Client-Rechners oder der Person, die das VPN nutzen wird. Zum Schluss muss das Anlegen der Verbindung noch bestätigt werden, etwa per Telefon, Tastendruck oder über die Fritz-App.

Anschließend zeigt euch die Fritzbox eine Seite mit einem QR Code. Den könnt ihr zum Beispiel mit dem Smartphone scannen, um die Verbindung direkt in die offizielle WireGuard App für Android zu übernehmen. Alternativ geht auch die Open-Source-App WG Tunnel, die deutlich mehr Funktionen bietet wie der „offizielle“ WireGuard-Client für Android. Ich persönlich nutze WG Tunnel, das ich über F-Droid installiert habe.

WireGuard Konfiguration in NetworkManager

Für Linux (und generell Desktop-PCs) bietet die Fritzbox die Möglichkeit, die Konfiguration herunterzuladen. Klickt auf den Button und speichert die Datei lokal auf der Festplatte ab. Die Datei wird standardmäßig als wg_config.conf im Ordner Downloads gespeichert. Der Name ist nicht ganz unwichtig, da einige WireGuard-Clients diesen Namen automatisch zur Benennung der Schnittstelle heranziehen.

Den Import erledigt ihr direkt über den NetworkManager am Desktop oder per Kommandozeile. Unter GNOME geht ihr in die Einstellungen, dann Netzwerk, dort klickt ihr auf das Plus Symbol und wählt Aus Datei importieren …. Danach die wg_config.conf Datei auswählen und importieren. Den Namen der Verbindung könnt ihr dann in den Einstellungen beliebig anpassen, ich empfehle aber den Schnittstellennamen auf wg0 zu setzen.

$ nmcli connection import type wireguard file ~/Downloads/wg_config.conf
Verbindung »wg_config« (39724859-b102-4446-bdb2-1ec60f501360) erfolgreich hinzugefügt.

Das war es schon. Ihr könnt das VPN jetzt direkt über die Quick Settings in GNOME aktivieren. Auch andere Desktopumgebungen wie KDE bieten passende Möglichkeiten. Wenn ihr prüfen möchtet, ob die Verbindung steht, installiert unter GNOME die Erweiterung IP Finder. Sie zeigt euch die öffentliche IP-Adresse mitsamt Länderflagge. Sobald dort die Flagge eures Wohnorts erscheint statt eures aktuellen Aufenthaltsorts (bspw. im Urlaub im Ausland), steht das VPN.

Doch nicht alle Haushaltsmitglieder sind begeistert, dass nun manche Anzeigen nicht mehr funktionieren – etwa die Werbeblöcke in der Google-Suche. Das muss man nicht unbedingt nachvollziehen können, aber es ist nun mal so.

Zum Glück bietet Pi-hole eine Lösung: Über die Gruppenverwaltung kann ich bestimmten Geräten nur einen Basis-Schutz geben, während andere weiterhin von vollständigem Adblocking profitieren. Ich zeige euch, wie ihr eine zusätzliche Gruppe „AdblockLite“ anlegt und bestimmte Geräte dort zuweist.

Die Gruppe „AdblockLite“ anlegen

Um eine neue Gruppe zu erstellen, müsst ihr euch zunächst in die Pi-hole-Weboberfläche einloggen. Diese erreicht ihr über http://pi.hole/admin/. In der Gruppenverwaltung (Group Management) unter Groups könnt ihr nun eine neue Gruppe hinzufügen. Gebt ihr zum Beispiel den Namen „AdblockLite“ und speichert die Änderung. Damit ist der Grundstein für selektives Adblocking gelegt.

Werbeblocker-Listen gezielt zuweisen

Nun gilt es festzulegen, welche Blocklisten für welche Gruppen gelten sollen. In der Gruppenverwaltung findet ihr unter Lists eine Übersicht aller aktivierten Listen. Standardmäßig sind diese für alle Geräte aktiv, doch hier könnt ihr Anpassungen vornehmen.

Entfernt für die Werbeblocker-Listen wie EasyList die Zuweisung zur neuen Gruppe „AdblockLite“, sodass diese nur noch für die Standardgruppe Default aktiv sind. Sicherheitslisten wie Emerging Threats sollten jedoch weiterhin für beide Gruppen gelten, damit alle Geräte im Netzwerk zumindest einen Basisschutz genießen.

Geräte der „AdblockLite“-Gruppe zuweisen

Damit bestimmte Geräte von der neuen Konfiguration profitieren, müssen sie explizit der „AdblockLite“-Gruppe hinzugefügt werden. Dazu navigiert ihr in der Pi-hole-Oberfläche zum Bereich Clients und fügt dort die entsprechenden Geräte per IP-Adresse oder Hostnamen hinzu. Anschließend ordnet ihr diese der Gruppe „AdblockLite“ zu. So wird sichergestellt, dass diese Geräte nicht von den vollständigen Adblocking-Regeln betroffen sind, sondern nur noch den Basis-Schutz erhalten.

Änderungen übernehmen und testen

Nach diesen Anpassungen müssen die neuen Einstellungen wirksam werden. Dazu könnt ihr in der Weboberfläche unter Tools den DNS-Resolver neu starten. Danach sollten die betroffenen Geräte nur noch durch die in „AdblockLite“ aktivierten Listen gefiltert werden. Eventuell muss auch noch einmal kurz die Netzwerkverbindung der betroffenen Rechner getrennt und wieder neu aufgebaut werden.

Fazit

Dank der Gruppenverwaltung in Pi-hole lässt sich das Adblocking individuell steuern. Während einige Geräte weiterhin von maximaler Werbeblockierung profitieren, erhalten andere nur noch einen Basis-Schutz. So kann jeder im Haushalt nach seinen eigenen Vorlieben surfen – und niemand muss sich über verschwundene Werbeanzeigen ärgern. Mit dieser Lösung bleibt das Netzwerk dennoch gegen bekannte Bedrohungen geschützt und bietet gleichzeitig mehr Flexibilität für unterschiedliche Nutzeranforderungen.

Erstmal gilt es die in meinem Netzwerk maximal erzielbare Datenrate auszumessen. Diese Werte sollen später als Referenz dienen, ob die mit der Fritzbox ermitteln Werte auch die Realität abbilden. Dazu hänge ich zwei ausgewachsene Rechner (einen mit Arch und einen mit Ubuntu 15.10) mit Gigabit-Ethernet an die Fritzbox (in meinem Fall eine Fritzbox 7490) und installiere auf beiden Rechner Iperf. Das Programm findet sich bei eigentlich allen Distributionen in den Paketquellen von Linux. Arch Listet neben der Version 2.x bereits auch Iperf3 in den Quellen auf. Achtet darauf, dass die neue Version nicht zu der alten abwärtskompatibel ist und installiert am besten die ältere Ausgabe des Programms. Bei Bedarf gibt es das Programm auch für MacOS X und Windows.

Datenrate im Netz mit Iperf ermitteln

### Iperf unter Ubuntu/Debian installieren...
$ sudo apt install iperf
### Iperf unter Arch Linux installieren...
$ pacman -Ss iperf
community/iperf 2.0.5-9
    A tool to measure maximum TCP bandwidth
community/iperf3 3.1.2-1
    Internet Protocol bandwidth measuring tool
$ pacman -S iperf

Anschließend starte ich Iperf auf einem der Rechner im Server-Modus und auf dem zweiten Computer als Client. Nach wenigen Sekunden spuckt die Client-Seite das Ergebnis aus, dieses erscheint ebenfalls im Log des Iperf-Servers. In meinem Fall erreichen die zwei mit Gigabit-Netzwerkkarten ausgestatteten Rechner an der Fritzbox fast die theoretisch maximale Datenrate. Die 940 MBit/s können sich auf jeden Fall sehen lassen und zeigen, dass mit der Verkabelung alles passt. Nun muss die Fritzbox beweisen, was sie als Iperf-Server zu leisten imstande ist.

$ iperf -s 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.178.80 port 5001 connected with 192.168.178.57 port 36672
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.10 GBytes   941 Mbits/sec

### Iperf-Test via Fritzbox und UDP
$ iperf -c 192.168.178.80
------------------------------------------------------------
Client connecting to 192.168.178.80, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.178.57 port 36672 connected with 192.168.178.80 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.10 GBytes   943 Mbits/sec

Iperf-Server auf der Fritzbox aktivieren

Der Iperf-Server ist nun auf der Fritzbox nicht von Haus aus aktiv. Für den Leistungstest müsst ihr die versteckte Konfigurationsseite der Fritzbox unter http://fritz.box/support.lua aufrufen und dort den Haken bei der Option Messpunkt für einen Iperf-Client im Heimnetz aktivieren, Port 4711 für TCP und UDP setzen und weiter unten auf Einstellungen übernehmen klicken. Auf den zweiten Schalter Messpunkt für einen bidirektionalen Iperf-UDP-Test im Heimnetz aktivieren, Port 4712 für UDP gehe ich später noch ein, erst einmal reicht es lediglich die erste Option zu aktivieren.

Im Gegensatz zum „Standard-Iperf“ lauscht der Fritzbox-Iperf-Server nun nicht auf Port 5001 auf eingehende Verbindungsanfragen sondern auf Port 4711. Von eurem Testrechner müsst ihr als Iperf daher mit der Portangabe -p 4711 starten. Fast schon wie erwartet, zeigt sich bei diesem Test wieder, dass die CPU der Fritzbox (selbst die des aktuellen Top-Modells 7490) für die Verarbeitung von Netzwerkpaketen nicht wirklich geeignet ist. Iperf meldet gerade mal einen Datendurchsatz von 173 MBit/s. Zur Erinnerung: Leitet die Fritzbox die Datenpakete als Switch nur von Rechner zu Rechner weiter, erzielt eine Iperf-Konfiguration bestehend aus zwei Gigabit-Rechnern eine Datenrate von über 940 MBit/s.

### Iperf-Test via Fritzbox und TCP
$ iperf -c 192.168.178.1 -p 4711
------------------------------------------------------------
Client connecting to 192.168.178.1, TCP port 4711
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.178.57 port 57234 connected with 192.168.178.1 port 4711
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   206 MBytes   173 Mbits/sec

Iperf im UDP-Modus zeigt realistisches Ergebnis

Zur Rettung der Ehre der Fritzbox aktiviert ihr nun den zweiten Punkt Messpunkt für einen bidirektionalen Iperf-UDP-Test im Heimnetz aktivieren, Port 4712 für UDP und übernehmt die Einstellung wieder. Damit habt ihr die Möglichkeit die Netzwerkgeschwindigkeit mittels des schlanken User Datagram Protocol kurz UDP zu testen. Bei diesem wird im Gegensatz zu TCP aka Transmission Control Protocol unter anderem keine Bestätigung beim Empfang eines Datenpakets zurück zum Sender geschickt, was unter anderem den Overhead des Protokolls reduziert und die Prozessorlast bei der Übertragung senkt. Schmeißt ihr nun auf eurem Rechner Iperf an, fügt ihr dem Aufruf die Optionen -u für UDP und -b 1000M für die Zielbandbreite von 1 GBit/s an.

$ iperf -c 192.168.178.1 -p 4712 -u -b 1000M
------------------------------------------------------------
Client connecting to 192.168.178.1, UDP port 4712
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.178.57 port 42387 connected with 192.168.178.1 port 4712
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   969 MBytes   813 Mbits/sec
[  3] Sent 691514 datagrams
[  3] WARNING: did not receive ack of last datagram after 10 tries.

In diesem Modus entspricht die von Iperf auf der Fritzbox ermittelte Datenrate von 813 MBit/s deutlich eher der Realität, der Wert liegt aber trotzdem noch rund 14 Prozent unter dem, den ich mit zwei „ausgewachsenen“ Rechnern ermittelt habe. Der in der Fritzbox integrierte Iperf-Server eignet sich daher nicht wirklich für Leistungstests mit Gigabit-Ethernet oder WLAN nach IEEE 802.11ac, das zumindest in der Theorie ähnlich schnelle Datenraten erzielen sollte. In der Praxis liegen die Datenraten von Smartphones und Notebooks trotz WLAN-AC deutlich unter der von Gigabit-Ethernet, sodass hier der Fritzbox-Iperf zumindest vergleichbare Aussagen liefern sollte.

Iperf auf Android-Smartphones und -Tablets

Der in der Fritzbox integrierte Iperf-Server eignet sich daher im Prinzip hauptsächlich dafür den Durchsatz von per WLAN angebundenen Geräten wie Notebooks, Smartphones oder Tablets zu messen. Für Android gibt es daher eine ganze Reihe von Apps, die als Iperf-Client dienen können. Die Homepage des Iperf-Projekts listet dafür eine ganze Reihe von Apps für Android (sowie eines für iOS) auf, doch nicht jede dieser Apps eignet sich für den Fritzbox-Iperf-Server, da dieser nicht auf dem Standard-Port des Protokolls (Port 5001) lauscht und sich der Port in der App anpassen lässt.

FRITZ!App WLAN mit Iperf-Test

1 von 3

In der Praxis bei mir hat sich die FRITZ!App WLAN bewährt. In dieser lässt sich aus der Seitenleiste heraus die Option WLAN messen aufrufen. Die Funktion führt eine ganze Reihe von Tests durch, darunter eben (wenn die Iperf-Option, wie oben im Artikel beschrieben, zuvor in den Fritzbox-Einstellungen aktiviert wurde) auch einen Iperf-Test. Diesen allerdings nur mit der TCP-Option, die generell geringere Datenraten anzeigt. Alternativ könnt ihr zu den kostenlosen Apps Aruba Utilities oder iPerf for Android greifen. In diesen Apps könnt ihr vom PC gewohnten Iperf-Optionen eins zu eins übertragen, was allerdings ein wenig Tipparbeitet auf der virtuellen Smartphone-Tastatur bedeutet.

Aruba Utilities und Iperf for Android

1 von 5

Speedtest für das lokale Netwerk

Einzige Voraussetzung für den Speedtest ist ein Webserver mit PHP oder ASP in eurem lokalen Netzwerk mit einer möglichst optimalen Anbindung — wenn es euer Netzwerk her gibt am besten mit Gigabit-Ethernet. Es macht daher keinen Sinn schwächere SBCs wie etwa einen Raspberry Pi als Testserver zu nutzen oder die Daten in den Online-Speicher einer Fritzbox zu laden. Diese „Server“ liefern einfach zu wenig Durchsatz — gerade der RasPi mit seiner nach wie vor leistungsschwachen Anbindung der Ethernetschnittstelle über USB. Für meinen Test habe ich die Webstation auf einem Synology-NAS aktiviert, das die theoretische Datenrate einer Gigabit-Leitung über NFS ziemlich gut ausreizt. Daher sollten die von Speedtest-Mini ermittelten Daten halbwegs aussagekräftig sein.

Der Mini-Speedtest lässt sich nun nach Registrierung auf der Speedtest-Seite kostenlos herunterladen. Zur Installation müsst ihr die Datei mini.zip entpacken und den Inhalt des Archivs in ein neues Verzeichnis im Webroot eures Webservers laden. Für die PHP-Version nennt ihr dann noch die index-php.html nach index.php um. Anschließend sollte ihr dann die Speedtest-Seite mit einem Browser unter beispielsweise http://diskstation/speedtest aufrufen können. Zum Start des Geschwindigkeitstest klickt ihr dann wie üblich auf die Schaltfläche Begin test. Das Ergebnis des Tests erscheint dann wenige Sekunden später auf dem Bildschirm. Einen kleinen Hacken gibt es allerdings: Der Speedtest braucht zwingend Flash, auf Android-Handys lässt sich der Test auf diesem Weg daher nicht ausführen.

Alternative ohne grafische Oberfläche

Als Alternative könnt ihr aber auch auf das bereits von mir vorgestellte Kommandozeilen-Tool speedtest-cli zurückgreifen. Dieses lässt sich bei einigen Distributionen inzwischen direkt aus den Paketquellen installieren, alternativ aber auch direkt als Binary herunterladen und ohne Installation auf dem System ausführen. Beim Aufruf des Programms könnt ihr dann mit der Option --mini (gefolgt von der URL eures Speedtest-Servers) den Leistungstest eures lokalen Netzwerks ausführen, ohne dass es Flash auf dem System braucht. Bei der Speedtest-App für Android konnte ich leider keinen Weg finden, den Auswahl an Speedtest-Servern um einen lokalen zu ergänzen.

$ speedtest-cli --mini http://diskstation/speedtest/
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Vodafone Kabel Deutschland (178.xx.yyy.z)...
b'Hosted by Speedtest Mini (192.168.178.79) [0.00 km]: 0.873 ms'
Testing download speed........................................
Download: 939.95 Mbit/s
Testing upload speed..................................................

In der Regel wird man für das Scannen des eigenen Netzwerks nach aktiven Rechnern auf den Network Mapper (kurz nmap) und dessen grafischen Aufsätze wie Zenmap zurückgreifen. Das Ergebnis eines solchen Scans führt im Endeffekt schnell zum Ziel, allerdings erhaltet ihr ohne weitere Optionen kaum Hinweise darüber, um was für einen Rechner es sich hier handelt. Möchtet ihr die IP eines frisch aufgesetzten Raspberry Pi mit Raspbian ermitteln, dann müsstet ihr jede unbekannte IP ausprobieren, bis ihr irgendwann mal per Zufall die Adresse des gerade installierten Rechners erwischt. Geistern mehr als nur ein paar Geräte durchs Büro- oder WG-Netz, entwickelt sich aus diesem Vorhaben eine etwas mühsame Arbeit.

Mit Nmap im Netz nach Rechnern scannen

## Nmap unter Debian oder Ubuntu installieren...
$ sudo apt-get install nmap
## Nmap unter Arch Linux installieren...
$ sudo pacman -S nmap

$ nmap -sP 192.168.178.0/24
Starting Nmap 6.47 ( http://nmap.org ) at 2015-11-01 21:33 CET
Nmap scan report for 192.168.178.1
Host is up (0.00054s latency).
Nmap scan report for 192.168.178.21
Host is up (0.000068s latency).
Nmap scan report for fritz.repeater (192.168.178.24)
Host is up (0.0040s latency).
[...]

Um ein wenig mehr über den jeweiligen Rechner zu erfahren, müsst ihr Nmap mit Root-Rechten aufrufen. Die restlichen Parameter könnt ihr unverändert lassen, hier im Beispiel nutze ich etwa mit der Option -sP den recht schnellen Ping-Scan. Diese Ausgabe enthält nun schon deutlich mehr Informationen über die im Netz gefundenen Geräte. Schon alleine die Angabe des Herstellers der Netzwerkkarte reicht in einem nicht übervollen Netz zur Identifikation des gesuchten Geräts, zur Not könnte man auch gezielt nach einer MAC-Adresse suchen — so man diese denn kennt.

$ sudo nmap -sP 192.168.178.0/24
Starting Nmap 6.47 ( http://nmap.org ) at 2015-11-01 21:29 CET
Nmap scan report for 192.168.178.1
Host is up (0.00047s latency).
MAC Address: 08:96:D7:D9:52:E1 (AVM GmbH)
Nmap scan report for 192.168.178.24
Host is up (0.0018s latency).
MAC Address: 3A:31:C4:6D:92:A5 (Unknown)
[...]
MAC Address: B8:27:EB:E4:E1:30 (Raspberry Pi Foundation)
Nmap scan report for samsungprinter.fritz.box (192.168.178.36)
Host is up (0.0013s latency).
MAC Address: 00:15:99:77:47:9B (Samsung Electronics Co.)
Nmap scan report for 192.168.178.42
Host is up (0.079s latency).
[...]
Nmap done: 256 IP addresses (15 hosts up) scanned in 2.92 seconds

Arp-Scan liefert die IPs von Rechnern im Netz

Nmap ist nun nicht das einzige Netzwerktool, mit dem sich das lokale Netzwerk durchsuchen kann. Mit dem Kommandozeilentool Arp-Scan kommt ihr ähnlich schnell zum Ziel. Das Programm sendet sogenannte ARP-Pakete ins Netz (hier die Wikipedia zum Address Resolution Protocol), die sich gut für die Analyse des Netzwerks auswerten lassen. Wer sich tiefer in die Materie einlesen möchte, der findet auf der Homepage des Projekts eine ausführliche Dokumentation. Für die Installation von Arp-Scan müsst ihr in der Regel nicht lange suchen, das Programm findet ihr wie Nmap in den Paketquellen der meisten gängigen Distributionen, daher sollte die Installation keinen großen Aufwand bedeuten.

## Arp-Scan unter Debian oder Ubuntu installieren...
$ sudo apt-get install arp-scan
## Arp-Scan unter Arch Linux installieren...
$ sudo pacman -S arp-scan

Nach der Installation stößt ihr den Netzwerkscan in der Regel direkt mit sudo arp-scan -l an. Dabei findet das Programm automatisch die aktuelle Netzwerkkonfiguration heraus. Sollte dies nicht funktionieren, müsst ihr Arp-Scan ein wenig auf die Sprünge helfen. Öffnet dazu ein Terminal und lasst euch zum Beispiel mit ifconfig die aktuelle Netzwerkkonfiguration ausgeben. Sucht euch anschließend aus der Ausgabe die Karte heraus, die mit „RUNNING“ und einer IP neben „inet“ meldet, dass sie gerade Daten in das Netzwerk funkt. Hier auf meinem System wäre es etwa die Karte „enp0s25“, auf anderen Linux-Systemen nennen sich die Ethernet- und WLAN-Karten gerne „eth0“ oder „wlan0“.

$ ifconfig
enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.111.167 netmask 255.255.255.0 broadcast 192.168.111.255
[...]

Mit dieser Informationen startet ihr nun den Netzwerkscan. Wie der erweiterte Nmap-Scan benötigt auch Arp-Scan zum Senden der ARP-Pakete Root-Rechte. Das Ergebnis des Scans listet wie das mit Root-Rechten gestartete Nmap nicht nur die IPs, sondern auch die MAC-Adresse des Geräts wie auch den Hersteller des Chipsatzes der Netzwerkkarte auf. Somit habt ihr wieder schnell einen für den Betrieb als Headless-Server gedachten Mini-Rechner wie einen Raspberry Pi aus eurem Netzwerk herausgefiltert. Hier bei Arp-Scan funktioniert dies sogar ein ein klein wenig besser, da das Programm die Ausgabe direkt auf eine Zeile beschränkt, sodass man die Ausgabe einfacher per grep filtern kann.

$ sudo arp-scan --interface=enp0s25 --localnet
Interface: enp0s25, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.111.21 52:54:00:cf:04:ae QEMU
192.168.111.40 00:11:6b:c3:4f:d1 Digital Data Communications Asia Co.,Ltd
192.168.111.132 f0:de:f1:9d:80:57 Wistron InfoComm (Kunshan)Co
192.168.111.137 b8:27:eb:7c:5f:e1 Raspberry Pi Foundation
192.168.111.141 c4:6e:1f:9e:4a:b9 (Unknown)
192.168.111.142 50:b7:c3:8a:7d:d5 Samsung Electronics CO., LTD
[...]
$ sudo arp-scan -l | grep Raspberry
192.168.111.137 b8:27:eb:e4:e1:30 Raspberry Pi Foundation
192.168.178.250 b8:27:eb:7c:5f:e1 Raspberry Pi Foundation

Zenmap und der Angry IP Scanner scannen mit GUIs

Bei den hier vorgestellten Beispielen habe ich ganz bewusst auf grafische Tools verzichtet, da Nmap und Arp-Scan wunderbar im Terminal funktionieren und man so eine Aufgabe sowieso nicht jeden Tag durchführt — wozu also eine GUI bemühen. Wer allerdings lieber mit einem grafischen Werkzeug arbeitet, der muss auf ein solches Tool nicht unbedingt verzichten. Startet ihr das Nmap-Frontend Zenmap (bei Debian/Ubuntu über das Paket zenmap zu installieren, bei Arch hingegen direkt im Paket von nmap enthalten), dann reicht schon ein Scan mit dem Profil Quick scan, um sämtliche Daten zur Netzwerkkonfiguration und den aktiven Diensten anzuzeigen.

Ein wenig leichter habt ihr es mit dem Angry IP Scanner. Diesen bekommt ihr unter Ubuntu nicht aus den Paketquellen, als Java-Anwendung müsstet ihr das Programm allerdings nur aufrufen. Weitere Installationshinweise gibt euch das Ubuntu-Wiki. Unter Arch findet ihr das Programm auch noch nicht in den Quellen. Allerdings hilft euch das AUR weiter, dort findet ihr das Programm unter dem Eintrag ipscan. Wie Nmap brauch auch der Angry IP Scanner Root-Rechte. Habt ihr das Programm entsprechend aufgerufen, fügt ihr im Menü unter Werkzeuge | Fetcher mindestens den MAC Hersteller hinzu, gebt den zu untersuchenden IP-Bereich an und legt los — Ein kleiner Vorteil des Programms: Den Angry IP Scanner gibt es auch für MacOS X und Windows.

Ganz schick ist daher die kleine App Diskovery, die man sich kostenlos aus dem Play Store installieren kann. Diskovery ist im Endeffekt nichts anderes, als ein Samba-Server, der seine Präsenz mittels Avahi/Zeroconf im lokalen Netzwerk meldet. So taucht das Handy dann automatisch auf Macs im Finder unter den Freigaben auf, wenn diese im selben Netzwerk angemeldet sind. Per Login und Passwort lässt sich zudem verhindern, dass Unbefugte auf das Handy Zugriff bekommen.

Ganz kostenlos ist Diskovery allerdings nicht, auch wenn man die App erst einmal ohne Gebühren aus dem Play Store installieren kann. Den nicht ganz unwichtigen Schreibzugriff gibt es nur dann, wenn man diesen per 0,99 Euro teurem In-App-Kauf freischaltet. Für Linuxer eignet sich Diskovery leider nicht wirklich, mehr als eine Reihe von Fehlermeldungen erhält man beim Zugriff nicht. Als Alternative gibt es jedoch zahlreiche FTP– oder SSH-Server für Android, und zur Not auch noch Airdroid und Co. Von daher lässt sich die Inkompatibilität verschmerzen.

Im Folgenden gehe ich von diesem Szenario aus. Ein Laptop ist per WLAN mit dem DSL-Router im Nebenzimmer verbunden. Neben dem Laptop steht ein weiterer Rechner ohne WLAN. Dieser soll per Crossover-Kabel an den Laptop angeschlossen werden und dann über das Laptop ins Internet gehen. Die nötigen Einstellungen müsst Ihr nun am „Internet-Rechner“ vornehmen.

Die benötigte Funktion ist von Haus aus im NetworkManager eingebaut. In aktuellen Ubuntu-Versionen (wenn ich mich nicht irre, müsste Ubuntu Intrepid Ibex 8.10 die erste Version sein, die diese ICS-Funktion kennt) öffnet Ihr dazu die Einstellungen des NetworkManagers über einen Rechtsklick auf das NM-Icon im Panel und die Option „Verbindungen bearbeiten“.

Hier wählt ihr die Netzwerkschnittstelle, die mit dem anderen Rechner verbunden ist, aus. Zugegeben, das ist etwas verwirrend… Hängt ihr also per Laptop und WLAN am DSL-Router und möchtet den per Crossover-Kabel verbundenen Desktop-Rechner ins Netz bringen, dann gebt ihr nicht die WLAN-Verbindung des Laptops frei, sondern dessen kabelgebundenen Netzwerkkarte. Wählt hier in den IPv4-Einstellungen die Option „Gemeinsam mit anderen Rechnern“ aus.

Sobald Ihr diesen Dialog mit „Anwenden“ geschlossen habt, könnt Ihr das Crossover-Kabel zwischen Laptop und Desktop anschließen. Habt Ihr die Netzwerkkonfiguration des Desktops nicht geändert, dann müsste dieser nun automatisch via DHCP die Netzwerkdaten bekommen und ins Internet gehen können.

Theoretisch müsste sich die selbe Vorgehensweise auch mit zwei Laptops, von denen einer per UMTS im Internet hängt und der andere per WLAN die UMTS-Verbindung des ersten Laptops verwendet, wiederholen lassen. Doch mangels UMTS-Adapter kann ich das nicht testen.

Generell eignet sich die Internetfreigabe per NetworkManager gut für eine „schnelle“ und vorübergehende Aktion. Solltet ihr Euren eigenen Hardware-Router aufsetzen, dann würde ich nicht diesen Weg gehen, da der NM die Verbindungen nur aufbaut, wenn ein Benutzer eingeloggt ist.

Im UMTS-Netz von Vodafone werden nach Informationen von zdnet seit Juli 2009 DNS-Anfragen auf Port 53 zwangsweise auf die eigenen DNS-Server umgeleitet, so kann der Provider garantieren dass die eigenen DNS-Server nicht umgangen werden können, selbst wenn Anwender alternative DNS-Server einstellen. Es ist nur eine Frage der Zeit, bis dieser Feldtest auf die DSL-Anschlüsse des Anbieters ausgeweitet wird. Netzneutralität ade… Hallo Zensurstaat!

Wer nun meint, dass Pädophilen somit tatsächlich der Zugang zu einschlägig bekannten Domains unmöglich gemacht wird, der irrt. Es macht nur ein bisschen mehr Arbeit… Löschen statt Sperren wäre immer noch der einzig richtige Ansatz, aber das würde ja Geld kosten und den Bestrebungen unserer Regierung, Deutschland zu einem Überwachungsstaat auszubauen, nicht so gut ins Spiel passen…

Zwar kann man in den Netzwerkeinstellungen aller gängigen Betriebssysteme die DNS-Einstellungen schnell ändern, doch den Port – über den die DNS-Anfragen laufen sollen – zu wechseln, ist meist nicht möglich. Versucht man dies etwa mit Ubuntu und dem NetworkManager, so weigert sich der NM die Einstellungen zu übernehmen.

Um die Zensurmaßnahme der Frau von der Leyen zu umgehen ist jedoch nur ein eigener DNS-Server nötig, denn bei beispielsweise bind9 ist es völlig problemlos möglich höhere DNS-Server über andere Ports als Port 53 abzurufen. Der Artikel auf zdnet geht ausführlich auf Windows als Betriebssystem ein und streif Linux nur kurz, ich ziehe das Pferd mal von der Ubuntu oder Debian Seite auf.

Installation von bind9

Die Installation kann auf Eurem Internet-Router oder auch auf Eurem Desktop erfolgen, als DNS-Server bietet sich bind9 an:sudo apt-get install bind9. Nach der Installation des Paketes, könnt Ihr an die die Konfiguration von bind9 gehen. Ihr müsst nur die Konfigurationsdatei /etc/bind/named.conf.options bearbeiten, alles andere ist eigentlich schon passend vorkonfiguriert.

$ sudo nano /etc/bind/named.conf.options

Dort können nun die vom eigenen DNS-Server zu nutzenden nicht zensierenden DNS-Server der German Privacy Foundation e.V., des FoeBuD e.V. oder des Chaos Computer Club e.V. eingetragen werden. Eine Liste mit unzensierten Servern findet sich auf den Seite der Privacy Foundation e.V. oder auf wikileaks.org. Die Einträge müssen letztendlich so ähnlich aussehen.

options {
[...]
        forward only;
        forwarders {
                87.118.100.175 port 110;
                62.141.58.13 port 110;
                87.118.104.203 port 110;
        };
[...]
};

Natürlich könnt Ihr einen Server Eurer Wahl verwenden. Die Portangabe ist bislang nur im UMTS-Netz von Vodafone nötig. Wer verhindern möchte, dass der DNS-Server von anderen Rechnern im lokalen Netzwerk angesprochen werden kann, der sollte noch die allow-query Option setzen.

options {
[...]
        allow-query { localhost; };
[...]
};

Dadurch ist bind9 vollständig eingerichtet, ein Neustart von bind9 mit sudo /etc/init.d/bind9 restart liest die neue Konfiguration ein, so dass die gerade getroffenen Einstellungen aktiv werden.

Eigenen DNS-Server im System verankern

Nun muss nur noch verhindert werden, dass das System die vom Internetprovider vermittelten DNS-Server verwendet, sondern brav den eigenen DNS-Server benutzt.

Bei DSL und pppoeconf

Solltet Ihr einen eigenen Rechner als Router benutzen, der via pppoeconfig die DSL-Verbindung aufbaut, oder Euren Desktop-Rechner direkt an das DSL-Modem angeschlossen haben und ebenfalls pppoeconf nutzen, so würde ich die zu nutzenden DNS-Server über resolvconf bestimmen. Dazu installiert Ihr das benötigte Paket…

$ sudo apt-get install resolvconf

…und bearbeitet die Datei /etc/network/interfaces.

$ sudo nano /etc/network/interfaces

Hier tragt Ihr die IP des eigenen DNS-Servers ein über die Option „dns-nameservers“ ein. Sollte der Einwahlrechner identisch mit dem DNS-Server sein, so reicht der Eintrag der IP des localhosts.

[...]
auto dsl-provider
iface dsl-provider inet ppp
pre-up /sbin/ifconfig eth1 up # line maintained by pppoeconf
provider dsl-provider
dns-nameservers 127.0.0.1
[...]

Nach einem Neustart der Netzwerkeinstellungen über $ sudo /etc/init.d/networking restart sollten die Einstellungen korrekt sein. In der Datei /etc/resolv.conf wird der zu benutzende Nameserver stehen.

$ grep nameserver  /etc/resolv.conf
nameserver 127.0.0.1

Die DNS-Server Eures DSL-Anbieters dürfen hier nicht mehr gelistet werden.

Mit dem NetworkManager

Sollte man den NetworkManager zum Verbindungsaufbau benutzen, so würde ich persönlich nicht die /etc/network/interfaces anpassen. Klickt ihr mit der rechten Maustaste auf das Icon des NetworkManagers im Panel, so seid Ihr in der Lage Eure Netzwerkeinstellungen zu konfigurieren. Dort könnt ihr auch die zu benutzenden DNS-Server einstellen. Wieder tragt ihr die IP eures DNS-Servers ein.

Wird der eigene DNS-Server auch benutzt?

Jetzt solltet Ihr noch überprüfen, ob der eigene Nameserver auch wirklich benutzt wird. Mittels dig könnt ihr die DNS-Einträge einer Domain bestimmen. Ihr bekommt auch gesagt von welchem DNS-Server diese stammen. In meinem Fall läuft der Nameserver auf dem eigenen Rechner, somit kommt die Antwort vom localhost.

$ dig linuxundich.de
[...]
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Sep 28 13:19:53 2009
;; MSG SIZE  rcvd: 168

Bislang kommunizierten Rechner auf denen der Dropbox-Client installiert wurde ausschließlich über das Internet miteinander. Schob man auf RechnerA eine Datei in den Dropbox-Ordner, so lud Dropbox die Datei automatisch zu Dropbox hoch. Auf RechnerB wurde diese Datei dann wieder über das Internet von Dropbox heruntergeladen. Dies ändert sich mit der nächsten Dropbox-Version, die man schon jetzt als Beta ausprobieren kann.

RechnerA lädt die Datei natürlich immer noch zu Dropbox hoch, doch RechnerB, der den selben Dropbox-Account benutzt und im selben Netzwerk wie RechnerA steht, zieht die Datei direkt von RechnerA und nicht mehr aus dem Internet. Somit spart man sich Internet-Traffic und natürlich läuft die Synchronisierung der Daten von Rechner zu Rechner deutlich schneller.

Die neue Version bekommt man für Linux, Apple und natürlich auch Windows aus dem Dropbox-Forum, bitte beachtet das Dropbox diese Version als „Highly Experimental Build“ ansieht, seid also auf Fehler gefasst… Wer Dropbox bislang noch nicht installiert hat, der sollte zuerst Dropbox in der aktuellen offiziellen Version installieren, die „unstable“-Archive enthalten nur den Dropbox-Client und nicht das Nautilus-Plugin. Hat man das Archiv heruntergeladen, so sollte man Dropbox stoppen…

Danach kann man den alten Dropbox-Client löschen und die gerade heruntergeladene 0.7.x Version installieren. Liegt das .tar.gz Archiv beispielsweise auf dem Desktop, so muss man einfach nur die Befehle…

$ rm -rf ~/.dropbox-dist/
$ tar -xzf ~/Desktop/dropbox-lnx.*.tar.gz -C ~/

…ausführen. Anschließend kann man Dropbox wieder über Anwendungen -> Internet -> Dropbox aus dem Menü heraus starten. Am Programm selber hat sich nun nicht mehr viel geändert. Die P2P-Funktionalität taucht nirgendwo direkt auf. Man merkt sie beispielsweise, wenn man einen neuen Rechner zum eigenen Account hinzufügt und eine größere Menge an Daten transferiert wird. Ist ein weiterer Rechner mit diesem Account im LAN, dann trudeln die Daten mit mehreren MB/s ein…

Man kann dies aus der Statusanzeige des Dropbox-Menüs erkennen. Wenn auf einmal Datenraten erzielt werden, die über den eigenen Internetzugang nicht möglich wären, dann klappt die Synchronisation von Rechner zu Rechner.

Die Slug selber besitzt zwar keine Soundkarte, doch es gibt mittlerweile USB-Soundkarten die nicht mehr als ein paar Euro kosten. Ich hab auf gut Glück einen DIGITUS USB Audio Controller erstanden und siehe da, das Ding funktioniert bei Debian Lenny oder auch Ubuntu Intrepid Ibex…

root@nslu2:~$ tail -f /var/log/messages
Feb 17 18:02:09 nslu2 kernel: [43362489.130000] usb 2-1: new full speed USB device using ohci_hcd and address 2
Feb 17 18:02:09 nslu2 kernel: [43362489.320000] usb 2-1: configuration #1 chosen from 1 choice
Feb 17 18:02:09 nslu2 kernel: [43362489.350000] usb 2-1: New USB device found, idVendor=0d8c, idProduct=0103
Feb 17 18:02:09 nslu2 kernel: [43362489.350000] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb 17 18:02:09 nslu2 kernel: [43362489.360000] usb 2-1: Product: C-Media USB Audio       
Feb 17 18:02:09 nslu2 kernel: [43362489.370000] usb 2-1: Manufacturer: C-Media INC.
Feb 17 18:02:12 nslu2 kernel: [43362491.840000] usbcore: registered new interface driver snd-usb-audio

root@nslu2:~$ cat /proc/asound/cards 
 0 [default        ]: USB-Audio - C-Media USB Audio       
                      C-Media INC. C-Media USB Audio        at usb-0000:00:01.1-1, full speed

out-of-the-box, es wird also auch an der Slug funktionieren… Einen kleinen Hinweis am Rande. Ich habe meine Slug DeUnderclocked, also den Widerstand, der ältere Slugs auf die halbe Taktrate einbremst, entfernt. Da PulseAudio etwas Performance braucht und die Slug davon nicht gerade viel hat, ist dies ein wichtiger Punkt…

Im folgenden Versuche ich euch an die Hand zu nehmen und PulseAudio auf der Slug zu installieren, so dass ihr Sound von einem anderen Linux-Rechner über PA zur Slug, die ihr natürlich an eine Stereoanlage oder gute Boxen angeschlossen habt, umleiten könnt. Als erstes müssen eine Reihe von Paketen installiert werden…

root@nslu2:~$ apt-get install --no-install-recommends alsa-utils libasound2-plugins pulseaudio pulseaudio-module-zeroconf pulseaudio-utils alsa-utils libasound2-plugins hal pulseaudio-module-hal

Damit nicht halb GNOME mitinstalliert wird, benutze ich die Option --no-install-recommends, so werden die empfohlenen Abhängigkeiten nicht mit installiert. Als nächstes muss man den eigenen Benutzer auf der Slug zu den passenden Gruppen hinzufügen.

root@nslu2:~$ adduser $USER pulse
root@nslu2:~$ adduser $USER pulse-access
root@nslu2:~$ adduser $USER pulse-rt
root@nslu2:~$ adduser $USER audio

Danach muss man sich von der Slug abmelden und über SSH wieder einloggen, damit die Gruppenzugehörigkeiten auch aktiv werden. Im nächsten Schritt müssen Endgeräte für Pulseaudio angelegt werden. Dies erfolgt in der Datei /etc/asound.conf. In diese muss der Inhalt…

pcm.pulse {    
        type pulse
}    
ctl.pulse {
        type pulse
}
pcm.!default {
        type pulse
}
ctl.!default {
        type pulse
}

…eingefügt werden. Nun muss man PulseAudio etwas in die Schranken weisen. PA kann eine Menge Performance schlucken. Performance, die auf einer Slug gar nicht vorhanden ist. Würde man jetzt PA starten, so würde man gar keinen oder nur sehr stotternden Sound hören. PulseAudio kennt dazu Qualitätsstufen, die über /etc/pulse/daemon.conf eingestellt werden können. Mit

[...]
resample-method = speex-float-0
[...]

sollte PA beim Abspielen rund 20% Last erzeugen und somit die Slug nicht allzusehr auslasten. Wer immer noch stotternden Sound bekommt, der kann

[...]
resample-method = trivial
[...]

einstellen, was jedoch auch die geringste Qualität bedeutet. Nun kann man PA zum ersten mal starten.

me@nslu2:~$ pulseaudio
W: main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted
W: main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted
ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL front:0

Die Meldungen dabei kann man ignorieren. Spielt man jetzt einen Klang von einem zweiten SSH-Terminal aus ab…

me@nslu2:~$ aplay /usr/share/sounds/alsa/Front_Right.wav

…sollte man den Sound aus den angeschlossenen Boxen der Slug hören. Nun geht es weiter zur Netzwerkkonfiguration von PulseAudio. Wie eingangs erwähnt und in diesem Beitrag beschrieben kann PulseAudio den Audiostream einer Anwendung von einem PA-Server zum nächsten leiten. So kann man Musik auf dem kleinen Netbook abspielen und der PA-Server auf der Slug spielt diese dann über die angeschlossene Stereoanlage ab. Damit dies möglich ist, müssen in der /etc/pulse/default.pa die dafür nötigen Module module-zeroconf-publish und module-native-protocol-tcp aktiviert werden

[...]
### Network access (may be configured with paprefs, so leave this commented
### here if you plan to use paprefs)
#load-module module-esound-protocol-tcp 
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/16
load-module module-zeroconf-publish 
[...]

Bei module-native-protocol-tcp kann man gleich noch einen IP-Bereich festlegen, der den PA-Server ansprechen darf. Nun ist PA fertig konfiguriert, es fehlt nur noch eine Einstellung dass PA beim Starten der Slug anläuft. Dies macht man über die /etc/default/pulseaudio. Hier muss der Start als „Daemon“…

# Start the PulseAudio sound server in system mode.
# (enables the pulseaudio init script)
# System mode is not the recommended way to run PulseAudio as it has some
# limitations (such as no shared memory access) and could potentially allow
[...]
# System->Preferences->Sound). For other sessions, you can simply start
# PulseAudio with "pulseaudio --daemonize".
# 0 = don't start, 1 = start
PULSEAUDIO_SYSTEM_START=1
[...]

..aktiviert werden. Nun kann man PulseAudio über /etc/init.d/pulseaudio restart starten und stoppen. Ab jetzt kann man wie hier beschrieben Sounds vom eigenen Rechner auf die Slug umleiten und ordentlichen Sound auch aus der kleinsten Kiste bekommen.

Das war das „Howto“, aber wie gut funktioniert es? PulseAudio fordert die Slug schon deutlich. Solange die Slug sonst nichts zu tun hat funktioniert es auch richtig gut. Doch ist bspw. zur selben Zeit ein Dateitransfer via Samba oder NFS aktiv, so kommt der Sound schon ins Stocken. Als „reiner“ Soundserver ist die Slug schon so zu gebrauchen, doch wenn man eine Eierlegendevollmilchsau sucht, so liegt man mit der NLUS2 falsch.