Forum

Bonjour à tous,

j'ai eu besoin de rendre public un répertoire ; j'ai donc essayé NFS. Et après moultes tentatives, je me suis aperçu que si j'arrête le parefeu ( via drakfirewall) sur le serveur NFS, alors ça se mettait à fonctionner ( et mon autre PC client voir correctement le dossier partagé

Par contre, si démarre le parefeu en cochant "serveur NFS" (ce qui me paraît plutôt logique),




et bien ça ne fonctionne plus

Dans le journal du server NFS, je vois en boucle les lignes suivantes lorsque je fais un " showmount -e 192.168.1.78" depuis le client ( ici 192.168.1.54 ) ?

juin 27 15:48:33 localhost mandi[5987]: skipping known address: 192.168.1.54
juin 27 15:48:33 localhost kernel: Shorewall:net-fw:"DROP:IN=wlp1s0 OUT= MAC=e0:b9:a5:17:7e:48:c0:3f:d5:6d:0f:b3:08:00 SRC=192.168.1.54 DST=192.168.1.78 LEN=104 TOS=0x00 PREC=0x00 TTL=64 ID=60474 DF PROTO=UDP SPT=828 DPT=47391 LEN=84


Quand même bizarre, non ?
J'ai dû oublier quelque chose, mais là je ne vois pas
Faut faire quoi pour avoir le parefeu actif et le serveur NFS joignable ? :

Salut,

Il faut ouvrir en TCP et UDP le port 2049.
Mais il semble qu'il faille aussi ouvrir en TCP + UDP le 111 (à vérifier)

Salut !

là je suis sur le serveur, et j'ai trifouillé dans le répertoire de shorewall.

Et j'ai déjà ceci :[root@localhost shorewall]# pwd
/etc/shorewall[root@localhost shorewall]# cat rules | egrep -v '^#'
INCLUDE rules.drakx
[root@localhost shorewall]# cat rules.drakx
ACCEPT net fw udp 111,2049,4002,4001,4003,4004 -
ACCEPT net fw tcp 111,2049,4002,4001,4003,4004 -


Donc avoir coché la case "serveur NFS" semble bien avoir édité le fichier rules.drakx avec les ports que tu mentionnes.Ce fichier étant INCLUS dans le rules ...

Et si je fais un nmap depuis le client, je vois bien les 2 ports ouverts sur le serveur... mais les mêmes traces dans le journal

J'y connais rien avec le parefeu. Y'aurait pas aussi des options pour stopper carrément des adresses IP ? Ca se trouverait où ?
Car c'est quoi cette trace juin 27 15:48:33 localhost mandi[5987]: skipping known address: 192.168.1.54

En configurant le parefeu via drakfirewall, on remarque que les fichiers suivants ont été modifiés dans /etc/shorewall :


-rw------- 1 root root 329 juin 27 16:14 start
-rw------- 1 root root 300 juin 27 16:14 stop
-rw------- 1 root root 349 juin 27 16:15 zones
-rw------- 1 root root 442 juin 27 16:15 interfaces
-rw------- 1 root root 384 juin 27 16:15 policy
-rw------- 1 root root 98 juin 27 16:15 rules.drakx
-rw------- 1 root root 0 juin 27 16:15 masq


Je vais voir s'il n'y a pas qc là-dedans ...

... y'a bien des zones et policy, mais à la lecture, je n'y comprends rien

Les paquets depuis le client sont DROP ... Est-ce que c'est parce que je suis sur le wifi ( wlp1s0 )?

juin 27 16:50:43 localhost kernel: Shorewall:net-fw:DROP:IN=wlp1s0 OUT= MAC=e0:b9:a5:17:7e:48:c0:3f:d5:6d:0f:b3:08:00 SRC=192.168.1.54 DST=192.168.1.78 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63509 DF PROTO=TCP SPT=48394 DPT=21 WINDOW=29200 RES=0x00 SYN URGP=0


J'ai pourtant bien coché les 2 interfaces ...






J'abdique ...à vous ... ...

Édité par choucroot Le 27/06/2016 à 17h37

Bonjour,
C'est le bug 14550. Il sera résolu dans Mageia 6.
Tu trouveras ici une solution provisoire et si tu préfères, le patch qui sera dans Mageia 6.
https://bugs.mageia.org/show_bug.cgi?id=14550

Merci !!

J'en étais arrivé au point d'utiliser tcpdump ( ça faisait longtemps !!! ). Après l'échange sur le port 111, j'ai vu que le showmount essayait une requête sur le port 41270 .. ET donc fatalement ça ne pouvait pas fonctionner ... car arrêté par le parefeu.

18:41:07.184231 IP 192.168.1.54.971 > 192.168.1.78.111: UDP, length 56
18:41:07.187897 IP 192.168.1.78.111 > 192.168.1.54.971: UDP, length 28
18:41:07.188160 IP 192.168.1.54.971 > 192.168.1.78.41270: Flags [S], seq 1305731735, win 29200, options [mss 1460,sackOK,TS val 1095064 ecr 0,nop,wscale 7], length 0


Grace à la fiche de bug, après la correction dans le fichier etc/sysconfig/nfs ( RPCMOUNTDARGS="--port 4003 ), c'est bien le port 4003 qui est utilisé

19:04:18.697495 IP 192.168.1.54.744 > 192.168.1.78.111: UDP, length 56
19:04:18.703769 IP 192.168.1.78.111 > 192.168.1.54.744: UDP, length 28
19:04:18.704177 IP 192.168.1.54.744 > 192.168.1.78.4003: Flags [S], seq 4231776779, win 29200, options [mss 1460,sackOK,TS val 1234215 ecr 0,nop,wscale 7], length 0


Bref, le parefeu fonctionne bien ... après:
- les logs ne disent pas quel port est rejeté (où alors est-ce une option à activer ? ) ...
- et je n'ai pas eu l'idée d'aller voir s'il y avait un bug, car j'imaginais que c'était une fonctionnalité éprouvée (car utilisée par beaucoup de monde ... ).

Dommage qu'un fix n'ait pas été déployé sur Mageia5 ...

Encore merci.

choucroot:
Cà doit être encore jouable

Il est dispo dans le lien que j'ai donné

Euh ... juste une parenthèse pour celui qui lirait ce fil ... contrairement à ce que je disais plus haut ( ), les ports sources et destinations sont bien affichés dans les logs de shorewall. C'est SPT pour "Source port" et DPT pour "Destination port" ( vu ici http://www.shorewall.net/shorewall_logging.html qui renvoit ensuite ici http://logi.cc/en/2010/07/netfilter-log-format/ ) ...
Comme quoi, j'aurais pu me rendre compte bien plus tôt du problème ... Et oui, sans maîtrise, la puissance n'est rien ... c'est vrai aussi pour Linux

Papoteur:
Une version 2.24.2 est disponible dans Core/Update-testing. Le bugzilla attend vos rapports d'essais.

Bonjour Papoteur,

j'ai bien coché Core Updates Testing (distib5) dans la liste des médias, mais lorsqu'ensuite je recherche drakx-net dans le gestionnaire de logiciel, il ne me renvoie que la version 2.22 ( celle déjà installée ) ... pourtant, dans le journal au moment de la recherche, je vois bien qu'il y a examen de /var/lib/urpmi/Core Upadtes Testing (distrib5)/synthesis.hdlist.cz

J'ai loupé quelque chose ?

choucroot:
Oui.
Depuis le gestionnaire de logiciels, Fichier -> Mise à jour des médias, Cocher Core-Updates Testing

Ben c'est ce que je viens d'écrire ... j'ai coché( et ça va bien vérifié dans Core-Updates d'après le journal), mais il ne trouve pas de version 2.24.2 !

Je ne cherche pas à être désagréable, mais non, tu n'indiques pas avoir fait le MISE A JOUR du média. Tu indiques simplement avoir activé le dépôt. Relis mon message précédent.

Excuse moi, c'est parce que je ne comprenais pas pourquoi on cochait un media et qu'après il fallait le "mettre à jour" dans un autre menu ; habitude que les "Updates" (Core, Nonfree et Tainted) se mettent tout seul à jour quand on les sélectionne. Bref, pas tout compris mais revenons à nos moutons ;

Me voici donc avec les bons logiciels installés:
rpm -qa | grep drakx-net
libdrakx-net-2.24.2-1.mga5
drakx-net-applet-2.24.2-1.mga5
drakx-net-2.24.2-1.mga5
drakx-net-text-2.24.2-1.mga5

Il y a bien un draknfs du 27 juin.
[root@localhost toto]# ll /usr/bin/draknfs
-rwxr-xr-x 1 root root 134 juin 27 11:43 /usr/bin/draknfs*

Pb : Comment faire pour tester le fix sachant que j'ai déjà un serveur installé (la première fois que j'ai lancé ). Car si je recrée une configuration de partage et fais "OK", et que je rédémarre le serveur (via les boutons proposés).



Et bien : ça ne fonctionne toujours pas ( le fichier /etc/sysconfig/nfs n'est pas modifié ! )

[root@localhost toto]# ll /etc/sysconfig/nfs*
-rw-r--r-- 1 root root 1026 janv. 12 2015 /etc/sysconfig/nfs
-rw-rw-r-- 1 root root 0 juil. 5 12:08 /etc/sysconfig/nfs-common
-rw-rw-r-- 1 root root 0 juil. 5 12:08 /etc/sysconfig/nfs-server
[root@localhost toto]#


Qu'en dis-tu ?