Simlau.net BlogOpenSource, Devops and Development since 2006

Wireguard in der Hetzner Cloud

Durch einen meiner Kunden bin ich auf das Wireguard Projekt aufmerksam geworden.

Bei WireGuard handelt es sich um ein sehr simples und doch hochperformantes VPN, welches anders als OpenVPN und Co. direkt auf Linux Kernel Ebene arbeitet. Die Konfiguration beschränkt sich dabei per Interface auf eine einzige Konfigurationsdatei (hier /etc/wireguard/wg0.conf auf server01.example.tld)

[Interface]
Address = fd86:ea04:1115:0:5054:ff:fefd:e128/64
SaveConfig = false
ListenPort = 51820
PrivateKey = QKFKDqpg6oDFbnhq/WfNhExbi5IqTU+8GDOLb7E+9HU=

[Peer]
PublicKey = p+PusqlRIQ1cvdNIvfXXEBlf2puVHkfk/vGv9KCn9FQ=
Endpoint = server02.example.tld:51820
AllowedIPs = fd86:ea04:1115:0:11:32ff:fe27:3e3e/128

Ich nutze WireGuard um ein internes Netz über mein Heimnetzwerk und mehrere Clouds (Azure, AWS, Hetzner) hinweg ein internes IPv6 Netz zu spannen. Über dieses Netz laufen diverse Backend Dienste (wie Prometheus, Icinga, Consul, Vault, Nomad), die nicht direkt von extern erreichbar sein müssen.
Der große Vorteil liegt für mich darin, das die Kommunikation dezentral (also direkt von System zu Zielsystem) erfolgt. Ich muss somit keinen zentralen VPN-Server betreiben, der unter Umständen einen SPOF in meinem Setup darstellen könnte.

Vor kurzem habe ich dann einige Systeme in der Hetzner Cloud in Betrieb genommen (Ubuntu 18.04 LTS). Diese wollte Ich natürlich ebenfalls in meinen WireGuard Mesh mit aufnehmen.

Hier hatte ich jedoch das Problem, das nach dem Starten des WireGuard Tunnels kein IPv6 Verkehr außerhalb des Tunnels mehr möglich war. Lediglich ping6 funktionierte noch, vorausgesetzt man hat das Default Interface (Option -I eth0) mit angegeben.

Da das ganze auf anderen Ubuntu Systemen reibungslos funktionierte, war schnell klar das das Hetzner Basis Image schuld sein muss.

Nach langem Troubleshooting des IPv6 Routings konnte ich das Problem dann auch ausfindig machen.
Hetzner konfiguriert die Netzwerkkonfiguration mittels cloud-init folgendermaßen vor (/etc/network/interfaces.d/50-cloud-init.cfg).

...
auto eth0:0
iface eth0:0 inet6 static
address 2a01:1234:1234:1234::1/64
gateway fe80::1
post-up route add -net :: netmask 0 gw fe80::1%eth0 || true
pre-down route del -net :: netmask 0 gw fe80::1%eth0 || true

Diese Konfiguration ist aber kaputt. Die Pre- und Post-Scripte führen zu einem Fehler. Weiterhin führt das Alias Interface (eth0:0) bzw. das fehlen einer IPv6 Adresse auf eth0 dazu, das mit der Konfiguration einer weiteren IPv6 Adresse (auf einem anderen Interface) kein IPv6 mehr funktioniert.

Die Lösung ist die Konfiguration auf das empfohlene Schema umzustellen und die IPv6-Adresse auf eth0 umzuziehen.

...
auto eth0
iface eth0 inet6 static
address 2a01:1234:1234:1234::1
netmask 64
gateway fe80::1

Alternativ kann auch komplett auf die „Legacy Konfiguration“ via /etc/network/interfaces verzichtet werden.

Ein Nachteil von Wireguard ist das das nötige Kernel Modul aktuell noch nicht nativ im Kernel von gängigen Linux Distributionen vorhanden ist. Daher ist die Installation via DKMS (Dynamic Kernel Module Support) nötig. In Zukunft soll sich das aber noch ändern.

Vorstellung meines Heimnetzwerks

Da ich letzter Zeit immer wieder von Bekannten und Kunden über mein Heimnetzwerk ausgefragt werde, habe ich beschlossen dazu mal wieder einen kleinen Artikel zu schreiben.

Im ersten Teil gebe ich euch einen Überblick über meine bisherigen Erfahrungen und die aktuell „wichtigsten Geräte“, die bei mir im Dauerbetrieb sind. Eventuell folgt dann noch ein zweiter Teil über die Realisierung meiner Homeautomatisierung (mit Homebridge, Homematic, Brematic, …).

Router
Ich setze seit ich denken kann auf AVM Hardware. Derzeit ist bei mir eine Fritz!Box 7490 an einem Telekom VDSL Anschluss mit 100 Mbit im Einsatz. Gelegentlich fehlen mir zwar einige Möglichkeiten in der Box, dennoch habe ich bisher keine bessere Alternative in Sachen VDSL finden können.

Zeitweise hatte ich zwischen LAN und Fritz!Box noch einen zusätzlichen Router. Dieser diente als zusätzliche Firewall – zum Tracken des Netzwerkverkehrs und für Dinge wie IPS/IDS. Ich habe sowohl mit einem Ubiquiti Security Gateway als auch mit einem eigenen Router auf Linux Basis experimentiert. Gerade das Ubiquiti Security Gateway bietet wunderschöne Übersicht über das, was da eigentlich so im eigenen Netzwerk nach Hause telefonieren möchte. Dennoch war ich mit beiden Lösungen nicht wirklich zufrieden.

Ein Grund hierfür war das ich durch das zusätzliche Gerät viele Probleme mit IPv6 bekommen hatte. Als Privatkunde bei Telekom besitze ich keinen festen IPv6 Prefix. Dies erschwert die Prefix Delegation an den Zwischenrouter. Eine mögliche Lösung wäre sicher ein „reines Modem“ vor den Router zu schalten bzw. den Router die Internetverbindung via PPoE aufbauen zu lassen. Mit dieser Idee war ich bisher aber nicht ganz glücklich.
Da ich das Setup Zuhause ohnehin möglichst einfach halten möchte habe ich mich dazu entschlossen das Thema mit dem Zwischenrouter vorerst nicht weiter zu betrachten.

Die Fritz!Boxen die bei mir bisher im Einsatz waren haben alle anstandslos ihren Dienst verrichtet. Lediglich einen Ausfall musste ich verzeichnen – und dieser war in Verbindung mit Überspannung bei einem Blitzeinschlag. Dennoch gab es damals einen Ersatz von AVM mit einem komplett neuen Gerät.

Alles in allem bin ich mit der Stabilität vollstens zufrieden.

WLAN
Nicht so glücklich mit der AVM Hardware bin in Sachen WLAN. Gerade mit meinen Apple Geräten hatte ich immer wieder Verbindungsprobleme zum WLAN. Die Leidensgeschichte ist hier wirklich lange.

Mögliche Lösungsansätze waren dabei unter anderem:

• Wechsel von Fritz!Box 7390 zu Fritz!Box 7490
• Einbau von größeren Antennen in die Fritz!Box („FriXtender XL“)
• Erweiterung des WLANs mittels AVM FRITZ!WLAN Repeater 1750E (via LAN)
• Weitere Tests mit AVM Fritz Powerline

Keines der Produkte hatte Besserung gebracht. Da Netflix aber ein immer wichtigerer Bestandteil der Abendunterhaltung wurde und selbst kurze „Ausfälle“ hier für viel Frust sorgten (Stichwort WAF – Woman Acceptance Factor) musste eine neue Lösung her. Gefallen ist meine Entscheidung auf Ubiquiti – die für einen erschwinglichen Preis wirklich ein ausgezeichnete Qualität an Hardware liefern.

Derzeit sind bei mir zwei Ubiquiti UniFi AP-AC-Pro Access Points im Einsatz. Einer davon befindet sich im Erdgeschoss, einer im Keller.

Mit Einsatz dieser Access Points haben sich alle WLAN Probleme in Luft aufgelöst. Die WLAN Verbindung funktioniert seither sowohl im 2,4 GHz als auch im 5 GHz Band einwandfrei. Das Roaming zwischen beiden Access Points klappt zuverlässig und ist selbst bei einem laufenden Stream nicht bemerkbar.

Switches
Nachdem ich von den Access Points von Ubiquiti komplett überzeugt wurde wollte ich auch mein Netzwerk auf Ubiquiti SDN umstellen. Die Wahl ist hier auf einen UniFi 8 Port Switch mit PoE gefallen. Dieser verrichtet seither problemlos seine Arbeit und versorgt einen der beiden Access Points via PoE mit Strom.

Der Austausch eines anderen Switches im Keller durch den gleichen oder einen größeren Unifi Switch steht noch aus.

Storage
Ein Thema was ich wirklich sehr lange vor mir hergeschoben habe war das Thema Backup. Ein Grund hierfür war das ich lange Zeit nicht bereit war einen größeren Betrag für eine NAS Storage. Also bestand mein Konzept bis dahin aus einer Mischung von Google Drive und Backups auf USB Festplatten. Nie hatte man die Daten dabei, die man gerade brauchte. Zudem wurden die Backups natürlich auch nur dann gemacht, wenn die USB Disk an das Macbook angeschlossen wurde.

Als ich mich aber 2017 komplett selbstständig gemacht hatte und somit nicht nur aus steuerrechtlichen Gründen ein funktionierendes, verlässliches Backup unumgänglich wurde habe ich investiert.

Nach vielen Gesprächen mit Kunden und Bekannten, Tests und der Überlegung eventuell sogar einen komplett eigenen Rechner zu bauen habe ich mich für eine Synology Disk Station entschieden und bin seitdem mit dieser wunschlos glücklich.

Im Einsatz ist eine DS918+ mit 4 Bays, die auf 16 GB RAM erweitert wurde. Als Disks sind zwei WD Red WD60EFRX (6 TB) sowie zwei Samsung SSD 860 EVO (500 GB) eingebaut – jeweils im RAID 1. Die wichtigsten Daten (mit häufigem Zugriff) liegen auf dem SSD RAID. Das HDD RAID dient als Storage für Backups von Macbook und Linux Servern, aber auch für das Backup des SSD RAIDs.

Anfangs ist es etwas ungewöhnlich die Konfiguration über eine Art „Windows Desktop“ im Browser durchzuführen. Daran hat man sich aber schnell gewöhnt – zumal auch ein vollständiges Linux und Docker auf der Synology zur Verfügung stehen.

Synology liefert wirklich gute Hardware mit ausgezeichnet gepflegter Software aus. Für erfahrene Benutzer lässt sich die NAS durch AddOns in alle Richtungen erweitern. Ich habe die Entscheidung zu keinem Zeitpunkt bereut und kann seitdem deutlich ruhiger schlafen.

Server, Virtualisierung
Als IT Berater benötigt man natürlich auch etwas Hardware, auf der man einfach mal ein paar Dinge ausprobieren kann. Grundsätzlich kann zwar durchaus ein, zwei VMs auf der Synology DS918+ hosten, man kommt man hier aber doch sehr schnell an die Grenzen der CPU, die einfach nicht für die Virtualisierung geeignet ist. Auch arbeite ich in Bereichen, in denen fertige Appliances vom Hersteller geliefert werden und es teilweise unmöglich ist diese auf einem KVM/QEMU zu betreiben (Stichwort VirtIO Treiber).

Dieses Problem habe ich mit einem Intel NUC NUC8i7BEH2 gelöst, der mit einer M2 SSD und 16 GB RAM ausgestattet ist. Das Gerät ist kaum hörbar, extrem stromsparend und beheimatet aktuell eine Installation von ESXi 6.7.

Auf dem NUC laufen neben dem hauseigenen Active Directory (Windows Server 2019) und der Nextcloud Instanz (Ubuntu 18.04) derzeit hauptsächlich kleinere Test-VMs (u.a. RHEL 8 Beta, Oracle Linux, …), die ich für Demos und Trainings bei meinen Kunden nutze.

Wenn es so weit sein wird das sich mein Sohn für das Internet interessiert, wird vermutlich noch eine weitere VM auf dem ESXi einziehen – eine Sophos UTM. Dabei handelt es sich um eine linuxbasierte Firewall bzw. ein Internet Security Gateway. Diese wird sich dann um die Filterung des Web Traffic übernehmen. Die Sophos UTM lässt sich problemlos auf einem ESXi als virtuelle Maschine betreiben – als Privatanwender auch vollkommen kostenlos.

Philips 55PUS7303 – Android Smart TV per REST steuern

Bisher hatte ich meine Fernseher hauptsächlich als reines Anzeigegerät genutzt und „smarte Funktionen“ auf externe Geräte (wie meinen Apple TV oder einen Raspberry Pi) ausgelagert. Dieses Konzept hat die letzten Jahre gut funktioniert.

Da nun aber mein alter Fernseher vor einigen Monaten seinen Dienst aufgegeben hat (und er damit verdient in seine Rente gehen durfte), war ich auf der Suche nach einem neuen TV Gerät.

Die Wahl ist nach langer Überlegung letztlich auf einen Philips 55PUS7303 gefallen – ein Android TV. Meine Hoffnung durch Android ist eine längere Unterstützung von Firmware Updates vom Hersteller, bzw. später ggf. auch die Möglichkeit für eine Custom Firmware.

Einbindung in die Home Automatisierung.
Mit einem vollständigen Android ausgestattet war ich nun auf der Suche nach einer Lösung diesen Fernseher auch komplett in die Home Automatisierung einzubinden.

• Gerät ein- und ausschalten
• Lautstärke anpassen
• Kanäle und Eingänge wechseln
• Steuerung der Hintergrundbeleuchtung (Ambilights)

Die erste Überlegung in Sachen Android war das ganze über ADB (die Android Debug Bridge) zu lösen. Also ein passendes USB Kabel bestellt, den Entwickler Modus in den Einstellungen aktiviert und die ADB Kopplung gestartet. Am Ende konnte ich zumindest die Lautstärke problemlos regeln. Glücklich war ich mit dieser Lösung allerdings nicht, zumal ich auch gerne auf das Android SDK auf meiner Steuerzentrale verzichten wollen würde.

Nach weiterer Recherche bin ich auf ein Bash Script zur Steuerung von Philips TVs bei GitHub gestoßen.
Dieses Tool nutzt die sogenannte Jointspace API, mit der Philips TVs ausgestattet sind. Darüber kann nahezu jede Funktion ausgeführt werden, die sich auch mit der normalen Fernbedienung steuern lässt. Die API ist unter den folgenden TCP Ports auf dem Fernseher erreichbar.

• Port 1925 – JointSpace HTTP
• Port 1926 – JointSpace HTTPS

Authentifizierung über die API
Die API benötigt (ab der bei mir eingesetzten Version 6) für gewisse Funktionen eine gültige Authentifizierung. Dabei handelt es sich um eine Device ID als Benutzernamen sowie einem zugehörigen Kennwort. Das Kennwort erhält man durch den Kopplungsprozess der Device ID, bei dem man lediglich den PIN vom Display des Fernseher ablesen muss. Das Bash Script übernimmt diesen Job und schreibt die Credentials dabei direkt in die Datei im aktuellen Verzeichnisses.

.credentials.tv

Diese Credentials kann man dann nutzen um sich mit der API zu verbinden. Einige Beispiele für die Verwendung findet man direkt im Script.

Um zum Beispiel die Lautstärke auf Mute zu stellen kann man folgenden cURL Aufruf verwenden.

-bash# curl -XPOST -u $DEVICEID:$PASSWORD https://10.0.0.34:1926/6/input/key -d "{'key': 'Mute'}" -k --digest -v

Wichtig ist das die Credentials im Digest Format übertragen werden müssen.

Eine API Dokumentation mit möglichen Kommandos findet man hier.

Anschalten des Geräts
Es gibt zwar auch die Möglichkeit den Fernseher über die API anzuschalten, allerdings schaltet der Fernseher nach einiger Zeit im Standby die Netzwerkfunktion ab. Dies ist für meinen Einsatz allerdings kein Problem. Der Fernseher hängt bei mir stromtechnisch an einer schaltbaren Homematic Funksteckdose und wird ohnehin nur bei Bedarf eingeschaltet. Sobald das Gerät Strom bekommt startet es automatisch und stellt den zuletzt bekannten Status bzw. Kanal wieder her.

Automatic reboots after Linux patches

Vor kurzen habe ich mich in einem Projekt um die Automatisierung von Linux Patches gekümmert. Nach einem Upgrade ist bekanntlich je nach Art der installierten Updates eventuell ein Restart von bestimmten Diensten oder sogar ein kompletter Reboot notwendig. Der Kunde wollte den Reboot nicht pauschalisieren und hatte dafür bereits eine Lösung parat. Folgenden Codeschnipsel habe ich vorgefunden.

#!/bin/bash
LAST_KERNEL=$(rpm -q --last kernel | perl -pe 's/^kernel-(\S+).*/$1/' | head -1)
CURRENT_KERNEL=$(uname -r)

test $LAST_KERNEL = $CURRENT_KERNEL || echo REBOOT

Kurz gesagt wird einfach geprüft ob das laufende System dem zuletzt installierten Kernel entspricht. Das mag zwar funktionieren, lässt aber viele Aspekte außer Acht. Ein Reboot macht nicht nur beim Update des Kernels, sondern zum Beispiel auch bei der Aktualisierung von Core Libraries (wie etwa glibc) Sinn. Dazu kommen weitere Pakete, die dann schon einiges mehr an Logik im Update Script benötigen.

Zum Glück ist das ganze aber kein neues Thema und wurde schon oftmals von anderen Leuten gelöst. Sowohl für Enterprise Linux als auch für Debian basierte Systeme gibt es jeweils eine sehr schöne und einfache, fertige Lösung.

Enterprise Linux
Für EL basierte Systeme (CentOS, RedHat) heißt der nötige Befehl needs-restarting und wird über das Paket yum-utils (ohnehin auf jedem System sinnvoll) ausgeliefert.

-bash# needs-restarting -r || shutdown -r

Eine erweiterte Möglichkeit bietet auch das YUM Plugin „ps“.

-bash# yum ps
Geladene Plugins: etckeeper, fastestmirror, ps
       pid proc                  CPU      RSS      State uptime
Loading mirror speeds from cached hostfile
 * base: mirror.checkdomain.de
 * epel: mirror.wiuwiu.de
 * extras: mirror.checkdomain.de
 * updates: mirror.checkdomain.de
kernel-3.10.0-862.6.3.el7.x86_64  
         0 <kernel>             0:00      0 B    Running: *4 day(s) 8:55:06

Dieses Plugin bricht das ganze auch auf einzelne Dienste herunter. Sofern also kein Reboot sondern nur ein Neustart eines bestimmten Dienstes notwendig sein sollte kann man das hiermit ebenfalls auslesen.

Debian
Für Debian und Ubuntu heißt das nötige Tool reboot-notifier und sollte meiner Meinung nach ebenfalls auf jedem System installiert sein. Sofern ein Reboot benötigt wird wird durch einen APT Hook das File /var/run/reboot-required angelegt.

[ -f /var/run/reboot-required ] && shutdown -r

Eine erweiterte Möglichkeit bietet checkrestart aus dem Paket debian-goodies.

-bash# checkrestart 
Found 25 processes using old versions of upgraded files
(16 distinct programs)
(11 distinct packages)

Of these, 10 seem to contain systemd service definitions or init scripts which can be used to restart them.
The following packages seem to have definitions that could be used
to restart their services:
uuid-runtime:
	1060	/usr/sbin/uuidd
irqbalance:
	1351	/usr/sbin/irqbalance
accountsservice:
	1382	/usr/lib/accountsservice/accounts-daemon
rsyslog:
	1408	/usr/sbin/rsyslogd
policykit-1:
	1515	/usr/lib/policykit-1/polkitd
openssh-server:
	2068	/usr/sbin/sshd
puppet:
	2546	/usr/bin/puppet
nagios-nrpe-server:
	4590	/usr/sbin/nrpe
ntp:
	4791	/usr/sbin/ntpd
fail2ban:
	5441	/usr/bin/fail2ban-server

These are the systemd services:
systemctl restart accounts-daemon.service
systemctl restart polkit.service

These are the initd scripts:
service uuidd restart
service irqbalance restart
service rsyslog restart
service ssh restart
service puppet restart
service nagios-nrpe-server restart
service ntp restart
service fail2ban restart

These processes (1) do not seem to have an associated init script to restart them:
qemu-system-x86:
	597	/usr/bin/qemu-system-x86_64
	6742	/usr/bin/qemu-system-x86_64
	6822	/usr/bin/qemu-system-x86_64
	6938	/usr/bin/qemu-system-x86_64
	26613	/usr/bin/qemu-system-x86_64
	26948	/usr/bin/qemu-system-x86_64
	31880	/usr/bin/qemu-system-x86_64
	32553	/usr/bin/qemu-system-x86_64
	32632	/usr/bin/qemu-system-x86_64

Upgrading your infrastructure to Puppet 4

Immer noch Puppet v3.x im Einsatz? Langsam wird es höchste Zeit auch deine letzten Systeme auf Puppet 4 umzustellen. Puppet 3 ist mittlerweile schon seit dem 31.12.2016 End of Life und viele Module aus der Forge sind längt nur mehr für Puppet 4 und aufwärts verfügbar.

In der Regel bedeutet die Umstellung von Puppet 3 auf Puppet 4 zwar eine Menge Arbeit, es lohnt sich aber definitiv. Welchen Performance Boost mit Puppet 4 beim Compiling eines Catalogs herausholen kann zeigt der folgende Auszug (aus Foreman) aus einem meiner aktuellen Projekte (ein Kunde mit ca. 1000 Puppet Nodes).

Die Grafik zeigt die Dauer eines Puppet Laufs – vor und nach dem Upgrade auf Puppet 4 der Node. Ein weiterer Boost mit dem nachgelagerten Upgrade auf Puppet 5.x steht noch aus.

Die Basis für das Upgrade auf Puppet 4 war dort insbesondere das weitreichende Testing des Codes via Jenkins CI Jobs und verschiedenen Tools. Dadurch konnten alle problematischen Stellen im Code gefunden und direkt ausgebessert werden. Einen ersten Überblick über die nötigen Änderungen kann der Puppet 4 Upgrade Guide geben.

Ein großartiges Tool für den Vergleich zwischen Katalogen („was passiert bei einem Upgrade auf v4?“) ist octocatalog-diff von GitHub.

Noch keine Strategie für das Upgrade auf Puppet 4.x? Setzt euch gerne mit mir in Verbindung und wir besprechen wie ich euch unterstützen kann.