TrueNAS : Configurer facilement la réplication ZFS via Wireguard VPN

Wireguard a également trouvé son chemin dans TrueNAS (anciennement FreeNAS) via FreeBSD. Bien qu'il n'y ait pas d'interface pour le configurer directement, un fichier de configuration approprié peut être chargé via un script post-init et établit alors également la connexion.

L'avantage par rapport à la solution précédenteIl n'est pas nécessaire d'avoir une machine virtuelle, qui a besoin de ses propres mises à jour, peut se bloquer et consomme des ressources supplémentaires. Tout ce dont vous avez besoin est déjà inclus dans le système de base, pratiquement la seule chose qui manque est la configuration, que j'ai complètement reprise de ma précédente installation, sinon vous pouvez aussi créer un nouveau fichier.

Dans mon installation, le fichier de configuration se trouve dans

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

Le fichier lui-même correspond alors à une configuration normale de Wireguard. Comme je veux seulement acheminer le trafic vers le serveur à l'autre extrémité par le VPN, le paramètre "AllowedIPs" est restreint en conséquence :

[Interface]
# L'adresse doit être unique pour chaque client, utilisez "10.8.0.3/24" pour le deuxième client et ainsi de suite.
Adresse = 10.8.0.4/24
PrivateKey = WIREGUARD-PRIVATE-KEY

# Commentez ce qui suit pour conserver le serveur DNS par défaut des clients ou en forcer un autre.
DNS = 8.8.8.8

[Pair]
PublicKey = WIREGUARD-PUBLIC-KEY
# Accès par tunnel au réseau local côté serveur uniquement :
IPs autorisés = 192.168.178.0/24
Point de terminaison = wireguard.server.net:51820

# Décommentez ce qui suit, si vous êtes derrière un NAT et que vous voulez que la connexion soit maintenue en vie.
PersistantKeepalive = 25

La connexion est lancée au moyen de :

wg-quick up /path/to/wg0-client.conf

ou par le biais de

wg-quick down /path/to/wg0-client.conf

résilié à nouveau. Le client Wireguard établit automatiquement la route nécessaire pour que le serveur de l'autre réseau (dans mon cas, il fonctionne sur l'IP 192.168.178.31) puisse être atteint.

Un problème subsiste ici aussi : si des adresses IP dynamiques sont utilisées et qu'elles changent, le client Wireguard ne le sait pas au départ. À cette fin, la solution de script correspondante pour l'option Vérification de l'IP du pair Wireguard adaptées aux commandes FreeBSD correspondantes (au lieu de redémarrer le service, il est désactivé une fois et redémarré immédiatement après ; les autres éléments utilisés, comme "dig", sont également présents dans le TrueNAS :

#!/bin/bash
# Vérifier l'état de l'interface
# wg0-client : nom de l'interface à vérifier
# meinpeer.dyndns.net : le nom du pair dont l'IP doit être vérifiée.
        
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) # L'adresse de l'homologue doit être ajustée.
   echo "$digIP"
     if [ "$digIP" != "$cip" ]
       puis
          echo "Les données sont différentes"
          wg-quick down /path/to/wg0-client.conf
          wg-quick up /path/to/wg0-client.conf
        sinon
    echo "Les données sont les mêmes"
    #To do nothing
   fi

Le script n'est exécuté par cronjob que toutes les 5 minutes, dès que l'adresse IP ne correspond pas, la connexion est rétablie :

Ce qui est encore nécessaire avec cette solution : une "station distante" dans l'autre réseau où se trouve le serveur vers lequel la réplication a lieu. Dans mon installation, ce n'est pas un problème, car j'utilise un Raspberry Pi, qui Le serveur démarre également le contrôle du temps. Je n'ai donc pas encore essayé si la fonctionnalité de filtrage intégrée dans TrueNAS peut être configurée pour accepter les connexions entrantes.

Le reste des étapes après l'établissement de la connexion VPN est alors facilement fait et est parfait dans la documentation officielle de TrueNAS décrit. Fondamentalement, la réplication via VPN fonctionne de la même manière que dans le réseau local, un cryptage supplémentaire n'est pas réellement nécessaire, mais peut bien sûr être utilisé.

Même si un NAS n'est toujours pas une sauvegarde, vous dormez mieux avec des données réparties sur deux sites physiquement séparés (dans mon cas, plusieurs centaines de kilomètres de distance) que si les données sont stockées, par exemple, chez l'un des grands fournisseurs de nuages - à part le fait que plusieurs téraoctets de données peuvent alors devenir quelque peu coûteux chez AWS et qu'un vieux NAS n'est toujours pas une sauvegarde. HP Proliant N36L est parfaitement adapté à cette fin.

Mise à jour : script de vérification de l'IP du pair étendu

Il arrive parfois que la connexion Wireguard avec l'adresse IP correcte soit disponible, mais qu'il n'y ait toujours pas de connexion au réseau derrière elle. Pour éviter cela, j'ai ajouté une commande "ping" au script, qui vérifie si le serveur cible peut être atteint et reconnecte Wireguard si nécessaire :

#!/bin/bash
# Vérifier l'état de l'interface
# wg0-client : nom de l'interface à vérifier
# meinpeer.dyndns.net : le nom du pair dont l'IP doit être vérifiée.
        
cip=$(wg show wg0-client endpoints | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}")
echo "Wireguard peer IP de l'interface : $cip"
pingip=$(ping -c 1 192.168.178.10 &> /dev/null && echo success || echo fail) 1TP3Changer l'ip du serveur cible
digIP=$(dig +short mypeer.dyndns.net) #l'adresse du pair doit être définie
   echo "$digIP"
     if [ "$digIP" != "$cip" ]
       puis
          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
        sinon
          echo "OK"
          #rien d'autre à faire
      fi