Installing WireGuard on openmediavault 6.0.24 (August 2022)Comme indiqué dans la version originale de ce billet en février 2022, le sujet abordé n'est pas d'intérêt général. Il est question de l'accès à des fichiers partagés sur un système distant via un réseau privé virtuel WireGuard lorsque le protocole de partage des fichiers est NFS (Network File System - système de fichier réseau). Alors que ce dernier a été « développé pour permettre le partage de fichiers entre des systèmes résidant sur un réseau local » (source), j'espérais qu'il serait aussi simple de monter le répertoire partagé situé sur le système distant que de monter un répertoire partagé d'un serveur de stockage local (NAS ou Network Attached Storage). L'existence de cette note démontre que ce ne fut pas tout à fait aussi simple qu'escompté.
Le serveur de stockage local est un petit système exécutant OpenMediaVault version 6.0.38-1 (Shaitan). Il y a très peu de changements à ce système par rapport aux valeurs par défaut proposées lors de l'installation d'OMV. Le site distant, exécutant OpenMediaVault version 6.0.39-1 (Shaitan), est presque une réplique parfaite du NAS local, à l'exception des différents sous-réseaux IP. Voici un aperçu des parties pertinentes des réseaux.
L'accès aux dossiers partagés du NAS vault depuis l'ordinateur de bureau hp, où les deux appareils sont situés sur le réseau local domestique, se fait avec NFS. Je voulais monter de façon semblable un répertoire partagé situé sur le NAS romv en tirant avantage d'un réseau privé virtuel (RPV) qu'il est possible de créer entre ces appareils avec WireGuard. Pour commencer, le RPV est activé à partir du bureau local, puis un point de montage dans le système de fichier de l'ordinateur de bureau hp pour le répertoire distant est créé.
À ce stade, je peux envoyer un ping au NAS distant, me connecter à l'interface Web OMV (sur http://romv.local) et ouvrir des sessions SSH sur romv exactement de la même manière qu'avec vault le NAS local.
avahi s'exécute sur le système distant, ses requêtes multicast n'atteignent pas le réseau local. J'examinerai peut-être cela plus tard, mais ce n'est pas un vrai problème pour le moment étant donné que des adresses IP fixes sont données au NAS. Alors un simple ajout dans le fichier hosts de l'ordinateur de bureau « active le nom romv.local.
Grâce au tunnel WireGuard, il semble n'y avoir aucune différence entre le NAS vault et le NAS romv sur le système distant. Par conséquent, j'ai pensé qu'il devrait être possible de monter le répertoire partagé /export/_michel sur romv exactement de la même manière que le répertoire partagé export/nas_michel sur vault est monté sur l'ordinateur de bureau. Cela n'a pas fonctionné.
Cela m'a bloqué et malheureusement, j'ai mal interprété ce que la commande showmount disait.
Avec le recul, je réalise que la commande montrait que la machine distante, romv à 192.168.168.33, exportait le partage NFS, mais uniquement vers les clients du sous-réseau 192.168.168.0/24. Le RPV WireGuard permet à l'ordinateur de bureau HP d'accéder à ce sous-réseau, mais il n'attribue pas d'adresse à cet ordinateur dans ce sous-réseau distant. En regardant la connexion SSH, il est évident qu'en ce qui concerne romv, l'adresse IP de hp est 192.168.98.4qui est l'adresse de la machine sur le réseau virtuel WireGuard. En regardant la sortie des commandes de montage avec le paramètre -v activé, il est, encore une fois, évident que la demande de montage du répertoire partagé provient de 192.168.98.4 qui est une adresse bloquée. Comme je l'ai dit dans la note d'origine, c'était dommage que je n'aie pas pensé à utiliser ce paramètre. Si j'avais élaboré la figure des réseaux affichée ci-dessus avant d'écrire le présent billet, j'aurais peut-être évité le problème.
La solution rapide consiste à modifier l'adresse IP client des répertoires partagés NFS. Cela se fait généralement en modifiant le fichier de configuration /etc/exports. Or ce fichier ne doit pas être modifié à la main dans OpenMediaVault.
Au lieu de cela, la modification doit être effectuée avec l'interface Web OMV, comme indiqué dans la figure ci-dessous.
L'adresse IP du client était 192.168.168.0/24 par défaut sur cette installation d'OMV. J'ai dû cliquer sur le dossier partagé _michel, puis cliquer sur l'icône du crayon pour modifier l'entrée vers 192.168.98.0/24 comme indiqué sur la figure. Ce basculement de l'adresse client vers le sous-réseau virtuel WireGuard fait en sorte que les demandes de montage provenant de l'ordinateur de bureau à 192.168.98.4 seront acceptées. N'oubliez pas d' le changement d'adresse, puis d'appliquer les changements de configuration pour qu'ils prennent effet. En même temps, les options de montage peuvent être modifiées si désiré. Je n'ai pas modifié les options définies par défaut (insecure, rw, subtree_check). Pour savoir quelles sont ces options et quelles sont les autres options, reportez-vous à la page de manuel exports(5).
*.exports ajouté au répertoire /etc/exports.d en suivant mes instructions dans l'ancienne version de ce billet. Si cette suppression est faite après l'application des modifications dans l'interface Web OMV, la table des exportations doit être mise à jour.
Les répertoires exportés peuvent être visualisés à partir du système client. Clairement seuls les ordinateurs sur le sous réseau 192.168.98.0/24 peuvent monter les répertoires partagés.
Il est maintenant facile de monter le répertoire distant dans le système de fichiers de hp.
Alors que le point de montage romv_nas appartient entièrement à root, le répertoire partagé romv_nas/_michel est accessible à tout membre du groupe users auquel appartiennent déjà la plupart des utilisateurs de l'ordinateur de bureau. Par conséquent, il est possible de créer, lire, modifier et supprimer des fichiers du répertoire à distance tout comme sur un répertoire local.
Il est avantageux de monter le système de fichiers distant dans /media/michel, car il apparaîtra automatiquement parmi les Appareils connectés dans l'explorateur de fichiers. Du moins, c'est ce qui se passe dans Caja sur mon bureau exécutant Linux Mint Mate.
Dans mon cas, monter le pseudosystème de fichiers NFS V4 n'est pas particulièrement utile, car il contient un seul répertoire. Il est plus simple de monter ce dernier directement comme cela se faisait dans les anciennes versions de NFS. Cela sera fait ci-dessous après avoir démonté le système de fichiers virtuel.
Quelle que soit la façon dont le répertoire distant est monté, un avertissement est de rigueur. Il est important de démonter tous les répertoires NFS partagés avant de fermer le tunnel WireGuard. Si le RPV est fermé alors qu'un dossier à distance est partagé, certaines fonctions telles que ls et df seront bloqué, car le système tentera de se connecter au dossier partagé désormais inaccessible pendant très longtemps.
Que faire si quelqu'un a un ordinateur sur le réseau distant et veut accéder au NAS à 192.168.168.33? Avec le changement de l'adresse IP du client dans OMV sur 192.168.98.0/24, un client sur 192.168.168.0/24 n'aurait pas accès. En d'autres termes, y a-t-il une bonne façon de faire ce que je voulais faire dans la version originale de ce billet ? En court, oui. Pour voir comment procéder, commençons en retournant à la configuration initiale en revenant à l'adresse IP client par défaut dans l'interface Web OpenMediaVault sur romv.
L'adresse IP du client par défaut était 192.168.168.0/24 sur mon installation d'OMV. Encore une fois, n'oubliez pas d'appliquer les modifications pour qu'elles prennent effet. Vérifions que nous sommes revenus à la situation initiale.
Les appareils du sous-réseau 192.168.98.0/24 doivent maintenant être ajoutées à la liste des clients autorisés à monter le système de fichiers partagés. Comme indiqué précédemment, le fichier /etc/exports sur romv ne peut pas être modifié, car il est géré par OpenMediaVault. Au lieu de cela, une table d'exportation supplémentaire appelée tunnel.exports ou tout autre élément se terminant par .exports est créée dans le répertoire /etc/exports.d. N'importe quel éditeur de texte peut être utilisé pour ajouter le contenu suivant.
Depuis root est le propriétaire et le groupe du répertoire /etc/exports.d, sudo sera nécessaire.
N'oubliez pas de mettre à jour les exportations.
Nous pouvons maintenant vérifier que le répertoire partagé est disponible pour tous les clients sur deux sous-réseaux, 192.168.168.0/24 et 192.168.98.0/24.
Assurez-vous que tout système de fichiers déjà monté sur /media/michel de l'ordinateur de bureau est démonté avant de monter le système de fichiers virtuel NFS V4. L'astuce ici consiste à monter le système de fichiers en utilisant l'adresse IP de l'ordinateur de bureau sur le réseau privé WireGuard.
Bien sûr, il est également possible de monter le répertoire partagé directement au lieu du système de fichiers virtuel NFS V4.
Notez qu'il n'est pas nécessaire de restreindre le type de système de fichiers avec le paramètre -t nfs. Par défaut, la version 4 de NFS sera utilisée tant que le système distant et le poste de travail exécutent des versions relativement récentes de Linux. Dans ma situation, le système distant exécute OpenMediaVault sur un noyau Linux 5.16.0 et l'ordinateur de bureau est un système Linux Mint Mate avec noyau plus vieux, Linux 5.4.0.
Toutes mes excuses pour les conseils, disons, moins que parfaits dans la première version de ce billet. Comme on vient de voir, il est facile d'accéder aux dossiers partagés avec NFS via un tunnel WireGuard tant que l'on tient compte du sous-réseau IP sur lequel se trouve l'interface WireGuard vers le site distant.
L'avertissement usuel s'impose ici : je ne prétends pas être un expert dans le domaine, loin de là. Alors toute correction ou suggestion est bienvenue. On peut envoyer un courriel en cliquant sur l'adresse au bas de la page.