TrueNAS: Fácilmente se configura la replicación de ZFS sobre Wireguard VPN

Wireguard también ha encontrado su camino en TrueNAS (antes FreeNAS) a través de FreeBSD. Aunque no hay una interfaz para configurarlo directamente, se puede cargar un archivo de configuración adecuado a través de un script post-inicio y luego también se establece la conexión.

La ventaja sobre el solución previaNo se necesita una máquina virtual, que a su vez necesita sus propias actualizaciones, puede colgar tiempos y consume los recursos adicionales. Todo lo que necesitas ya está incluido en el sistema central, prácticamente sólo falta la configuración, esto lo he tomado completamente de mi configuración anterior, de lo contrario también puedes crear un nuevo archivo.

En mi configuración el archivo de configuración se encuentra en

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

El archivo en sí corresponde entonces a una configuración normal de Wireguard. Como sólo quiero enrutar el tráfico al servidor del otro extremo a través de la VPN, el parámetro "AllowedIPs" está restringido en consecuencia:

[Interfaz]
# La dirección debe ser única para cada cliente, use "10.8.0.3/24" para el segundo cliente y así sucesivamente.
Dirección = 10.8.0.4/24
PrivateKey = WIREGUARD-PRIVATE-KEY

# Comente lo siguiente para preservar el servidor DNS predeterminado de los clientes, o forzar uno deseado.
DNS = 8.8.8.8

[Peer]
PublicKey = WIREGUARD-PUBLIC-KEY
# Túnel de acceso a la red local del lado del servidor solamente:
PIs permitidos = 192.168.178.0/24
Punto final = wireguard.server.net:51820

# Descomente lo siguiente, si está detrás de un NAT y quiere que la conexión se mantenga viva.
PersistentKeepalive = 25

La conexión se inicia por medio de:

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

o por medio de

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

terminado de nuevo. La ruta necesaria, para que el servidor en la otra red (en mi caso esta corre en la IP 192.168.178.31) pueda ser alcanzada, es fijada automáticamente por el cliente de Wireguard.

Un problema permanece aquí también: si se usan direcciones IP dinámicas y éstas cambian, el cliente de Wireguard inicialmente no es consciente de ello. Para ello, la solución de guión correspondiente para el Comprobación de IP de pares de Wireguard adaptado a los comandos apropiados de FreeBSD (en lugar de reiniciar el servicio una vez y reiniciarlo inmediatamente después, los otros elementos utilizados, como "dig", también están presentes en TrueNAS:

#!/bin/bash
# Comprobar el estado de la interfaz
# wg0-cliente: nombre de la interfaz a comprobar
# meinpeer.dyndns.net: el nombre del par cuya IP debe ser comprobada
        
cip=$(wg show wg0-client endpoints | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}")
eco "$cip"
digIP=$(dig +short meinpeer.dyndns.net) # La dirección del par debe ser ajustada
   eco "$digIP"
     si [ "$digIP" != "$cip" ]
       entonces
          eco "Los datos son diferentes"
          wg-quick down /path/to/wg0-client.conf
          wg-quick up /path/to/wg0-client.conf
        más
    eco "Los datos son los mismos"
    #Nada que hacer
   fi

El guión sólo es ejecutado por cronjob cada 5 minutos, tan pronto como la dirección IP no coincide con la conexión se restablece:

Lo que todavía es necesario con esta solución: una "estación remota" en la otra red donde se encuentra el servidor que se replica. En mi configuración no hay problema, porque uso un Pi de frambuesa, que es el El servidor también inicia el control de tiempo. Por lo tanto, si puede configurar la funcionalidad de guardaespaldas incorporada de TrueNAS para aceptar conexiones entrantes es algo que aún no he intentado.

El resto de los pasos después de establecer la conexión VPN se hacen fácilmente y se describen perfectamente en la documentación oficial de TrueNAS descrito. Básicamente, la replicación a través de VPN funciona de la misma manera que en la red local, una encriptación adicional no es realmente necesaria, pero por supuesto puede ser utilizada.

Incluso si un NAS sigue sin ser una copia de seguridad, duermes mejor con la distribución de los datos en dos lugares físicamente separados (en mi caso también varios cientos de kilómetros de distancia entre sí), que si los datos se encuentran, por ejemplo, en uno de los grandes proveedores de nubes - aparte del hecho de que varios terrabytes de datos luego se vuelven un poco caros en AWS y un viejo HP Proliant N36L es perfectamente adecuado para este propósito.

Actualización: script de comprobación de IP de pares ampliado

A veces ocurre que la conexión de Wireguard con la dirección IP correcta está disponible, pero todavía no hay conexión con la red de atrás. Para evitar esto, he añadido un comando "ping" al script, que comprueba si el servidor de destino está disponible y reconecta Wireguard si es necesario:

#! /bin/bash
# Comprobar el estado de la interfaz
# wg0-client: nombre de la interfaz a comprobar
# meinpeer.dyndns.net: el nombre del par cuya IP debe comprobarse
        
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) 1TP3Cambiar la ip al servidor de destino
digIP=$(dig +short mypeer.dyndns.net) #hay que poner la dirección del peer
   echo "$digIP"
     if [ "$digIP" != "$cip" ]
       entonces
          echo "Las IPs no coinciden, reiniciando wireguard"
          wg-quick down /ruta/al/wg0-client.conf
          wg-quick up /ruta/al/wg0-client.conf
        elif [ "$pingip" != "success"]
        echo "Ping fallado, reiniciando wireguard..."
          wg-quick down /ruta/al/wg0-client.conf
          wg-quick up /ruta/al/wg0-client.conf
        si no
          echo "OK"
          1TP3Nada más que hacer
      fi