Forum Linux.général Accès au serveur NFS

Posté par  . Licence CC By‑SA.
Étiquettes :
0
15
oct.
2022

Bonjour,

J'ai installé et configuré un serveur NFS, sous Manjaro, et son client sous Debian.
Je monte le répertoire partagé via fstab grâce aux informations récupérées sur le net :
192.168.1.16:/srv/partagenfs /media/partagenfs/ nfs user,rw,x-systemd.requires=NetworkManager-wait-online.service,noatime,intr 0 0

Après le boot, Dolphin me liste bien le répertoire partagé mais je n'y ai pas accès (time out). Il faut que je désactive iptables sur le serveur pour que je puisse lister le contenu du répertoire partagé. Si je réactive alors iptables côté serveur je n'ai toujours aucun soucis pour lire les fichiers partagés.
J'ai tenté de désactiver les règles iptables qui interdisent du trafic sans résultat.
Voici mon iptables.rules :

# Generated by iptables-save v1.8.8 on Fri Oct 14 16:20:40 2022
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -s 193.252.148.241/32 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 54925 -j ACCEPT
-A INPUT -p udp -m udp --dport 1714:1764 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3050 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -p udp -m udp --dport 5060 -j ACCEPT
-A INPUT -p udp -m udp --dport 7078 -j ACCEPT
-A INPUT -p udp -m udp --dport 9078 -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags FIN,PSH,URG FIN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -m pkttype --pkt-type broadcast -j DROP
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
#-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m tcp --dport 2049 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20049 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -d 193.252.148.241/32 -j DROP
-A OUTPUT -j ACCEPT
-A fail2ban-ssh -j RETURN
COMMIT
# Completed on Fri Oct 14 16:20:40 2022`

J'ai tenté de capturer les trames côté client avec Wireshark sans trop y comprendre quelque chose. J'ai bien identifié une erreur NFS4 mais je ne sais pas à quoi c'est dû.

Si quelqu'un pouvait m'aider SVP !

Sylvain

  • # version de nfs ?

    Posté par  . Évalué à 2.

    Vu que tu utilises le port tcp 2049, j'imagine que tu cherches à utiliser nfs4, mais est-ce vraiment le cas ?

    Selon les versions et les fonctionnalités, il faut parfois ouvrir d'autres ports, pour les appels RPC (le 111 en udp et tcp par exemple, et parfois même des plages de ports). Tu peux forcer la version de NFS avec l'option nfsvers.

    Sinon, au passage, pour quand tu auras réglé ton problème de firewall : j'utilise autofs pour monter les exports NFS à la demande. Ça permet de booter sans timeout même si le serveur NFS est éteint.

    • [^] # Re: version de nfs ?

      Posté par  . Évalué à 1.

      Merci pour ta réponse.

      Oui, j'utilise bien la version 4 de NFS, les captures de paquets Wireshark le prouvent.

      J'ai essayé également d'ouvrir le port 111 sans plus de résultat.

      Excuse mon ignorance, mais que veux tu dire par "booter sans timeout" ? Cela signifie qu'avec autofs tu n'as pas de délais dû à la réponse NFS du serveur ?

      • [^] # Re: version de nfs ?

        Posté par  . Évalué à 2.

        Excuse mon ignorance, mais que veux tu dire par "booter sans timeout" ? Cela signifie qu'avec autofs tu n'as pas de délais dû à la réponse NFS du serveur ?

        Ah pardon, j'ai été un peu vite et ce n'était pas très clair. C'est dans le cas où le serveur NFS est éteint. Le point de montage NFS ne fait alors pas partie de la séquence de démarrage, mais est monté à la demande automatiquement, et démonté lorsqu'il n'est plus accédé.

        C'est très pratique.

  • # idée (pas sûr)

    Posté par  . Évalué à 2.

    C'est peut-être parce que ces règles sont avant celles qui autorisent le port 2049 :

    -A INPUT -p tcp -m tcp --tcp-flags FIN,PSH,URG FIN,PSH,URG -j DROP
    -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
    -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
    -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP

    Mais du coup je me demande pourquoi ssh (port 22) fonctionnerait.

    • [^] # Re: idée (pas sûr)

      Posté par  . Évalué à 1.

      Non, ça ne marche pas : j'ai tenté de décaler la ligne vers le haut sans résultat.
      Merci quand même !

  • # Résolu !

    Posté par  . Évalué à 3.

    Bonjour,

    J'ai consulté les "iptables denied" de dmesg pour m'apercevoir que les ports 111 et 20048 étaient refusés en udp et tcp depuis le client.
    Il s'avère que le port 20048 correspond à "NFS mount protocol", ceci explique cela…

    J'ai donc adapté iptables et ça marche. Dommage que ce soit si peu documenté.

    Il me reste maintenant à autoriser l'accès en écriture aux clients NFS.

    • [^] # Re: Résolu !

      Posté par  . Évalué à 3.

      Chouette !

      J'ai revérifié, et sur mon infrastructure, il n'y a que le port 2049 utilisé en TCP pour NFS. Pourtant j'ai bien un processus rpc.mountd :-/. J'utilise nfs 4.2, sur Debian 11 (client et serveur).

      Wikipedia nous dit ceci, aussi :

      One big advantage of NFSv4 over its predecessors is that only one UDP or TCP port, 2049, is used to run the service, which simplifies using the protocol across firewalls.

      Peut-être que quand tu fais le mount, le client nfs fait un genre de sondage pour déduire quelle version utiliser, et choisis NFS4 à la fin ?

      Si tu montes l'export directement dans la ligne de commande, avec la version, et seulement le port 2049 ouvert, est-ce que ça fonctionne ? Je suis curieux ;) :

      mount -t nfs4 -o nfsvers=4.2 192.168.1.16:/srv/partagenfs /media/partagenfs/
      (ou bien)
      mount -t nfs4 -o nfsvers=4.2 192.168.1.16:/               /media/partagenfs/
      (ou bien)
      mount -t nfs4 -o nfsvers=4 192.168.1.16:/srv/partagenfs  /media/partagenfs/
      
      • [^] # Re: Résolu !

        Posté par  . Évalué à 3.

        J'ai commenté la ligne NFS dans fstab et je n'ai laissé activé sur le serveur que le port 2049 dans iptables. Voici ce que ça donne :

        mount -t nfs4 -o nfsvers=4.2 192.168.1.16:/srv/partagenfs /media/partagenfs/

        mount.nfs4: mounting 192.168.1.16:/srv/partagenfs failed, reason given by server: No such file or directory

        mount -t nfs4 -o nfsvers=4.2 192.168.1.16:/ /media/partagenfs/

        Montage réussi de 192.168.1.16:/srv/partagenfs

        mount -t nfs4 -o nfsvers=4 192.168.1.16:/srv/partagenfs /media/partagenfs/

        mount.nfs4: Connection timed out

        En revanche, en activant ma ligne NFS dans fstab, il faut bien activer les ports 111, 2049 et 20048 chacun en tcp.

        • [^] # Re: Résolu !

          Posté par  . Évalué à 3. Dernière modification le 17 octobre 2022 à 21:58.

          Divagations

          Ah ah ok, j'ai compris (enfin je crois), en me remémorant les migrations de nfs3 vers nfs4.

          Il y a un truc pas du tout intuitif, c'est que quand tu mets ceci dans le /etc/exports :

          /srv/nfsroot        192.168.1.0/255(rw)
          /srv/nfsroot/boring 192.168.1.0/255(rw)
          /srv/nfsroot/fun    192.168.1.0/255(rw)
          

          Pour y accéder en nfs3, tu montes avec : mount serveur:/srv/nfsroot/boring /mnt
          Mais en nfs4 (ou 4.2 ?), il faut faire : mount serveur:/boring /mnt

          (c'est ce qu'on voit dans la commande qui force le nfs 4.2 : mount.nfs4: mounting 192.168.1.16:/srv/partagenfs failed, reason given by server: No such file or directory.)

          Hypothèse foireuse : il doit exister soit un downgrade en nfs3 en cours de route, soit un mode de compatibilité, qui fait que les ports 111 et consorts sont utilisés quand même.

          J'ai vu des infos intéressantes sur le wiki de Archlinux, en particulier au niveau de la mention fsid=0, à laquelle je n'avais jamais trop fait attention.

          Chez toi

          Au final, je pense que si tu changes le premier champ de la fstab comme ceci :

          192.168.1.16:/ /media/partagenfs/ nfs user,rw,x-systemd.requires=NetworkManager-wait-online.service,noatime,intr 0 0
          

          Ça devrait fonctionner avec seulement le port 2049.

          Chez moi

          Par exemple dans un de mes /etc/exports j'ai :

          /vol       192.168.0.0/23(rw,async,fsid=0,crossmnt,no_subtree_check)
          /vol/data  192.168.0.0/23(rw,async,no_subtree_check)
          

          et dans /proc/mount :

          unserveur.interne.example.com:/data /mnt/boring nfs4 
              rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,
              namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,
              clientaddr=192.168.1.42,local_lock=none,addr=192.168.0.12 0 0
          

          et dans la config autofs :

          automountInformation: -fstype=nfs4,async unserveur.interne.example.com:/data
          

          On voit bien que /vol côté serveur devient / côté client, et que je monte le sous-répertoire /data. Ça m'avait surpris lors du passage des serveurs de Debian 8 à Debian 10, il y a quelques années, j'avais totalement oublié.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.