Kategorie: Netzwerk

AVM FRITZ!Box 5530 Fiber am Telekom-FTTH-Anschluss in Betrieb nehmen

Die neue FRITZ!Box 5530 Fiber wurde bereits im September 2019 das erste mal gezeigt. Mehr als ein Jahr später, Mitte November 2020, fand die offizielle Vorstellung statt. Als Verkaufsstart nannte AVM hier lediglich “demnächst verfügbar”. Anschließend hat es nochmal ca. zwei Monate gedauert, bis die FRITZ!Box 5530 Fiber das erste Mal käuflich zu erwerben war. Seitdem sind immer mal wieder Angebote bei Amazon zu finden, die in der Regel aber nach wenigen Stunden ausverkauft sind.

Ich hatte Glück und konnte letzte Woche eine 5530 ergattern, die vor wenigen Tagen bei mir eingetroffen ist. Nachdem ich bereits von einigen Firmware-Problemen bei der offiziellen FRITZ!OS Version 07.21 gelesen hatte, habe ich ohne weitere Tests direkt zur neuesten erhältlichen Firmware gegriffen. Zum Zeitpunkt des Artikels war das FRITZ!OS 07.24-86065 Inhaus. Den Download findet ihr übrigens hier: https://download.avm.de/inhaus/PSQ19Phase2/5530/FRITZ.Box_5530-07.24-86065-Inhaus.image

Und hier ist die neue FRITZ.Box_5530-07.24-86375-Inhaus.

Telekom-Setup

Bereits seit einigen Jahren werden bei uns in der Gegend Neubaugebiete mit Fiber to the Home (FTTH) ausgestattet. Die Telekom setzt dabei auf Gigabit Passive Optical Network (GPON).

Die Beantragung erfolgt über den Netzversorger. Dieser legt dann in koordinierter Bauweise neben dem Strom- unter anderem auch den FTTH-Anschluss in die Mehrspartenhauseinführung. Genauer gesagt erst einmal nur das Glasfaserleerrohr. Anschließend wird die Glasfaser eingeblasen und der Glasfaser-Abschlusspunkt (Gf-AP) gesetzt. Üblicherweise wird daneben die Glasfaser-Teilnehmeranschlussdose (Gf-TA) verbaut. Diese kann aber z.B. auch in einem anderen Raum oder im EG verbaut werden. Als drittes wird der die Optical Network Termination (ONT) platziert. Dabei handelt es sich schlicht und einfach um das Glasfasermodem welches via LC-Simplex-Patchkabel mit der Gf-TA verbunden wird. Die FTTH-Grundinstallation bei der Telekom ist also Gf-AP –> Gf-TA –> ONT.

Bei mir kommt ein sogenannter Klapp-TA zum Einsatz. Dabei handelt es sich um einen Gf-TA der sich aufklappen lässt mit integriertem ONT. Ich habe ein Leerrohr von der Mehrspartenhauseinführung zum Netzwerkschrank gelegt, sodass ich den kombinierten Gf-TA/ONT dort platzieren konnte. In meinem Fall ist der ONT ein Huawei EchoLife HG8010u (ONT v3). Dieser besitzt eine LAN-Schnittstelle, welche man mit dem Router verbindet, in meinem Fall eine ältere FRITZ!Box 7490.

Nachfolgend ein paar Fotos:

Umstellung auf FRITZ!Box 5530 Fiber

Mein Ziel war es, den ONT und die ältere FRITZ!Box 7490 durch die neue FRITZ!Box 5530 Fiber zu ersetzen. Einfach Umstecken funktioniert allerdings nicht, da hier einige Dinge zu beachten sind. Nachfolgend eine kleine Anleitung, die bei mir und anderen Benutzern einwandfrei funktioniert hat.

  1. Als Ausgangssituation startet ihr mit eurem aktiven und verbundenen ONT (Glasfaserkabel ist eingesteckt).
  2. Zunächst benötigt ihr die ONT-Kennung, welche ihr bei der Telekom erfragen müsst. Theoretisch funktioniert das über die Hotline. Praktisch wissen nur wenige Ansprechpartner Bescheid, weshalb ihr vermutlich mehrmals anrufen müsst, bis euch die ONT-Kennung genannt wird. Daher würde ich euch empfehlen die Anfrage via “Telekom hilft” auf Twitter zu stellen. Das funktioniert zuverlässig und vermutlich auch schneller.
  3. Wie anfangs beschrieben solltet ihr eure FRITZ!Box 5530 auf die neueste Version aktualisieren.
  4. Nun könnt ihr das GPON-Modul in eure 5530 stecken, das Glasfaserkabel vom ONT entfernen und mit eurer FRITZ!Box verbinden.
  5. Die Seite “http://fritz.box/support.lua” öffnen, einloggen und ganz runter scrollen. Dort bei “GPON Seriennummer” die Seriennummer eures ONTs eintragen. Mit dem Klick auf den Button “Einstellungen übernehmen” hat es bei mir komischerweise nicht funktioniert. Daher habe ich nach dem Eintragen oben links auf das FRITZ!-Logo geklickt und im Popup auf “Übernehmen”.
    Die Seriennummer bei den Huawei-ONTs findet ihr unter dem Deckel. Diese könnt ihr 1:1 übernehmen.
    Bei älteren Sercomm-ONTs müsst ihr die Seriennummer erst umwandeln. Als Hilfestellung kann ich diesen Forenbeitrag empfehlen.

  6. Anschließend unter “http://fritz.box” die Telekom-Zugangsdaten und die ONT-Kennung eintragen.

    FRITZ!Box 5530 Zugangsdaten

    FRITZ!Box 5530 Zugangsdaten

  7. Optional: Ab sofort könnt ihr ohne weiteres Zutun zwischen FRITZ!Box 5530 und altem ONT wechseln. Einfach das Glasfaserkabel umstecken.

Sollte bei euch diese Variante nicht funktionieren, gäbe es noch die Möglichkeit über einen Rediscover. In diesem Fall müsst ihr die Seriennummer eures Telekom-ONTs nicht übernehmen. Nachteil dieser Methode ist allerdings, dass ab sofort nur noch die FRITZ!Box 5530 an eurem FTTH-Anschluss funktioniert. Ein Wechsel zurück zum alten ONT hätte einen erneuten Rediscover zur Folge. Da diese Variante einige Nachteile besitzt hier nur die Kurzform:

  1. ONT-Kennung bei der Telekom erfragen. Funktioniert sporadisch via Hotline, daher besser “Telekom hilft”.
  2. FRITZ!Box 5530 auf die neueste Version aktualisieren.
  3. Glasfaserkabel vom ONT entfernen.
  4. Bei der Telekom einen Rediscover anfordern. Funktioniert sporadisch via Hotline, daher besser “Telekom hilft”.
  5. Glasfaserkabel in das GPON-Modul der FRITZ!Box 5530 stecken und Zugangsdaten eintragen.

Ubiquiti UniFi Dream Machine Pro (UDM-PRO) – NAT deaktivieren

Ubiquiti Logo

Die Ubiquiti UniFi Dream Machine Pro (UDM-PRO) bietet ein gutes Preis-Leistungs-Verhältnis, weshalb sie oft im Privatgebrauch oder in kleinen Firmen zum Einsatz kommt. Idealerweise wird das Gerät direkt oder über ein Modem mit dem Internet verbunden. Hierfür stehen an der UDM-PRO die beiden WAN-Ports 9 (RJ45) und 10 (SFP) zur Verfügung. Auf beiden Ports ist die Network Address Translation (NAT) standardmäßig aktiviert. Innerhalb der Konfigurationsoberfläche besteht keine Möglichkeit NAT zu deaktivieren.

Falls die UDM-PRO unter bestimmten Voraussetzungen hinter einem Router, z.B. einer FRITZ!Box betrieben werden muss, dann hat man zwangsweise den Nachteil von doppeltem NAT. In vielen Fällen kann dieses Setup ohne weitere Einschränkungen genutzt werden. Doppeltes NAT führt aber oftmals bei Onlinespielen, Xbox, PlayStation und Co zu Problemen. Diese Probleme können jedoch behoben werden, indem die UDM-PRO in der FRITZ!Box als “Exposed Host” konfiguriert wird. Das doppelte NAT ist dann aber trotzdem noch vorhanden.

Lange Rede kurzer Sinn: In diesem Artikel möchte ich euch zeigen, wie ihr NAT auf den WAN-Ports der UDM-PRO deaktivieren könnt.

SSH aktivieren und verbinden

Zunächst müsst ihr den SSH-Zugang aktivieren und ein Passwort setzen. Dies erfolgt über die Einstellungen der UDM-PRO unter dem Punkt “Console Settings”. Bei älteren Versionen von UniFi OS sieht die Weboberfläche ein wenig anders aus.

UDM SSH aktivieren

Anschließend könnt ihr euch z.B. mit PuTTY via SSH auf die UDM-PRO verbinden. Der Username ist “root”.

Mit folgendem Befehl können wir die aktuelle NAT-Konfiguration einsehen:

ab UniFi OS 3.x:
xtables-multi iptables -t nat -L UBIOS_POSTROUTING_USER_HOOK -v --line-number
UniFi OS 2.x und älter:
xtables-legacy-multi iptables -t nat -L UBIOS_POSTROUTING_USER_HOOK -v --line-number

Standardmäßig sieht die NAT-Konfiguration folgendermaßen aus:

Chain UBIOS_POSTROUTING_USER_HOOK (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1     481K   66M MASQUERADE  all  --  any    eth8    anywhere             anywhere   
2        0     0 MASQUERADE  all  --  any    eth9    anywhere             anywhere

Hier ist ersichtlich, dass auf Port 9 (eth8) und Port 10 (eth9) NAT aktiviert ist.

“UDM / UDMPro Boot Script” installieren

Voraussetzung für das Deaktivieren von NAT ist das “UDM / UDMPro Boot Script“, welches auch nach einem Neustart oder Firmwareupdate bestehen bleibt.

Für die Installation wird das Boot Script heruntergeladen und installiert. Je nach Version von UniFi OS kann noch die alte Version des Skripts verwendet werden, welche bis UniFi OS 2.4.x funktionieren sollte.

curl -fsL "https://raw.githubusercontent.com/unifi-utilities/unifios-utilities/HEAD/on-boot-script/remote_install.sh" | /bin/sh

Alternativ ab UniFi OS 2.5.x und höher dann folgende Variante. Hier ist etwas mehr manuelle Handarbeit zu erledigen:

# Download package
curl -L https://github.com/unifi-utilities/unifios-utilities/raw/main/on-boot-script-2.x/packages/udm-boot-2x_1.0.1_all.deb -o /tmp/udm-boot-2x_1.0.1_all.deb

# Install it
dpkg -i /tmp/udm-boot-2x_1.0.1_all.deb

# Patches for 'udm-boot-2x_1.0.1_all.deb' package
sed -i 's/Description=Run On Startup UDM 2.x/Description=Run On Startup UDM 3.x/g' /lib/systemd/system/udm-boot.service
sed -i '/Restart=on-failure/d' /lib/systemd/system/udm-boot.service
sed -i '/RestartSec=5s/d' /lib/systemd/system/udm-boot.service

# Enable reload and start
systemctl enable udm-boot
systemctl daemon-reload
systemctl start udm-boot

Zum Schluss sollte geprüft werden, ob das Skript auch läuft:

systemctl status udm-boot.service

Sofern “Run On Startup UDM 3.x” angezeigt wird, passt alles.

NAT deaktivieren

Jetzt könnt ihr eigene Shell Scripte in “/data/on_boot.d” hinterlegen, die bei jedem UDM-PRO Start bzw. Reboot ausgeführt werden.

cd /data/on_boot.d

Dort erstellt ihr euer Skript zur Deaktivierung von NAT:

touch /data/on_boot.d/delete-nat.sh

Das Skript funktioniert ab UniFi OS 3.x und bekommt folgenden Inhalt:

#!/bin/bash
# Check if script runs directly after boot. If so, wait for 10 seconds.
uptimeMinutes=`cat /proc/uptime | awk '{print $1}'`
if [ ${uptimeMinutes::-3} -lt 300 ]
	then
		logger NAT-Script: Script zum 1. Mal nach Boot ausgefuehrt
		sleep 10
	else
		logger NAT-Script: Script via Cron-Job ausgefuehrt
fi

# Check if default NAT rules exist
if iptables -t nat -S UBIOS_POSTROUTING_USER_HOOK | grep -e "UBIOS_POSTROUTING_USER_HOOK -o eth8 -m comment --comment 00" -e "UBIOS_POSTROUTING_USER_HOOK -o eth9 -m comment --comment 00" > /dev/null
	then
		xtables-legacy-multi iptables -t nat -D UBIOS_POSTROUTING_USER_HOOK 1
		if iptables -t nat -S UBIOS_POSTROUTING_USER_HOOK | grep -e "UBIOS_POSTROUTING_USER_HOOK -o eth8 -m comment --comment 00" -e "UBIOS_POSTROUTING_USER_HOOK -o eth9 -m comment --comment 00" > /dev/null
			then
				xtables-legacy-multi iptables -t nat -D UBIOS_POSTROUTING_USER_HOOK 1
				if iptables -t nat -S UBIOS_POSTROUTING_USER_HOOK | grep -e "UBIOS_POSTROUTING_USER_HOOK -o eth8 -m comment --comment 00" -e "UBIOS_POSTROUTING_USER_HOOK -o eth9 -m comment --comment 00" > /dev/null
					then
						logger NAT-Script: NAT-Regel gefunden, Loeschen nicht erfolgreich \(Fehler!\)
					else
						logger NAT-Script: NAT-Regel gefunden und geloescht
				fi
			else
				logger NAT-Script: NAT-Regel gefunden und geloescht
		fi
	else
		logger NAT-Script: Keine NAT-Regel vorhanden
fi


# Check if cron job exists
if ls /etc/cron.d/delete-nat > /dev/null 2>&1
	then 
		logger NAT-Script: Cron-Job vorhanden
	else
		echo "*/15 * * * * /data/on_boot.d/delete-nat.sh" > /etc/cron.d/delete-nat
		logger NAT-Script: Cron-Job nicht vorhanden und erstellt
		/etc/init.d/cron restart 
fi
Das Skript ist eine leicht optimierte Version der ursprünglichen Variante aus dem Kommentar von other_tobi.

Es überprüft, ob die standardmäßig gesetzten NAT-Regeln vorhanden sind und entfernt diese. Außerdem wird ein rudimentäres Logging geboten.

Bei jeder Änderung im Routing oder in den Firewall-Regeln der UDM-PRO werden die beiden NAT-Policies wiederhergestellt. Aus diesem Grund wird ein Cronjob erstellt, welcher dafür sorgt, dass das Skript alle 15 Minuten ausgeführt wird. Somit wird sichergestellt, dass die Standard-NAT-Regeln wieder entfernt werden, sofern diese automatisch generiert werden.

Das Skript muss anschließend noch ausführbar gemacht werden:

chmod +x delete-nat.sh

Bei Bedarf könnt ihr das Skript direkt starten und prüfen, ob es funktioniert.

bash delete-nat.sh

Eine Überprüfung mit

xtables-legacy-multi iptables -t nat -L UBIOS_POSTROUTING_USER_HOOK -v --line-number

zeigt, dass beide NAT-Regeln entfernt wurden:

Chain UBIOS_POSTROUTING_USER_HOOK (1 references)
num pkts bytes target prot opt in out source destination

Das Logging des Skripts könnt ihr folgendermaßen einsehen:

grep NAT /var/log/messages

Statische Route in der FRITZ!Box

Standardmäßig ist das FRITZ!Box Subnetz 192.168.178.0/24 und das Netz der UDM-PRO 192.168.1.0/24.

Damit Clients aus dem UDM-PRO-Subnetz auf das Internet oder die FRITZ!Box zugreifen können, wird noch eine statische Route auf der FRITZ!Box benötigt.

Diese könnt ihr unter “Heimnetz –> Netzwerke –> Netzwerkeinstellungen” anlegen. Dazu ganz nach unten scrollen und auf den Button “IPv4-Routen” klicken (siehe Bild).

Dort erstellt ihr eine neue Route und gebt folgende Daten ein:

  • Netzwerk: das Netz der UDM-PRO, standardmäßig 192.168.1.0
  • Subnetzmaske: die Subnetzmaske des vorher eingetragenen Netzes, standardmäßig 255.255.255.0
  • Gateway: die Adresse der UDM-PRO im FRITZ!Box Subnetz, diese kann unter “Heimnetzwerk” in Erfahrung gebracht werden

Mit Klick auf “Übernehmen” ist dieser Schritt erledigt.

Optional: Firewall-Regel in der UDM-PRO

Dieser Schritt ist nur notwendig, wenn ihr vom Subnetz der FRITZ!Box auf ein Subnetz “hinter” der UniFi Dream Machine Pro zugreifen möchtet. Anders herum funktioniert es ohne weitere Konfiguration.

Die Kommunikation wird nämlich noch durch die Firewall der UDM-PRO blockiert. Um dies zu ändern, muss eine neue Regel erstellt werden. Zunächst muss der UniFi Network Controller auf der UDM-PRO geöffnet werden. Anschließend unter “Einstellungen –> Security –> Internet Threat Management –> Firewall” auf den Button “Create new Rule” klicken.

Exemplarisch habe ich jeglichen Traffic aus dem Subnetz der FRITZ!Box freigegeben. Sofern möglich solltet ihr die Freigabe jedoch spezifischer gestalten, z.B. auf einzelne IP-Adressen einschränken und nicht ganze Subnetze freigeben.

Raspberry Pi – Installation und Betrieb von WireGuard

WireGuard Logo

Obwohl die Bekanntheit von WireGuard in den letzten Monaten stark zugenommen hat, ist das VPN-Protokoll bzw, die VPN-Software immer noch verhältnismäßig unbekannt. Ich nutze WireGuard seit einigen Monaten und möchte es nicht mehr missen. Vor allem der schnelle Verbindungsaufbau, das exzellente Roaming-Verhalten und die gute Performance haben mich überzeugt.

Was sich genau hinter WireGuard verbirgt und wie die Software arbeitet, habe ich bereits in meinem Artikel “​WireGuard – neues VPN-Protokoll mit großer Zukunft” beschrieben. Jetzt folgt sozusagen der zweite Teil, in dem ich detailliert auf die Einrichtung unter Raspbian Buster und Android eingehe.

WireGuard Installation

Update 13.05.2021: Artikel auf das aktuellste Raspberry Pi OS angepasst. Dieser nutzt den Linux-Kernel 5.10, in welchem das WireGuard Modul enthalten ist.
Die Installationsanleitung funktioniert nicht bei folgenden Raspberry Pi Modellen: 1, 2 (Ausnahme v1.2), Zero & Zero W. Bei diesen Modellen fehlen benötigte CPU-Features und WireGuard muss dort von Hand compiliert werden. Wie das geht habe ich relativ am Ende meines Artikels aufgezeigt. Davon abgesehen macht die Nutzung auf diesen Modellen aber nur eingeschränkt Spaß.

Zunächst bringen wir die Paketquellen und alle Pakete auf den aktuellen Stand.

sudo apt update
sudo apt upgrade

Nachdem dies erledigt ist, widmen wir uns der Installation von WireGuard.

sudo apt install wireguard

Die Installation an sich ist damit erledigt. Allerdings fehlt ab Raspberry Pi OS Bullseye iptables, d.h. dieses müssen wir auch noch installieren:

sudo apt install iptables

Jetzt können wir mit der Konfiguration fortfahren.

Generierung der benötigten Schlüsselpaare

Zum Start benötigen wir jeweils einen privaten und öffentlichen Schlüssel für den Client und den Server.

Die Erstellung der Keys wird im Verzeichnis “/etc/wireguard” durchgeführt. Damit alle Dateien bei der Erstellung direkt restriktive Berechtigungen haben, muss die umask auf 077 gesetzt werden.

sudo su
cd /etc/wireguard
umask 077
wg genkey | tee peer1_private.key | wg pubkey > peer1_public.key
wg genkey | tee server_private.key | wg pubkey > server_public.key

Mittels “ls” prüfen wir, ob alle vier Dateien erstellt wurden:

ls
peer1_private.key  peer1_public.key  server_private.key  server_public.key

Zum Schluss können die Keys mittels “cat” ausgegeben werden, da wir diese später sowieso benötigen.

exit
sudo cat /etc/wireguard/peer1_private.key
sudo cat /etc/wireguard/peer1_public.key
sudo cat /etc/wireguard/server_private.key
sudo cat /etc/wireguard/server_public.key

WireGuard Server Konfiguration erstellen

Im ersten Schritt aktivieren wir das IPv4 Forwarding in der Datei “/etc/sysctl.conf”. Dies kann entweder mit Entfernen der Auskommentierung der Zeile “net.ipv4.ip_forward = 1” oder alternativ mit diesem Befehl erfolgen:

sudo perl -pi -e 's/#{1,}?net.ipv4.ip_forward ?= ?(0|1)/net.ipv4.ip_forward = 1/g' /etc/sysctl.conf

Wer IPv6 nutzt, muss stattdessen entsprechend die Auskommentierung der Zeile “net.ipv6.conf.all.forwarding=1” aufheben.

Anschließend muss der Raspberry Pi neugestartet werden.

sudo reboot

Wir überprüfen den Status mit folgendem Befehl:

sysctl net.ipv4.ip_forward

Wenn das IPv4 Forwarding aktiv ist muss als Ergebnis “net.ipv4.ip_forward = 1” zurückgegeben werden.

Jetzt erstellen wir die WireGuard-Konfiguration “/etc/wireguard/wg0.conf”. Welchen Editor ihr bevorzugt, bleibt natürlich euch überlassen.

sudo vim /etc/wireguard/wg0.conf

Folgendes Template könnt ihr als Ausgangsbasis nutzen.

[Interface]
Address = 100.64.0.1/24
ListenPort = 51820
PrivateKey = <insert server_private.key>

#replace eth0 with the interface open to the internet (e.g might be wlan0)
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

#Client1 Smartphone
[Peer]
PublicKey = <insert peer1_public.key>
AllowedIPs = 100.64.0.2/32

Neben den IP-Adressen müsst ihr den privaten Schlüssel vom Server und den öffentlichen Schlüssel vom Client ergänzen. Außerdem müsst ihr bei den iptables-Regeln evtl. die Netzwerkschnittstelle anpassen. Optional könnt ihr zudem einen anderen Port definieren. Wenn alles erledigt ist, solltest ihr die Datei unbedingt speichern.

Die für den Tunnel verwendeten IP-Adressen, dürfen sich mit den lokal verwendeten, privaten IPv4-Blöcken (RFC 1918) nicht überschneiden. Beim Einsatz einer FRITZ!Box als Router wird lokal standardmäßig 192.168.178.0/24 verwendet, d.h. alle anderen Adressbereiche können ohne Probleme genutzt werden.

Eine elegante Alternative ist die Verwendung von IP-Adressen (100.64.0.0/10), die für Carrier-Grade-NAT (RFC 6598) reserviert sind. Damit ist sichergestellt, dass die Tunnel-IPs nie mit den privaten Adressbereichen kollidieren können.

WireGuard Client Konfiguration erstellen

Am besten erstellt ihr für jeden Client eine eigene Konfiguration.

sudo vim /etc/wireguard/peer1.conf

Folgendes Template könnt ihr als Ausgangsbasis nutzen.

[Interface]
Address = 100.64.0.2/32
DNS = 192.168.178.1
PrivateKey = <insert peer1_private.key>

#Server
[Peer]
PublicKey = <insert server_public.key>
Endpoint = t6bibneqwcjxplum.myfritz.net:51820
AllowedIPs = 0.0.0.0/0, ::/0
#PersistentkeepAlive = 25

Hier müsst ihr unter “[Interface]” die IP-Adresse des Clients anpassen und den gewünschten DNS-Server eintragen. In meinem Beispiel verwende ich die private IP der FRITZ!Box. Wer daheim Pi-Hole im Einsatz hat, kann hier die Pi-Hole Adresse eintragen und kommt somit auch von unterwegs in den Genuss der Werbefreiheit.

Außerdem müsst ihr noch den privaten Schlüssel des Clients ergänzen.

Unter “[Peer]” tragt ihr zunächst den öffentlichen Schlüssel des Servers ein.

Anschließend folgt die Internetadresse, unter welcher der WireGuard-Server erreichbar ist. Üblicherweise gibt es hier zwei Dinge zu beachten. Bei eurem Internetanschluss daheim, bekommt ihr mit großer Wahrscheinlichkeit eine dynamische IP-Adresse vom Provider zugewiesen. Der WireGuard-Client müsste die wechselnden IP-Adressen stets kennen, um sich zu verbinden. Als Hilfe kommt hier ein dynamischer DNS-Anbieter ins Spiel, der einen festen Domainnamen bereitstellt und dahinter automatisch die jweils aktuelle IP-Adresse zuweist. Bei Verwendung einer FRITZ!Box könnt ihr beispielsweise den Dienst “MyFRITZ!” nutzen. Eine andere Alternative wäre FreeDNS. Der zweite Punkt ergibt sich, wenn der Raspberry Pi in eurem Heimnetzwerk steht. In diesem Fall müsst ihr an eurem Router ein Port-Forwarding einrichten (UDP 51820), sodass der WireGuard-Traffic des Clients auf den Server weitergeleitet wird.

Unter “AllowedIPs” wird definiert, welche IP-Ranges über das WireGuard-VPN geroutet werden. Mit “0.0.0.0/0, ::/0” wird der komplette IPv4- und IPv6-Traffic geroutet (full tunnel). Mit 192.168.178.0/24 könnt ihr z.B. nur euer Heimnetzwerk routen (split tunnel).

“PersistentKeepalive” ist standardmäßig deaktiviert. Zunächst ein paar Hintergrundinfos um einzuordnen, ob ihr dieses Feature benötigt oder nicht. Normalerweise ist WireGuard nicht sehr gesprächig und sendet nur Daten, wenn etwas zu übertragen ist. Ansonsten verhält sich WireGuard ruhig. Wenn sich der Server hinter einem NAT oder einer Firewall befindet und der Client für eine bestimmte Zeit keine Daten zum Server sendet, entfernt der NAT-Router bzw. die Firewall den Host-Status aus der Verbindungstabelle. Falls jetzt der Server ein Paket zum Client sendet, kommt dieses nicht an, da der NAT-Router bzw. die Firewall nicht weiß, was mit dem Paket zu tun ist. Mit der Option “PersistentKeepalive” sendet der Client alle x Sekunden ein leeres Paket, um die Verbindung aufrechtzuhalten. Ein Wert von 25 Sekunden hat sich in der Praxis bewährt und funktioniert mit einem Großteil von Firewalls und NAT-Routern.

Kurz zusammengefasst benötigt ihr dieses Feature also nur, wenn ihr vom Server euren Client erreichen möchtet, obwohl dieser seit längerer Zeit keine Pakete gesendet hat. Die meisten Benutzer werden dieses Feature nicht benötigen. Falls doch, einfach die Auskommentierung der Zeile rückgängig machen.

WireGuard Server starten

Nun können wir WireGuard auf dem Server starten. Anstatt alle einzelnen Schritte manuell mit dem “wg”-Tool durchzuführen, bedienen wir uns beim Tool “wg-quick”.

sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 100.64.0.1/24 dev wg0
[#] ip link set mtu 1432 up dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Die MTU von 1432 bezieht sich auf PPPoE mit IPv4. Bei IPv6 müsst ihr die MTU auf 1412 setzen. Wenn ihr Kabelinternet habt, dann sind Werte von 1440 bei IPv4 und 1420 bei IPv6 richtig.

Danach prüfen wir den Status der wg0-Schnittstelle.

sudo wg
interface: wg0
  public key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxljP1wpITnI=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtJd9/esWN4=
  allowed ips: 100.64.0.2/32

Der Server läuft und ist für die Verbindung des Clients bereit.

WireGuard beenden funktioniert mit diesem Befehl:

sudo wg-quick down wg0

Wenn WireGuard beim Systemstart automatisch geladen werden soll, kann dies mit folgendem Befehl realisiert werden:

sudo systemctl enable wg-quick@wg0
Created symlink /etc/systemd/system/multi-user.target.wants/wg-quick@wg0.service → /lib/systemd/system/wg-quick@.service.

Der Daemon kann folgendermaßen gesteuert werden. Dabei müsst ihr allerdings darauf achten, dass ihr WireGuard zuerst beendet, sofern ihr es manuell gestartet habt.

sudo systemctl start wg-quick@wg0
sudo systemctl stop wg-quick@wg0
systemctl status wg-quick@wg0

Zum Schluss werden die Berechtigungen von “/etc/wireguard/” und allen Dateien noch einmal korrigiert. Damit wird sichergestellt, dass nur root die entsprechenden Berechtigungen besitzt.

sudo chown -R root:root /etc/wireguard/
sudo chmod -R og-rwx /etc/wireguard/*

WireGuard Client unter Android einrichten

Die Einstellungen in der Android-App können manuell, mittels einer Datei oder mit einem QR-Code erfolgen. Die letzte Variante ist dabei am bequemsten. Hierfür muss auf dem Server der QR-Code erstellt werden.

sudo apt install qrencode

Nach dem Installieren von “qrencode” kann der QR-Code von der Client-Konfiguration erstellt werden:

sudo cat /etc/wireguard/peer1.conf | qrencode -t ansiutf8

Auf dem Android-Gerät muss zunächst die WireGuard App via Google Play installiert werden. Daraufhin kann der erstellte QR-Code mit der App gescannt werden, um die Konfiguration zu importieren. Nachdem ein Name vergeben wurde, kann die Verbindung aktiviert werden.

Mit einem Klick auf den gerade erstellten Tunnel werden einige Infos angezeigt, unter anderem auch eine Trafficstatistik.

Auf dem Server kann ebenfalls der Status ausgegeben werden. Dort werden unter anderem alle verbundenen Clients angezeigt:

sudo wg
interface: wg0
  public key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxljP1wpITnI=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtJd9/esWN4=
  endpoint: 11.12.13.14:53019
  allowed ips: 100.64.0.2/32
  latest handshake: 56 seconds ago
  transfer: 927.04 KiB received, 64.85 MiB sent

Der Client kann nun auch via Ping erreicht werden:

ping 100.64.0.2
PING 100.64.0.2 (100.64.0.2) 56(84) bytes of data.
64 bytes from 100.64.0.2: icmp_seq=1 ttl=64 time=95.9 ms
64 bytes from 100.64.0.2: icmp_seq=2 ttl=64 time=112.4 ms
64 bytes from 100.64.0.2: icmp_seq=3 ttl=64 time=71.7 ms

Noch zwei kleine Tipps für die Android-App. Ich importieren die Konfig vom Server immer zweimal. Einmal als “full tunnel” mit “0.0.0.0/0, ::/0” und einmal als “split tunnel”, lediglich mit dem Heimnetzwerk eingetragen, z.B. 192.168.178.0/24. So habt ihr volle Kontrolle und könnt je nach Situation den richtigen Tunnel nutzen.

Beim Bearbeiten eines Tunnels (Tunnel Infos anzeigen und dann rechts oben auf das Stift-Icon) könnt ihr außerdem festlegen, welche Apps keinen Traffic über den Tunnel schicken dürfen.

Troubleshooting

WireGuard ist ein Kernel-Modul, das via DKMS automatisch installiert wird, sobald das System einen neuen Kernel benutzt. In seltenen Fällen kann es jedoch passieren, dass WireGuard nicht automatisch eingebunden wird und mit dem neuen Kernel nicht mehr funktioniert.

In diesem Fall sollte zunächst geprüft werden, ob das WireGuard Modul geladen wurde:

lsmod | grep wireguard

Falls nicht kann es hilfreich sein, das Kernel-Modul neu zu konfigurieren:

sudo dpkg-reconfigure wireguard-dkms
sudo modprobe wireguard

Wenn dies keine Abhilfe schafft, könnt ihr noch folgendes ausprobieren:

sudo apt remove wireguard
sudo apt install bc libncurses5-dev
sudo apt install wireguard

Sollte dies auch keine Besserung bringen, könnt ihr alternativ das WireGuard Kernel Module und das wg Tool selber kompilieren. Davor muss aber sichergestellt sein, dass alle installierten WireGuard-Pakete deinstalliert sind!

sudo apt remove wireguard
# Toolchain installieren
sudo apt install libmnl-dev raspberrypi-kernel-headers build-essential git pkg-config
#Code laden
git clone https://git.zx2c4.com/wireguard-linux-compat
git clone https://git.zx2c4.com/wireguard-tools
# Kernel Module und das wg Tool kompilieren und installieren
make -C wireguard-linux-compat/src -j$(nproc)
sudo make -C wireguard-linux-compat/src install
make -C wireguard-tools/src -j$(nproc)
sudo make -C wireguard-tools/src install
# Neustarten und fertig
sudo reboot

Die aktuell installierte Version könnt ihr am besten via “dmesg” herausfinden:

dmesg | grep wireguard
[  466.479104] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
[  466.479115] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.

Quellen

  • https://www.wireguard.com/install/
  • https://github.com/adrianmihalko/raspberrypiwireguard
  • https://www.reddit.com/r/pihole/comments/bnihyz/guide_how_to_install_wireguard_on_a_raspberry_pi/
  • https://emanuelduss.ch/2018/09/wireguard-vpn-road-warrior-setup/
  • https://www.bachmann-lan.de/raspberry-pi-mit-wireguard-als-vpn-server-mit-wireguard/

WireGuard – neues VPN-Protokoll mit großer Zukunft

WireGuard Logo

WireGuard erfreut sich seit geraumer Zeit wachsender Beliebtheit. Hinter WireGuard verbirgt sich sowohl ein VPN-Protokoll, als auch eine VPN-Software. Während es vor zwei Jahren quasi unbekannt war, hat die Bekanntheit in den letzten Monaten stark zugenommen. Grund dafür ist neben der guten Performance und dem schnellen Verbindungsaufbau sicherlich auch die Aufnahme in den stabilen Linux Kernel 5.6, welcher Anfang April 2020 erscheinen dürfte.

Ich selbst bin im Herbst 2019 auf WireGuard gestoßen, als jemand in einem Forum WireGuard vorstellte und als “heißen Scheiß” bezeichnet hatte. Mittlerweile nutze ich WireGuard seit mehreren Monaten und kann dieser Aussage nur zustimmen :-)

Einleitung

Das VPN-Protokoll WireGuard und die gleichnamige Open Source Software wurden von Jason A. Donenfeld ins Leben gerufen. WireGuard sieht sich selber als extrem einfache, aber dennoch schnelle und moderne VPN-Lösung. Gleichzeitig soll es durch die Nutzung der neuesten Kryptographie-Techniken extrem sicher sein. Im direkten Vergleich mit IPsec und OpenVPN soll es leistungsfähiger, einfacher, schlanker und schneller sein.

Ursprünglich wurde WireGuard nur für den Linux-Kernel entwickelt, ist mittlerweile aber zudem für Windows, macOS, BSD, iOS und Android verfügbar.

Die ersten Snapshots wurden im Juni 2016 veröffentlich. Zwei Jahre später im Juni 2018 wurde der Code und das Protokoll als experimentell bezeichnet und darauf hingewiesen, dass noch kein stabiles Release existiert. Dies trifft bis zum heutigen Tag zu, könnte sich aber bald ändern.

Rund eineinhalb Jahre nach dem Vorschlag von Donenfeld zur Aufnahme in den Hauptzweig ist es nun soweit. Linus Torvalds hat vor wenigen Tagen den Entwicklungszweig Net-Next in den Hauptzweig der Kernel-Entwicklung integriert. Damit wird WireGuard erstmals Teil eines stabilen Linux-Kernels. Der Kernel 5.6 wird für Anfang April erwartet. Grund der langen Verzögerung war der Crypto-Unterbau von WireGuard, welcher einen anderen Ansatz als die Crypto-API des Linux-Kernels verfolgt und deshalb für Unstimmigkeiten gesorgt hatte. Letztlich wurden die neuen Crypto-Funktionen aber im kürzlich veröffentlichten Kernel 5.5 umgesetzt.

Technik

Der Grundgedanke hinter WireGuard ist erfrischend neu und simpel. WireGuard arbeitet ausschließlich auf Schicht 3 des OSI-Modells und ermöglicht die Netzwerkkopplung auf Peer-to-Peer-Basis. Softwareseitig gibt es keine Unterschiede zwischen den Teilnehmern. Alleine die Konfiguration entscheidet, ob ein Peer als Client oder Server arbeitet. Aus diesem Grund sind sogenannte Road-Warrior-Szenarien mit einem zentralen Server und mehreren Clients kein Problem.

Unterstützt wird neben IPv4 auch IPv6. Des Weiteren kann IPv4 in IPv6 getunnelt werden und umgekehrt. Die Verbindung zwischen zwei Peers wird über einen einzelnen, frei wählbaren UDP-Port geregelt. Standardmäßig ist dies UDP-Port 51820.

Zum Verbindungsaufbau wird auf beiden Seiten der VPN-Verbindung lediglich ein Schlüsselpaar benötigt. Der private Schlüssel bleibt dabei lokal, der öffentliche Schlüssel wird der Gegenstelle bekannt gemacht. Auf eine Zertifikat-Infrastruktur kann getrost verzichtet werden. Außerdem kann optional ein symmetrischer Schlüssel (PSK) verwendet werden, der die Verbindung zusätzlich sichert.

Andere VPN-Protokolle unterstützen eine Vielzahl von Algorithmen zum Schlüsselaustausch, zum Chiffrieren und zur Hash-Berechnung. WireGuard geht einen anderen Weg und kennt für jede Aufgabe nur einen fest codierten Algorithmus. Curve25519 für den Schlüsselaustausch, ChaCha20 für die Verschlüsselung, Poly1305 für die Authentifizierung, BLAKE2 für das Hashing und SipHash24 für die Hashtable.

Durch die vollständige Neuentwicklung und den Fokus auf Grundfunktionen kann komplett auf Altlasten verzichtet werden, was sich auch im Quelltext zeigt. Während OpenVPN und IPSec auf mehrere Hunderttausend Zeilen Code kommen, begnügt sich WireGuard mit ca. 7.000 Zeilen.

Ein weiteres Merkmal ist das eingebaute “Roaming”. Wechselt ein Peer (Client), also z.B. ein Smartphone, zwischen WLAN und Mobilfunknetz, bleibt die WireGuard-Verbindung bestehen und der Anwender bekommt davon nichts mit. Selbst wenn es in seltenen Fällen zu einem Verbindungsabbruch führt, ist die Verbindung fast unmittelbar wiederhergestellt. Andere VPN-Protokolle wie IPSec oder OpenVPN sind im direkten Vergleich quälend langsam.

Die gute Performance ist unter anderem darin begründet, dass WireGuard unter Linux direkt im Kernel arbeitet. Somit entfallen häufige Kontextwechsel zwischen Userland und Kernel und die Datenpakete können deutlich schneller abgearbeitet werden. Zudem besitzt WireGuard spezielle Optimierungen für die MIPS-Prozessor-Architektur, sodass es auch für leistungsschwache Geräte interessant ist.

Fazit

Ich habe WireGuard vor ca. fünf Monaten auf meinem Raspberry Pi und meinem Smartphone installiert. Seitdem ist mein Smartphone zu 100% über den WireGuard-VPN-Tunnel online. Weder daheim noch unterwegs musste ich bisher irgendwelche Probleme feststellen. Die Performance ist super und das Roaming-Verhalten spitze. Wie vom Entwickler versprochen gibt es hier keine Abbrüche oder Verzögerungen. Einziger Negativpunkt ist das spärliche Logging auf beiden Seiten.

In einem weiteren Artikel werde ich detailliert auf die Einrichtung unter Raspbian Buster und Android eingehen. Stay tuned!

Cisco und der Verpackungswahn

Cisco Logo

Cisco bietet die Möglichkeit nur wenige Monate oder Wochen benutzte Hardware zu signifikant günstigeren Preisen zu erwerben. Diese Cisco Refresh Produkte sind generalüberholt, vollständig zertifiziert und von neuer Hardware quasi nicht zu unterscheiden. Auch bei der Garantie und Lizenzierung gibt es keine Nachteile. Gute Gründe, um bei Neuanschaffungen über entsprechende Produkte nachzudenken.

Anhand einiger SFP-Module (GLC-LH-SMD), die via Cisco Refresh bezogen wurden, möchte ich euch gerne den Verpackungswahn bei Cisco zeigen. Die SFPs werden einzeln verpackt geliefert. Im größeren Karton befindet sich zunächst ein kleinerer Karton. Dort ist das Modul in einer antistatischen Verpackung enthalten. Das letzte Bild zeigt 20 ausgepackte SFPs und den entstandenen Kartonabfall. Den Plastikabfall habe ich dabei noch gar nicht berücksichtigt.

Ich stelle mir gerade vor, wie viel Verpackungs- und Transportkosten sich einsparen ließen. Geschweige denn von der unnötig verbrauchten Arbeitszeit während dem Auspacken ;-)