Die naheliegende Lösung: /etc/fstab plus ein Dispatcher-Skript für NetworkManager, das anhand von SSID oder Server-Erreichbarkeit automatisch mountet. Klingt nach einer Feierabend-Sache. Ist es aber nicht ganz – ich bin dabei über drei Stolperfallen gestolpert, die einem erst auffallen, wenn der Rechner runterfährt, aufwacht oder in den Standby soll. Genau die drei nehme ich hier mit euch durch.

Getestet habe ich das Ganze auf Arch Linux, aber das Setup ist nicht Arch-spezifisch: Solange eure Distribution systemd und NetworkManager mitbringt – also etwa auch Fedora, Ubuntu, Debian oder openSUSE –, funktioniert alles hier eins zu eins.

Der Grundaufbau

Netzwerkfreigaben bekommen in der fstab klassischerweise noauto, damit sie beim Boot nicht sofort, sondern erst bei Bedarf eingehängt werden:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0

Für den Mount-Typ selbst gibt’s je nach Protokoll gute Anleitungen im Arch Wiki, etwa zu Samba/CIFS und zu davfs2 für WebDAV – beide funktionieren unabhängig von der Distribution, solange cifs-utils beziehungsweise davfs2 installiert sind.

Das eigentliche Mounten übernimmt dann ein Skript unter /etc/NetworkManager/dispatcher.d/. NetworkManager ruft solche Skripte bei jeder Verbindungsänderung auf und übergibt Interface und Status (up, down, pre-down und ein paar weitere) mit – alle Details dazu stehen in der NetworkManager-dispatcher-Manpage. Ein simples Skript prüft die aktive WLAN-SSID und mountet, wenn’s passt:

#!/bin/bash
IFACE="$1"
STATUS="$2"

case "$STATUS" in
    up)
        SSID=$(nmcli -t -f active,ssid dev wifi | awk -F: '$1 == "yes" {print $2; exit}')
        if [[ "$SSID" == "MeinHeimnetz" ]]; then
            mount /mnt/server/home
            mount /mnt/server/data
        fi
        ;;
    down)
        umount /mnt/server/home
        umount /mnt/server/data
        ;;
esac

Fertig, oder? Nicht ganz. Sobald ihr das System runterfahrt, aus dem Standby weckt oder in den Standby schickt, zeigt sich, dass die Sache Tücken hat.

Warum nicht einfach GVfs?

Ihr fragt euch jetzt vielleicht, wieso ich mir das mit fstab und Dispatcher-Skripten überhaupt antue – GNOME bietet über „Mit Server verbinden“ im Dateimanager doch einen viel einfacheren Weg, Netzwerkfreigaben per SMB oder WebDAV einzubinden. Genau da liegt für mich das Problem.

Solche Mounts laufen nicht über den Kernel, sondern über GVfs, GNOMEs virtuelles Dateisystem. Programme, die die GIO-Bibliothek nutzen – fast alle GTK-Anwendungen, allen voran der Dateimanager selbst –, sprechen Freigaben direkt über eigene URIs wie smb:// oder dav:// an und zeigen entsprechend auch Vorschaubilder und Metadaten korrekt an. Für Programme, die das nicht können, blendet GVfs die Freigabe zusätzlich unter /run/user/<uid>/gvfs als ganz normalen Pfad ein. Diese Brücke läuft tatsächlich über FUSE – GVfs selbst ist zwar kein klassisches FUSE-Dateisystem, sondern eine eigene Architektur mit Daemon-Prozessen pro Protokoll, stellt aber genau für diesen Fall über gvfsd-fuse einen POSIX-kompatiblen Pfad bereit.

Genau diese Brücke ist bei mir der Knackpunkt: Nicht jedes Programm kommt damit zuverlässig klar. Konkret zeigt sich das bei mir in einem Markdown-Editor, in den ich auch Bilder für Artikel einbinde. Der Dateimanager zeigt die Bilder auf dem Netzlaufwerk ganz normal an, weil er GVfs nativ spricht. Der Markdown-Editor dagegen zeigt für dasselbe Bild nur einen Platzhalter – die Einbindung über den FUSE-Pfad funktioniert schlicht nicht zuverlässig, obwohl die Datei nachweislich da ist.

Ein klassischer Kernel-Mount über CIFS oder davfs2, wie im Rest dieses Artikels beschrieben, taucht dagegen als ganz normaler, stabiler POSIX-Pfad im Dateisystem auf – ohne Sonderbehandlung, für jedes Programm gleich. Der Mehraufwand mit fstab und Dispatcher-Skripten zahlt sich also gerade dann aus, wenn ihr Freigaben nicht nur im Dateimanager, sondern in ganz unterschiedlichen Anwendungen zuverlässig nutzen wollt.

Problem 1: Der Rechner fährt nicht mehr sauber runter

Fehlt in der fstab die Option _netdev, weiß systemd nicht, dass es sich hier um eine Netzwerkfreigabe handelt. Beim Shutdown kann es dann passieren, dass systemd versucht auszuhängen, nachdem das Netzwerk schon weg ist – der umount blockiert, bis der Job-Timeout greift, und euer System hängt beim Herunterfahren fest.

_netdev behebt das, weil systemd damit die richtige Reihenfolge kennt: erst aushängen, dann Netzwerk kappen. Wichtig ist außerdem, dass ein Dispatcher-Skript nicht nur auf down, sondern auf pre-down reagiert – der Status feuert, bevor die Verbindung wirklich fällt, während down schon danach kommt und für ein sauberes Aushängen zu spät ist. Damit das klappt, braucht es zusätzlich einen Symlink im Unterordner pre-down.d/.

Problem 2: Nach dem Aufwachen hängt sich der Dateimanager auf

Ein mount-Aufruf für CIFS oder WebDAV läuft im Kernel und kann bei nicht erreichbarem Server ziemlich lange blockieren – gerade kurz nach dem Aufwachen, wenn DNS oder Routing noch nicht ganz da sind. NetworkManager wartet standardmäßig synchron, bis so ein Dispatcher-Skript fertig ist, bevor es weitermacht. Hängt der mount-Aufruf, hängt bei euch plötzlich auch der Dateimanager oder die Netzwerkanzeige, weil die vom Verbindungsstatus abhängen.

Die Lösung: Mount-Versuche einfach im Hintergrund laufen lassen, damit das Dispatcher-Skript selbst sofort zurückkehrt, egal wie lange der eigentliche Mount braucht.

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

Problem 3: Der Standby funktioniert plötzlich nicht mehr

Und hier wird’s spannend. Mit der Lösung aus Problem 2 stolpert ihr in ein neues, deutlich fieseres Problem, das sich in meinem Fall so äußerte: Der Bildschirm geht aus, aber Tastaturbeleuchtung und LEDs bleiben an – ihr müsst hart abschalten. Was war passiert?

Der mount-Syscall für CIFS oder davfs blockiert bei nicht erreichbarem Server im sogenannten D-Zustand (uninterruptible sleep) – einem Zustand, den kein Signal unterbricht, auch SIGKILL nicht. Bevor der Kernel sich tatsächlich schlafen legt, versucht er, alle Prozesse einzufrieren. Ein Prozess im D-Zustand lässt sich aber nicht einfrieren, und der ganze Standby hängt fest, bis die Netzwerkoperation im Kernel von selbst aufgibt – das kann durchaus ein paar Minuten dauern.

Weil die Mount-Versuche aus Problem 2 jetzt länger im Hintergrund weiterlaufen, steigt eben auch die Chance, dass genau in dem Moment, in dem ihr in Standby gehen wollt, so ein blockierender Verbindungsversuch gerade aktiv ist.

Der zuverlässige Ausweg: Vor jedem mount erst mit einem echten Userspace-Verbindungstest prüfen, ob der Server überhaupt erreichbar ist – so einer lässt sich per Timeout wirklich abbrechen, zum Beispiel über Bashs eingebautes /dev/tcp:

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

Nur wenn der Test klappt, folgt der eigentliche mount. Damit landet ihr so gut wie nie mehr im riskanten, blockierenden Kernel-Connect, weil ihr zu dem Zeitpunkt schon wisst, dass der Server da ist.

Die Kombination, die bei mir funktioniert

Am Ende braucht ein robustes Setup vier Zutaten:

• _netdev in der fstab, damit systemd Netzwerkfreigaben beim Herunterfahren richtig einordnet.
• pre-down-Handling samt Symlink in pre-down.d/, damit das Aushängen garantiert vor dem Verbindungsabbau passiert – mit Timeout und Lazy-Unmount als Backup, falls der normale umount mal zickt.
• Asynchrone Mounts im up-Fall, damit NetworkManager und alles, was davon abhängt, nicht blockiert.
• Ein Erreichbarkeitstest vor jedem mount, damit der eigentliche, potenziell blockierende Kernel-Connect gar nicht erst passiert.

Dazu noch ein kleiner Healthcheck per systemd-Timer, der ein paar Minuten nach dem Boot und danach regelmäßig nachschaut, ob die Freigaben wirklich da sind, und notfalls nachhilft. Praktisch, falls der auslösende Netzwerk-Event mal zu früh oder zu spät kommt.

Alle Dateien im Überblick

Damit ihr das Ganze direkt nachbauen könnt, hier der komplette Satz an Dateien. Ich habe die Beispielnamen aus meinem eigenen Setup (ein Samba-Server namens bender, WebDAV via tuxedo) durch generische Platzhalter ersetzt – die müsst ihr natürlich an eure eigene Umgebung anpassen.

/etc/fstab – die beiden Freigaben, einmal Samba, einmal WebDAV:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
https://cloud.example.com/remote.php/dav/files/user /mnt/webdav davfs noauto,_netdev,uid=1000,gid=100,x-systemd.automount,x-systemd.idle-timeout=300,x-systemd.mount-timeout=15s 0 0

Die fstab referenziert die Zugangsdaten nur, gespeichert werden sie in eigenen Dateien – schon damit das Passwort nicht im Klartext in einer Datei steht, die jeder lesen kann.

/etc/samba/server.credentials – Zugangsdaten für die Samba-Freigabe:

username=maxmuster
password=GeheimesPasswort123

/etc/davfs2/secrets – Zugangsdaten für die WebDAV-Freigabe, referenziert wird hier der Mountpunkt statt einer Option in der fstab:

/mnt/webdav maxmuster GeheimesPasswort123

Beide Dateien gehören root und dürfen für niemand sonst lesbar sein:

$ sudo chmod 600 /etc/samba/server.credentials /etc/davfs2/secrets
$ sudo chown root:root /etc/samba/server.credentials /etc/davfs2/secrets

/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh – die gemeinsame Bibliothek, die alle anderen Skripte einbinden:

#!/bin/bash
log() {
    [[ "$DEBUG" == "1" ]] && logger -t "$LOG_TAG" -- "$1"
}

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

mount_with_retry() {
    local MOUNT="$1"
    local MAX_ATTEMPTS="${2:-3}"
    local SLEEP_SECONDS="${3:-2}"
    local MOUNT_TIMEOUT="${4:-10}"

    if mountpoint -q "$MOUNT"; then
        log "$MOUNT ist bereits eingehängt"
        return 0
    fi

    log "Hänge $MOUNT ein"

    local OUT ATTEMPT
    for ((ATTEMPT = 1; ATTEMPT <= MAX_ATTEMPTS; ATTEMPT++)); do
        if OUT=$(timeout "${MOUNT_TIMEOUT}s" mount "$MOUNT" 2>&1); then
            log "$MOUNT erfolgreich eingehängt"
            return 0
        fi
        log "Versuch $ATTEMPT/$MAX_ATTEMPTS für $MOUNT fehlgeschlagen (evtl. Timeout nach ${MOUNT_TIMEOUT}s): $OUT"
        [[ "$ATTEMPT" -lt "$MAX_ATTEMPTS" ]] && sleep "$SLEEP_SECONDS"
    done

    log "Alle Versuche für $MOUNT fehlgeschlagen"
    return 1
}

umount_with_fallback() {
    local MOUNT="$1"
    local TIMEOUT_SECONDS="${2:-5}"

    if ! mountpoint -q "$MOUNT"; then
        log "$MOUNT ist nicht eingehängt"
        return 0
    fi

    log "Hänge $MOUNT aus"

    if timeout "${TIMEOUT_SECONDS}s" umount "$MOUNT"; then
        log "$MOUNT erfolgreich ausgehängt"
        return 0
    fi

    log "Normaler Unmount von $MOUNT fehlgeschlagen, versuche Lazy Unmount"
    if umount -l "$MOUNT"; then
        log "$MOUNT per Lazy Unmount ausgehängt"
        return 0
    fi

    log "$MOUNT konnte nicht ausgehängt werden"
    return 1
}

/etc/NetworkManager/dispatcher.d/90-server-mount – Samba-Freigabe, gebunden an eine bestimmte WLAN-SSID oder ans Kabelnetz:

#!/bin/bash

DEBUG=1
LOG_TAG="server-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTS=(
    "/mnt/server/home"
    "/mnt/server/data"
)

mount_server() {
    if ! tcp_reachable server 445 2; then
        log "server auf Port 445 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    for MOUNT in "${MOUNTS[@]}"; do
        mount_with_retry "$MOUNT" 3 2 10
    done
}

umount_server() {
    for MOUNT in "${MOUNTS[@]}"; do
        umount_with_fallback "$MOUNT" 5
    done
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        if [[ "$IFACE" == wl* ]]; then
            SSID=$(nmcli -t -f active,ssid dev wifi |
                awk -F: '$1 == "yes" {print $2; exit}')

            log "Aktive WLAN-SSID: $SSID"

            if [[ "$SSID" == "MeinHeimnetz" ]]; then
                run_async mount_server
            fi

        elif [[ "$IFACE" == enp* || "$IFACE" == eth* ]]; then
            run_async mount_server
        fi
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mounts aushängen"
        umount_server
        ;;
esac

log "Dispatcher beendet"
exit 0

/etc/NetworkManager/dispatcher.d/90-webdav-mount – WebDAV-Freigabe, die einfach nur einen erreichbaren Cloud-Server voraussetzt:

#!/bin/bash

DEBUG=1
LOG_TAG="webdav-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTPOINT="/mnt/webdav"
HOST="cloud.example.com"

mount_webdav() {
    if ! tcp_reachable "$HOST" 443 3; then
        log "$HOST auf Port 443 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    mount_with_retry "$MOUNTPOINT" 3 2 10
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        run_async mount_webdav
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mount aushängen"
        umount_with_fallback "$MOUNTPOINT" 5
        ;;
esac

log "Dispatcher beendet"
exit 0

Für beide Skripte braucht ihr zusätzlich noch die passenden Symlinks, damit pre-down garantiert vor dem Verbindungsabbau feuert:

$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-server-mount 
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-server-mount
$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-webdav-mount 
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-webdav-mount

/usr/local/bin/mount-healthcheck.sh – das Sicherheitsnetz, das regelmäßig nachschaut:

#!/bin/bash
DEBUG=1
LOG_TAG="mount-healthcheck"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

log "Healthcheck gestartet"

SSID=$(nmcli -t -f active,ssid dev wifi 2>/dev/null |
    awk -F: '$1 == "yes" {print $2; exit}')

if [[ "$SSID" == "MeinHeimnetz" ]] || ping -c 1 -W 1 server >/dev/null 2>&1; then
    mount_with_retry "/mnt/server/home" 2 3
    mount_with_retry "/mnt/server/data" 2 3
else
    log "server im aktuellen Netz nicht erreichbar, überspringe"
fi

mount_with_retry "/mnt/webdav" 2 3

log "Healthcheck beendet"
exit 0

/etc/systemd/system/mount-healthcheck.service und mount-healthcheck.timer – Systemd-Einheiten, die das Healthcheck-Skript 60 Sekunden nach dem Boot und danach alle 10 Minuten anstoßen:

[Unit]
Description=Prueft und stellt Netzwerk-Mounts sicher
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
TimeoutStartSec=120
ExecStart=/usr/local/bin/mount-healthcheck.sh

[Unit]
Description=Fuehrt den Mount-Healthcheck 60s nach Boot und danach alle 10 Minuten aus

[Timer]
OnBootSec=60s
OnUnitActiveSec=10min
AccuracySec=30s

[Install]
WantedBy=timers.target

Aktivieren nicht vergessen:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now mount-healthcheck.timer

/usr/lib/systemd/system-sleep/90-cancel-network-mounts – optionales Sicherheitsnetz vor dem Suspend:

#!/bin/bash
case "$1/$2" in
    pre/*)
        logger -t sleep-mount-guard "Breche evtl. laufende Netzwerk-Mount-Versuche vor Suspend ab"
        pkill -9 -f 'mount.cifs' 2>/dev/null
        pkill -9 -f 'mount.davfs' 2>/dev/null
        ;;
esac

exit 0

Alle Skripte müssen ausführbar sein:

$ sudo chmod +x /etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh 
              /etc/NetworkManager/dispatcher.d/90-server-mount 
              /etc/NetworkManager/dispatcher.d/90-webdav-mount 
              /usr/local/bin/mount-healthcheck.sh 
              /usr/lib/systemd/system-sleep/90-cancel-network-mounts

Lange Rede, kurzer Sinn

Automatisches Einhängen von Netzwerkfreigaben über NetworkManager funktioniert gut, ist aber kein Fünf-Minuten-Job, wie es die Doku vermuten lässt. Wenn ihr nur den mount-Befehl in ein up-Skript packt, holt euch früher oder später eines der drei Probleme ein – meistens genau dann, wenn ihr unterwegs seid und kein Log zur Hand habt.

Mit _netdev, korrektem pre-down-Timing, asynchroner Ausführung und einem echten Erreichbarkeitstest vor jedem Mount seid ihr auf der sicheren Seite. Und das Muster lässt sich eins zu eins auf andere netzwerkabhängige Automatisierungen übertragen, etwa VPN-Verbindungen oder Backup-Jobs, die nur im richtigen Netz laufen sollen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

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 als 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.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

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.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

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.

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.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

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..................................................

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

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.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

In meinen Augen ist das aber auch nicht sonderlich schlimm, da die Dateimanager der großen Desktopumgebungen wie Nautilus, Dolphin oder Thunar ja wunderbar mit den üblichen Netzwerkprotokollen zurechtkommen. Dennoch würde ich mir ein wenig mehr Auswahl wünschen, denn für einige Aufgaben bräuchte es nach wie vor einen ausgewachsenen FTP-Client — Wenn man dafür nicht auf Terminal-Anwendungen ausweichen möchte, ist da eben die Auswahl unter Linux äußerst dünn.

Von daher freue ich mich neulich auf Taxi gestoßen zu sein. Taxi ist noch ein sehr junger FTP-Client für Linux, der jedoch auch noch sehr aktiv entwickelt wird. Die letzten Änderungen am Sourcecode sind gerade einmal ein paar Tage alt. Wer sich selber einen Eindruck vom Programm verschaffen möchte, der kann es sich unter Arch Linux aus dem AUR installieren. PPAs oder DEB-Pakete für Taxi konnte ich noch nicht finden. Noch bietet Taxi nicht viel mehr Funktionen als simples Dateimanagement und Bookmarks für eure wichtigsten FTP-Server, aber das Programm steht ja auch noch bei Version 0.1.

Allerdings habe ich die leise Befürchtung, dass die Entwickler des Programms nicht das Ziel haben, Taxi zu einem wirklich leistungsfähigen FTP-Tool auszubauen. In der Launchpad-Beschreibung steht, dass man Taxi für elementary OS entwickeln würde. Die auf Ubuntu aufbauende und dem Mac nacheifernde Distribution ist zwar bekannt schicke Programme zu entwickeln, bei diesen steht jedoch eher die Form im Vordergrund — nicht die Funktion. Nichts desto trotz: Mehr Auswahl ist immer gut!

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Als Kommandozeilentool braucht speedtest-cli keine graphische Umgebung, das Skript lässt sich auch auf einfachen Systemen wie eben dem Raspberry Pi mit etwa Raspbian ausführen. speedtest-cli muss auch nicht zwingend installiert werden, das Skript kann man direkt von Github laden und ausführen. Arch-Linux-User finden speedtest-cli jedoch auch im AUR, so dass sich das Skript ohne weiteren Umstand auf den Rechner laden lässt

$ wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
$ chmod +x speedtest-cli
$ ./speedtest-cli

Wer speedtest-cli öfters braucht, der schiebt das Skript nach ~/bin oder mit Root-Rechten nach /usr/local/bin, so dass es im $PATH steht und von jedem Verzeichnis aus aufrufbar ist — bei der Installation unter Arch landet das Skript sowieso ordentlich im Dateisystem, so dass man sich darum keine Gedanken machen muss.

speedtest-cli kennt neben dem einfachen Aufruf ohne Optionen auch noch eine Reihe von Schaltern. So lässt sich mit etwa mit speedtest-cli --share der Pfad zur Imagedatei mit den Ergebnissen des Leitungstests ausgeben. Oder man ruft mit  speedtest-cli --list die Liste der Speedtest-Server ab, so dass man mit  speedtest-cli --server SERVER einen Testserver gezielt anwählen kann.

$ speedtest-cli --help
usage: speedtest-cli [-h] [--share] [--simple] [--list] [--server SERVER]

Command line interface for testing internet bandwidth using speedtest.net.
--------------------------------------------------------------------------
https://github.com/sivel/speedtest-cli

optional arguments:
-h, --help show this help message and exit
--share Generate and provide a URL to the speedtest.net share
results image
--simple Suppress verbose output, only show basic information
--list Display a list of speedtest.net servers sorted by distance
--server SERVER Specify a server ID to test against

Insgesamt funktioniert speedtest-cli ähnlich gut wie Speedtest.net, allerdings beobachten einige User doch recht schwankende Ergebnisse des Kommandozeilentools. Auch bei mir spuckte speedtest-cli öfters mal Werte aus, die eigentlich nicht sein konnten. Kommen einem die Werte komisch vor, dann sollte man also lieber noch einmal den Test wiederholen, nicht dass man umsonst die Verkabelung nochmal neu macht,

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

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.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Dass ihr einen SSH-Server wie SSHDroid, einen Web-Server wie kWS Android Web Server oder auch eine IP Webcam auf eurem Androiden laufen lassen könnt, ist ja keine tolle Neuigkeit. Doch werden die Dienste bei den meisten von euch nur im heimischen WLAN funktionieren. Unterwegs im UMTS Netz könnte ihr die Server nicht aufrufen, weil ihr bei den meisten Mobilfunkverträgen keine öffentliche IP bekommt.

Stattdessen steckt euch der Provider in sein eigenes Netz mit einer privaten IP-Adresse und routet eure Daten über einen Knoten ins Internet. Ihr erkennt das ganz gut, wenn ihr euch unter  „Einstellungen -> Über das Telefon -> Status“ die IP des Telefons im Mobilfunknetz anseht. Steht dort etwas von 10.x.x.x, 172.16.y.y oder eben 192.168.z.z, dann kann man das Smartphone (oder auch den über UMTS eingewählten Computer) nicht aus dem Internet heraus ansprechen.

PageKite überwindet nun diese Trennung indem das Back-End (also quasi der PageKite-Client) eine aktive Verbindung ins Internet zu einem Front-End-Relay (aka Server) aufbaut. Dieser richtet einen DNS-Domainnamen für das Back-End ein und leitet eingehende Pakete durch. Dadurch wird euer Smartphone oder euer UMTS-Notebook aus dem Internet erreichbar, auch wenn der Mobilfunkanbieter dies eigentlich gar nicht ermöglicht. Auf der FOSDEM 2011 hat die treibende Kraft Bjarni Runar Einarsson ein bisschen aus dem Nähkästchen geplaudert, schaut euch doch mal die Aufzeichnung des Vortrags an, wenn ihr Fragen zum Prinzip habt.

Das selbe Prinzip lässt sich nun nicht nur für Mobiltelefone anwenden, sondern auch für Leute die eben nicht „richtig“ im Netz hängen.  Habt ihr im Studentenwohnheim keine Möglichkeit eine Portweiterleitung einzurichten, dann erspart euch PageKite die aufwändige Konfiguration von Reverse-SSH-Tunnels oder andere Workarounds. PageKite gibt es für Windows, MacOS X und natürlich Android und Linux und lässt sich eigentlich recht einfach einrichten.

Selber hosten oder PageKite.net buchen

PageKite ist komplett freie Software, sowohl der Client- wie auch der Server-Part stehen unter der GPL. Ihr könnt daher PageKite auf eurem eigenen Root-Server und unter einer eigenen Domain betreiben, ihr habt so volle Kontrolle über den Dienst. Da der Mittelsmann trotz Verschlüsselung durchaus in die Daten reinschnuppern könnte, ist das für viele User sicherlich interessant. Allerdings bieten die Jungs ihren Reverese-Proxy auch als Dienstleistung an, so dass man sich die Einrichtung ersparen kann.

Auf pagekite.net (oder aus der App heraus, dazu später mehr) könnt ihr euch einen Account erzeugen. Der erste Monat ist kostenlos und beinhaltet einen Traffic von etwa 2,5 GByte. Danach gibt es verschiedene Tarife, wobei ihr in Ein-Dollar-Schritten an der Preisschraube drehen könnt. Je mehr Geld man investiert, desto länger läuft die Buchung, desto mehr Daten könnt ihr übertragen und desto mehr Features bekommt man. Entwickler freier Software, die etwas mit dem Internet zu tun hat, bekommen von PageKite einen kostenlosen Deal angeboten.

Generell finde ich das Projekt wirklich clever durchdacht. Client/Server und auch das PageKite-Protocol sind Open-Source, die Dienstleistung (mit Hilfe deren die Entwicklung des Projekts letztendlich finanziert wird) ist proprietär. Hoffentlich geht die Rechnung am Ende für die Entwickler auf, soooo groß ist der Kundenkreis in meinen Augen nicht, aber ich kann mich da ja auch verschätzen.

PageKite für Android

Am interessantesten ist PageKite sicherlich für das Android-Handy oder -Tablet. So könnt ihr zum Beispiel via SSH auf das Handy zugreifen (bei einem gerooteten Gerät auf das komplette Dateisystem), egal ob es gerade im WLAN- oder UMTS-Netz hängt. Oder ihr schnappt euch einen ausgedienten Androiden und setzt ihn als kleine IP-Webcam ein. Oder das alte Handy dient also Notfallzugang ins eigene Netz…

Die Android-App zu PageKite bekommt ihr wie gewohnt aus dem Google Play Store, sie ist wie gesagt kostenlos und Open-Source. Bevor ihr starten könnt, bietet euch die App an einen Account bei PageKite.net zu erzeugen. Ihr könnt diese Frage abbrechen, müsst aber dann erstmal selber im Netz einen PageKite-Server aufsetzen, dazu bringe ich später auch noch ein bisschen was. Zum Testen würde ich erstmal den Weg über PageKite.net gehen.

Nach dem Eintragen eurer Account-Informationen bekommt ihr eine E-Mail mit einem Aktivierungslink zugeschickt, die sich bei mir ein bisschen Zeit lies. Erst nachdem ihr euren Account aktiviert habt, klappt die Geschichte. Ungeduldige bekommen keine Fehlermeldung angezeigt, es scheint alles fertig zu sein, doch Pakete werden erst nach der Aktivierung durchgeleitet.Nach der Aktivierung müsst ihr PageKite auf dem Handy noch ein bisschen einrichten. Erstmal braucht ihr einen SSH oder einen HTTP-Webserver. SSHDroid oder kWS Android Web Server haben sich bei mir in der Vergangenheit bewährt. Beachtet bitte, dass SSHDroid von Haus aus so konfiguriert ist, dass der Dienst nur im WLAN läuft. In den Einstellungen könnt ihr jedoch festlegen, dass der Dienst durchläuft. Das ist später wichtig, da ihr ja die Ganze Aktion im UMTS-Netz testen wollt.

In den Server Settings habt ihr nun die Möglichkeit die von euren Serverdiensten benutzen Ports einzutragen, in der Grundeinstellung ist erstmal gar nichts eingetragen. Für SSH-Droid wären dies in der Standardeinstellung Port 22, für einen Webserver wie den erwähnten kWS Android Web Server die Port Nummern 80 oder 443 für verschlüsseltes HTTPS. Eine Null setzt den jeweiligen Dienst zurück, so dass er wieder inaktiv wird und keine Weiterleitung via PageKite mehr stattfindet. Je nach App sieht das allerdings auch immer wieder anders aus, die vorhin erwähnte  IP Webcam schnappt sich zum Beispiel in ihrer Standardeinstellung die Port-Nummer 8080 für HTTP, so läuft das Programm dann auch ohne Root-Rechte. Mehr als die drei Dienste lassen sich aktuell in der App allerdings nicht einrichten.

Danach solltet ihr die PageKite mit „Enable PageKite“ aus der Startseite der App heraus scharf schalten können. Sobald ihr die Meldung „Kites are flying and all is well“ als Status auf dem Schirm habt, solltet ihr euer Android-Smartphone oder -Tablet über die Adresse „euername.pagekite.me“ über SSH oder eben auch HTTP/HTTPS erreichen können. Voraussetzung ist natürlich, dass ihr die entsprechenden Dienste auch auf eurem Handy eingerichtet und gestartet habt, sonst antwortet am anderen Ende niemand. Achtet aber auch bitte drauf die Dienste entsprechend zu sichern, SSHDroid hat nicht gerade wirklich gesunde Standardeinstellungen. Setzt auf jeden Fall ein ordentliches Passwort für den root-User oder geht gleich den Weg über Public-Keys.

PageKite unter Ubuntu/Debian

Unter Ubuntu/Debian möchte ich den Bogen zu Linux und Open-Source wieder schließen. In der Einleitung hatte ich geschrieben, dass ihr PageKite auch selber als Client/Server betreiben könnt. Wer einen kleinen Server im Netz (oder vielleicht auch einen Raspi?) laufen hat, der kann sich überlegen seine eigene PageKite-Instanz aufzusetzen, so seid ihr nicht von Dritten abhängig und spart zudem auch Geld, kostenlos bietet PageKite.net seine Dienstleistung ja nicht an.

Für Linux bietet PageKite fertige Binarys und RPM- wie auch DEB-Pakete an. Für Debian/Ubuntu gibt es zudem auch eine Paketquelle, aus der man die Anwendung wie gewohnt problemlos installieren kann, daher führe ich hier an dieser Stelle die entsprechenden Schritte an. Weitere Informationen bekommt ihr unter PageKite for Linux and BSD auf der Homepage.

$ echo deb http://pagekite.net/pk/deb/ pagekite main | sudo tee -a /etc/apt/sources.list
$ sudo apt-key adv --recv-keys --keyserver keys.gnupg.net AED248B1C7B2CAC3
$ sudo apt-get update
$ sudo apt-get install pagekite

Danach könnt ihr auf Server und Client die Drachen steigen lassen. Die Befehle sehen in etwa so aus, wobei dies nur ein Quick&Dirty-Test ist. Ausführliche Informationen zum Einrichten der Anwendung unter GNU/Linux findet ihr im Wiki PageKites. Solltet ihr wirklich euren eigenen PageKite-Server aufsetzen wollen, dann würde ich die Konfiguration abspeichern und auch dafür sorgen, dass die Verbindung verschlüsselt wird.

Server

$ pagekite --clean --isfrontend --ports=12345 --protos=http --domain=http,https:yourdomain.net:geheim
>>> Hello! This is pagekite v0.5.3a.                            [CTRL+C = Stop]
    This is a PageKite front-end server.                                       
     - Listening on *:12345                                                    
    Connecting to front-end x.x.x.x:x ...                                      
~<> Flying: http://yourdomain.net/                                              
 << pagekite.py [flying]   Kites are flying and all is well.

Client

$ pagekite --clean --frontend=yourdomain.net:12345 --service_on=http:yourdomain.net:localhost:80:geheim
>>> Hello! This is pagekite v0.5.3a.                            [CTRL+C = Stop]
    Connecting to front-end 11.222.33.444:12345 ...                           
     - Protocols: http                                                         
     - Ports: 12345                                                            
~<> Flying localhost:80 as http:/yourdomain.net/                               
 << pagekite.py [flying]   Kites are flying and all is well.

Sollte euch das Terminal nicht sonderlich gefallen, dann gibts als Client-Alternative auch noch den PageKite Manager. Das graphische Frontend steckt allerdings noch nicht in den Paketquellen des Projekts, sondern muss von Hand runtergeladen werden. Bequeme laden es über die nächsten zwei Befehle nach ~/bin und machen es gleich ausführbar.

$ wget https://pagekite.net/pk/pagekite-gtk.py -O ~/bin/pagekit-gtk
$ chmod +x ~/bin/pagekit-gtk

Alles in allem finde ich PageKite eine clevere Sache. Im Zusammenspiel mit DynDNS und einem Raspberry Pi kann man sich den Dienst sicherlich auch recht einfach zu Hause einrichten. Interessante Anwendungszwecke gibt es mit Sicherheit einige.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.