TrueNAS: ZFS-Replication über Wireguard-VPN einfach einrichten

Wireguard hat über FreeBSD auch den Weg in TrueNAS (bisher FreeNAS) gefunden. Zwar gibt es keine Oberfläche, um es direkt zu konfigurieren, eine passende Konfigurations-Datei kann aber über ein Post-Init-Script geladen werden und stellt dann auch die Verbindung her.

Der Vorteil gegenüber der bisherigen Lösung: es wird keine virtuelle Maschine benötigt, die wiederum eigene Updates benötigt, sich mal aufhängen kann und die zusätzliche Ressourcen verbraucht. Alles was man benötigt, ist im Kernsystem bereits enthalten, es fehlt praktisch nur die Konfiguration, diese habe ich komplett von meinem bisherigen Setup übernommen, ansonsten kann man auch eine neue Datei erstellen.

In meinem Setup liegt die Konfigurations-Datei in

/mnt/VM/wireguard/wg0-client.conf

Die Datei selbst entspricht dann einer normalen Wireguard-Konfiguration. Da ich nur den Traffic zum Server am anderen Ende durch das VPN leiten will, ist der Parameter „AllowedIPs“ entsprechend eingeschränkt:

[Interface]
# The address must be unique for each client, use "10.8.0.3/24" for the second client and so on.
Address = 10.8.0.4/24
PrivateKey = WIREGUARD-PRIVATE-KEY

# Comment the following to preserve the clients default DNS server, or force a desired one.
DNS = 8.8.8.8

[Peer]
PublicKey = WIREGUARD-PUBLIC-KEY
# Tunnel access to server-side local network only:
AllowedIPs = 192.168.178.0/24
Endpoint = wireguard.server.net:51820

# Uncomment the following, if you're behind a NAT and want the connection to be kept alive.
PersistentKeepalive = 25

Gestartet wird die Verbindung mittels:

wg-quick up /Pfad/zur/wg0-client.conf

bzw. mittels

wg-quick down /Pfad/zur/wg0-client.conf

wieder beendet. Die erforderliche Route, damit der Server im anderen Netzwerk (in meinem Fall läuft dieser auf der IP 192.168.178.31) erreichbar ist, setzt der Wireguard-Client automatisch.

Eine Problematik bleibt auch hier: wenn sich bei der Verwendung von dynamischen IP-Adressen diese ändern, bekommt der Wireguard-Client davon erst einmal nichts mit. Dafür wird die entsprechende Script-Lösung für den Wireguard-Peer-IP check angepasst auf die entsprechenden FreeBSD-Kommandos (statt eines Restart des Service wird er einmal deaktiviert und direkt danach wieder gestartet, die anderen verwenden Elemente wie „dig“ sind auch im TrueNAS vorhanden:

#!/bin/bash
# Status von der Schnittstelle überprüfen
# wg0-client: Name der Schnittstelle, die geprüft werden soll
# meinpeer.dyndns.net: der Name des Peers, dessen IP geprüft werden soll
        
cip=$(wg show wg0-client endpoints | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}")   
echo "$cip"
digIP=$(dig +short meinpeer.dyndns.net) # Die Adresse des Peers muss angepasst werden
   echo "$digIP"
     if [ "$digIP" != "$cip" ]
       then
          echo "Daten sind anders"
          wg-quick down /Pfad/zur/wg0-client.conf
          wg-quick up /Pfad/zur/wg0-client.conf
        else 
    echo "Daten sind gleich"
    #nichts zu tun
   fi

Das Script wird nur per Cronjob alle 5 Minuten ausgeführt, sobald die IP-Adresse nicht übereinstimmen wird die Verbindung neu aufgebaut:

Was mit dieser Lösung immer noch notwendig ist: eine „Gegenstelle“ im anderen Netzwerk, in dem der Server steht, auf den Repliziert wird. In meinem Setup kein Problem, da ich einen Raspberry Pi verwende, der den Server auch zeitgesteuert startet. Ob man die in TrueNAS integrierte Wireguard-Funktionalität so konfigurieren kann, dass sie eingehende Verbindungen akzeptiert, habe ich daher bisher nicht ausprobiert.

Die restlichen Schritte nach dem Aufbau der VPN-Verbindung sind dann einfach erledigt und ist in der offiziellen TrueNAS-Dokumentation perfekt beschrieben. Grundsätzlich funktioniert die Replikation über VPN genauso wie im lokalen Netzwerk, eine zusätzliche Verschlüsselung ist eigentlich nicht nötig, kann aber natürlich verwendet werden.

Auch wenn ein NAS nach wie vor kein Backup ist, schläft man mit der Verteilung der Daten auf zwei physikalisch getrennte Orte (in meinem Fall auch mehrere hundert Kilometer von einander getrennt) besser, als wenn die Daten z.B. bei einem der großen Cloud-Anbieter liegen – abgesehen davon, das mehrere Terrabyte an Daten dann doch etwas teuer werden bei AWS und ein alter HP Proliant N36L vollkommen ausreichend ist für diesen Zweck.

Update: erweitertes Peer-IP-Check-Script

Manchmal passiert es, dass die zwar die Wireguard-Verbindung mit der richtigen IP-Adresse vorhanden ist, aber trotzdem keine Verbindung zum dahinterliegenden Netzwerk besteht. Um das zu vermeiden, habe ich das Script um einen „ping“-Befehl ergänzt, der Prüft ob der Zielserver erreichbar ist und ggf. ebenfalls Wireguard neu verbindet:

#!/bin/bash
# Status von der Schnittstelle überprüfen
# wg0-client: Name der Schnittstelle, die geprüft werden soll
# meinpeer.dyndns.net: der Name des Peers, dessen IP geprüft werden soll
        
cip=$(wg show wg0-client endpoints | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}")   
echo "Wireguard peer IP from Interface: $cip"
pingip=$(ping -c 1 192.168.178.10 &> /dev/null && echo success || echo fail) #change ip to target server
digIP=$(dig +short mypeer.dyndns.net) #the peer address must be set
   echo "$digIP"
     if [ "$digIP" != "$cip" ]
       then
          echo "IPs doesn't match, restarting wireguard"
          wg-quick down /path/to/wg0-client.conf
          wg-quick up /path/to/wg0-client.conf
        elif [ "$pingip" != "success"]
        echo "Ping failed, restarting wireguard..."
          wg-quick down /path/to/wg0-client.conf
          wg-quick up /path/to/wg0-client.conf
        else 
          echo "OK"
          #nothing else todo
      fi