Sauvegarde avec Borgbackup et Wireguard🔗
Introduction
Si vous avez lu ma page dédiée à mon infrastructure de sauvegarde, vous savez que j'utilise Borg et que mon installation est particulière.
En effet, le serveur de sauvegarde n'est pas relié directement au réseau local (qui est en Wifi chez moi) mais relié en Ethernet à une station de travail principale. Cette dernière héberge le contenu le plus volumineux et relier le serveur de sauvegarde directement par un câble réseau me permet de disposer d'un débit de l'ordre du Gigabit/seconde soit près de 125Mo/seconde. Le Wifi ne monterait qu'à 54MBit/s soit 6,5Mo/seconde, près de 20 fois plus lent.
Donc, ma station de travail qui est également reliée au Wifi sert de passerelle Wifi au serveur de sauvegarde. Dans un sens j'ai le meilleur des deux mondes, car les clients à sauvegarder du réseau local peuvent tous attaquer le serveur local via la station de travail.
Néanmoins depuis près d'un an, je loue un serveur dans le "cloud" et j'ai besoin de récupérer une partie de son contenu pour faire une sauvegarde. Or, il est difficile pour ce serveur de franchir les 2 NAT.
J'ai testé l'utilisation de SSHFS et je dois dire que, même si ça marchait, je n'étais pas du tout satisfait des performances.
Au final, après avoir déployé Wireguard sur toutes mes machines, je me suis demandé s'il était simple de passer par le VPN pour faire la sauvegarde du client "cloud". Cet article montre un élément d'explication de la méthode que j'ai employée avec succès.
Un rappel du schéma d'infrastructure de backup
Voici un petit schéma de comment le tout est organisé:
_( )_( )_
Wi-Fi (_ _ _)
+--------+ ….. (_) (__)
| | ……. Internet
| | . … . ^ ^
+--------+ . | |
+--------+ +------+ | |
Laptop ^ - - - - - - - - >| |<-----------+ |
+------+ |
Router |
^ |
| |
|
| |
+-------+ +-------+ +----+--+
| | Eth | | | | |
| +<------>+ +< - - - - - + | |
| | | | | |
| | | | | |
+-------+ +-------+ +-------+
BackupServer WorkStation CloudServer
- Workstation fait du NAT pour BackupServer.
- Router fait du NAT pour le réseau local vers Internet.
Configuration du VPN wireguard
Vous allez me dire que Wireguard pour écrire derrière un double NAT c'est un peu overkilling. Vous n'aurez sans doute pas tort mais, à bien y réfléchir, ce n'est pas si compliqué à faire et, dans tous les cas, cela demande bien moins de compétences réseau de bas niveau que d'autres solutions.
Ce qui est bien dans Wireguard, c'est qu'il suffit de peu pour faire en sorte que les clients puissent se parler les uns les autres et ce, peu importe le réseau qui est en dessous. À partir du moment où un client arrive à sortir sur Internet, il fait partie du VPN.
Le principe que j'ai suivi est donné dans l'exemple de passerelle Wireguard que j'ai trouvé sur la mailing list du logiciel.
Globalement il consiste à disposer d'une machine qui servira de passerelle à l'ensemble du VPN. Cette dernière connaît tous les clients potentiels et elle dispose de toutes les clefs publiques des clients du VPN. Chaque client ne connaît que la passerelle et accepte tout ce qui vient du sous-réseau du VPN (la variable AllowedIPs de la passerelle est le sous-réseau Wireguard). De cette manière, la passerelle peut transmettre n'importe quel paquet venu d'un client A vers un client B.
Bien entendu, la passerelle sait faire de l'IP Forwarding.
Dans mon cas, la passerelle est le serveur "Cloud". De cette manière, elle peut facilement atteindre le serveur de sauvegarde via le VPN car Wireguard traverse tous les NAT. L'intérêt de passer par l'interface réseau du VPN (wg0) est que borg ou ssh peuvent l'utiliser directement pour atteindre la machine cible sans avoir à se préoccuper de la gestion réseau derrière.
Configuration nftables fonctionnelle
Mais avant de pouvoir faire passer Wireguard, il faut encore configurer comme il se doit la station de travail et notamment activer le NAT de manière sécurisée. C'est sur ce point que j'ai dû batailler ferme et que j'ai pris le temps de comprendre comment ça fonctionnait.
Globalement, il faut:
- Activer l'ip forwarding au niveau de la station de travail.
- Mettre en place du NAT entre le serveur de sauvegarde et la station de travail vers le LAN et Internet.
- Faire en sorte que la station de travail puisse faire partie du VPN.
L'IP forwarding s'active en indiquant la ligne suivante dans /etc/systctl.conf:
net.ipv4.ip_forward=1
Pour le reste, j'ai utilisé nftables qui est l'outil de configuration de netfilter recommendé dans Debian. Voici mon fichier de configuration que j'ai détaillé:
#!/usr/sbin/nft -f # On vide la table flush ruleset # Gestion de la table ip (v4) table ip filter { # On scanne ce qui passe en entrée chain input { type filter hook input priority 0; policy drop; # On autorise les connexions est déjà acceptées ct state {established, related} accept # On jete ce qui est invalide ct state invalid drop # On accepte ce qui vient de loopback iifname lo accept # On accepte ce qui vient de Wireguard iifname wg0 accept # On accepte le trafic qui vient de la carte Ethernet # C'est tout ce qui vient du serveur de sauvegarde. iifname eno1 accept # On permet le ping ip protocol icmp accept comment "Accept all icmp types" # On accepte tout ce qui vient du réseau local ip saddr 192.168.0.0/24 accept # On rejete le reste counter log prefix "Rejecting input " level warn reject } # Chaîne qui sert à faire le forwarding chain forward { type filter hook forward priority 0; policy accept; # Règles d'acceptation du forward ## ça vient du réseau ethernet et ça veut sortir sur le wifi iifname "eno1" oifname "wlp6s0" accept ## ça vient du réseau Wifi et ça veut rentrer sur ethernet ## ON accepte ce qui est en relation ou établi et ce qui vient ## du LAN Wifi. iifname "wlp6s0" oifname "eno1" ct state established accept iifname "wlp6s0" oifname "eno1" ct state related accept iifname "wlp6s0" oifname "eno1" ip saddr 192.168.0.0/24 accept ## Sinon, on jette iifname "wlp6s0" oifname "eno1" drop counter log prefix "rejecting forward shit " level warn } # Chaîne de sortie (non filtrée) chain output { type filter hook output priority 0; policy accept; } } # Gestion du NAT via nftables table ip nat { # Globalement, on accepte tout chain prerouting { type nat hook prerouting priority 0; policy accept; } chain input { type nat hook input priority 0; policy accept; } chain output { type nat hook output priority 0; policy accept; } # Mais au moment du postrouting, on active le masquerade # sur l'interface Wi-fi de la station de travail chain postrouting { type nat hook postrouting priority 0; policy accept; oifname "wlp6s0" masquerade # Et on compte les paquets pour voir ce qui passe. counter log prefix "nat postrouting " level warn } }
Configuration du client à sauvegarder dans le cloud
Enfin, pour le client final, il reste à configurer certains points:
- borgmatic.
- la clef SSH vers le dépôt Borg.
Mais tout est déjà décrit dans la documentation générale.
Conclusions
Voilà, grâce à ce dispositif, je peux utiliser borgbackup sur un client dans le "cloud" qui peut écrire directement sur mon serveur de sauvegarde, situé derrière 2 réseaux IP nattés. Les performances sont bonnes et grâce à la déduplication et au fait que le client conserve les blocs de fichiers en cache, je suis passé d'une sauvegarde de près d'une heure via SSHFS à quelques secondes via Wireguard. C'est vraiment impressionnant !
En conclusion, Wireguard c'est bien, mangez-en…