2022-02-23
md
Partage d'un répertoire avec NFS utilisant un tunnel WireGuard
<-Installing WireGuard on OpenMediaVault 5.6.1 (March 2021)

Peu de personnes seront concernées par ce sujet. Manifestement, je ne l'étais pas, car depuis plus d'un an, j'ai ignoré mon incapacité à monter un dossier NFS partagé d'un système OpenMediaVault distant accessible via un réseau privé virtuelWireGuard. Il a toujours été possible d'ouvrir des sessions SSH avec le système distant via WireGuard, ce qui était suffisant pour mes besoins. Hier, en proie de désire impérieux de mettre de l'ordre, j'ai poussé des soumissions (commits) vers quelques référentiels de sauvegarde Mercurial sur le système distant et je me suis demandé pourquoi cela se faisait via SSH (ce qui nécessite le logiciel hg sur la machine distante) et non directement avec l'instance hg de mon bureau de bureau.

Voici les principaux acteurs et leurs attributs pertinents lorsque le tunnel WireGuard est en place.

Des points supplémentaires pour quiconque trouve la source des noms d'utilisateur et d'hôte. Et si vous vous posez la question, l' interface WireGuard est nommée romv sur l'ordinateur de bureau et wg0 sur la machine distante.

Voici le problème que je rencontrais jusqu'à hier après avoir créé le tunnel entre les deux ordinateurs.

michel@hp:~$ sudo wg-quick up romv [#] ip link add romv type wireguard [#] wg setconf romv /dev/fd/63 [#] ip -4 address add 192.168.98.4/24 dev romv [#] ip link set mtu 1420 up dev bomv [#] ip -4 route add 192.168.168.0/24 dev romv michel@hp:~$ sudo mount -t nfs 192.168.168.33:/export/_michel /media/michel/romv_michel mount.nfs: access denied by server while mounting 192.168.168.33:/_michel

Cela était déroutant, car la command showmount semblait prouver que le système distant et le répertoire partagé /export/_michel étaient accessibles via le réseau privé virtual.

michel@hp:~$ showmount -e 192.168.168.33 Export list for 192.168.168.33: /export 192.168.168.0/24 /export/_michel 192.168.98.0/24,192.168.168.0/24

En regardant les notes prises il y a un an, il est évident que j'ai abandonné assez rapidement. Hier, j'ai eu la brillante idée de regarder le journal sur le système distant après avoir de nouveau échoué à monter le partage.

michel@romv:~$ journalctl -e -- Logs begin at Sun 2021-02-13 02:43:19 AST, end at Tue 2021-02-22 15:51:38 AST. -- ... Feb 22 15:48:11 romv rpc.mountd[511]: refused mount request from 192.168.98.4 for /export/_michel (/export/_michel): unmatched host ...

J'ai été surpris de voir que la demande de montage provenait du bureau du réseau "virtuel" WireGuard 192.168.98.4. Rétrospectivement, il aurait été très utile d'activé la sortie détaillée avec l'option -clors du montage du répertoire distant.

michel@hp:~$ sudo mount -v -t nfs 192.168.168.33:/export/_michel /media/michel/romv_michel mount.nfs: timeout set for Tue Feb 22 16:08:19 2022 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.168.33,clientaddr=192.168.98.4' mount.nfs: mount(2): Permission denied mount.nfs: access denied by server while mounting 192.168.168.33:/export/_michel

J'aurais peut-être vu l'incompatibilité du réseau, mais je supposais que le tunnel était totalement transparent et que le montage du répertoire partagé romv sur le bureau se ferait aussi simplement que le montage d'un répertoire partagé situé sur un système OpenMediaVault du réseau domestique. Ceci étant dit, l'indication "hôte sans correspondance" dans le journal a facilité la recherche d'un conseil clé : How to fix "mountd: refused mount request: unmatched host" par GOLINUXHUB. Donc, comme d'habitude, je présente une solution trouvée par quelqu'un d'autre. Commençons par examiner les exportations sur le système distant.

michel@romv:~$ sudo exportfs -v /export/_michel 192.168.168.0/24(rw,wdelay,insecure,root_squash,fsid=1,sec=sys,rw,insecure,root_squash,no_all_squash) /export 192.168.168.0/24(ro,wdelay,root_squash,no_subtree_check,fsid=0,sec=sys,ro,secure,root_squash,no_all_squash)

OpenMediaVault avait donc prévu de partager le répertoire /export/_michel sur le sous-réseau 192.168.168.0/24 et la requête provenait d'un sous-réseau différent : 192.168.98.0/24. Modifier le fichier /etc/exports comme suggéré par GOLINUXHUB ne semblait pas être une bonne idée, car ce fichier commence avec un avertissement inquiétant.

# This file is auto-generated by openmediavault (https://www.openmediavault.org) # WARNING: Do not edit this file, your changes will get lost.

Heureusement, selon le manuel (man exportfs) des fichiers de configuration supplémentaires peuvent être créés dans un sous-répertoire.

FILES /etc/exports input file listing exports, export options, and access control lists /etc/exports.d directory where extra input files are stored. Note: only files that end with .exports are used.

Essayons cette option en espérant qu'OpenMediaVault n'endommagera pas le fichier de configuration supplémentaire.

michel@romv:~$ sudo mkdir /etc/exports.d michel@romv:~$ echo "/export/_michel 192.168.98.0/24(rw,subtree_check,insecure)" | sudo tee /etc/exports.d/tunnel.exports /export/_michel 192.168.98.0/24(rw,subtree_check,insecure)

Réexportons tous les répertoires et vérifions le résultat.

Let's reexport all directories and check the modified exports.

michel@romv:~$ sudo exportfs -ra michel@romv:~$ sudo exportfs -v /export/_michel 192.168.10.0/24(rw,wdelay,insecure,root_squash,fsid=1,sec=sys,rw,insecure,root_squash,no_all_squash) /export/_michel 192.168.98.0/24(rw,wdelay,insecure,root_squash,sec=sys,rw,insecure,root_squash,no_all_squash) /export 192.168.10.0/24(ro,wdelay,root_squash,no_subtree_check,fsid=0,sec=sys,ro,secure,root_squash,no_all_squash)

Après un montage à distance NFS, les tests montrent qu'il est possible de créer, de définir des attributs, d'exécuter et de supprimer des fichiers comme sur un disque local.

michel@hp:~$ sudo mount -v -t nfs 192.168.168.33:/export/_michel /media/michel/romv_michel mount.nfs: timeout set for Tue Feb 22 16:11:11 2022 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.168.33,clientaddr=192.168.98.4' mount.nfs: mount(2): No such file or directory mount.nfs: trying text-based options 'addr=192.168.168.33' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying 192.168.168.33 prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying 192.168.168.33 prog 100005 vers 3 prot UDP port 39036 michel@hp:~$ ls -l /media/michel/romv_michel/test ls: cannot access '/media/michel/romv_michel/test': No such file or directory michel@hp:~$ touch /media/michel/romv_michel/test michel@hp:~$ ls -l /media/michel/romv_michel/test -rw-rw-r--+ 1 michel users 0 Feb 22 16:00 /media/michel/romv_michel/test michel@hp:~$ cat > /media/michel/romv_michel/test<< EOF > #!/bin/bash > echo "hello" > EOF michel@hp:~$ chmod +x /media/michel/romv_michel/test michel@hp:~$ /media/michel/romv_michel/test hello michel@hp:~$ rm /media/michel/romv_michel/test michel@hp:~$ ls -l /media/michel/romv_michel/test ls: cannot access '/media/michel/romv_michel/test': No such file or directory

Il y a un avantage à monter le répertoire à distance dans /media, car il sera visible en tant qu'appareil dans le gestionnaire de fichiers (Caja) de l'ordinateur de bureau.

share in Caja

J'envisage de ne monter le répertoire distant partagé qu'occasionnellement, mais j'ai quand même concocté un script bash pour réaliser cette opération.

#!/bin/bash if [ ! -d "/sys/class/net/romv/" ]; then # no romv interface, setup the Wireguard tunnel sudo WireGuard-quick up romv sleep 2 if [ ! -d "/sys/class/net/romv/" ]; then echo "Could not setup WireGuard tunnel" exit 1 fi fi # mount the NFS share on romv #sudo mount -v -t nfs -o nfsvers=3 192.168.168.33:/export/_michel /media/michel/romv_michel sudo mount -t nfs -o nfsvers=3 192.168.168.33:/export/_michel /media/michel/romv_michel if [ $? -eq 0 ]; then echo "Remote directory mounted on /media/michel/romv_michel" else echo "Could not mount the remote directory" exit 2 fi

Si pour une raison quelconque la commande mount ne fonctionne pas, les éléments suivants s'afficheront.

michel@hp:~$ mount_romv mount.nfs: Connection timed out Could not mount remote directory

Il faut tellement de temps pour que l'opération se termine en cas de problème, que je la terminerai probablement avant la fin du délai d'attente.

Ce serait bien de pouvoir trompété ce qui précède est une solution parfaite au problème, mais ce n'est pas le cas. Notez comment le répertoire partagé a été monté avec la version 3 de NFS. Ceci est confirmé avec la commande suivante.

michel@hp:~$ df -t nfs -t nfs4 --output=source,fstype,target Sys. de fichiers Type Monté sur 192.168.10.33:/export/_michel nfs /tmp/romv_michel 192.168.0.17:/_michel nfs4 /mnt/nas-michel

C'est un peu surprenant, car, comme on peut le voir, le répertoire partagé d'un NAS local exécutant également OpenMediaVault a été monté avec la version 4 de NFS. À l'heure actuelle, cela semble être un curieux artefact qui peut s'expliquer par la nature du processeur Athlon monocœur assez ancien utilisé sur la machine distante. Il n'y a aucune preuve que c’est le cas, mais c'est plausible. Notez que l'option -o nfsvers=3 dans la commande mount dans le fichier bash. Il supprime la tentative de montage du partage distant avec nfs4 qui échouera pour gagner un peu de vitesse.

Il y avait un problème majeur lorsque j'ai monté le répertoire distant pour la première fois. Il était impossible de créer ou de modifier des fichiers sur celui-ci. Il y avait des erreurs d'autorisation qui se sont avérées être associées aux différents utilisateurs sur le bureau et le système distant. Plus précisément, le nom d'utilisateur michel était le même sur les deux machines, mais l'ID utilisateur était 1000 sur le bureau et 1001 sur le système distant. Je crois qu'il y a des moyens de contourner cela; j'ai opté pour une solution plus simple, mais brouillonne. Après plusieurs essais et un peu de chance, j'ai réussi à changer l'ID utilisateur de michel sur le système distant en 1000. Cela, en plus de changer le couple propriétaire:groupe du répertoire partagé de 1001:users à michel:users, à fonctionné. Rétrospectivement, je me demande si la dernière démarche à elle seule aurait été suffisante, mais je n'approfondirai pas cette question à ce stade. Dans un an, j'y reviendrai peut-être, mais la machine distante aura peut-être disparu d'ici là.

Au fait, j'ai décidé de continuer à utiliser le protocole SSH pour pousser les modifications vers les référentiels distants. Je considère tout ce que j'ai décrit ci-dessus comme une expérience d'apprentissage.

<-Installing WireGuard on OpenMediaVault 5.6.1 (March 2021)