NFS et iptables [RÉSOLU]

Support Debian
#1

Bonsoir,

Pour mon premier post sur ce forum, je viens vous faire part d’un épineux problème.

Au départ, je ne me servais que de mon pare-feu intégré à mon modem-routeur. Son paramétrage d’usine, et non modifiable, était d’accepter tout ce qui sort du LAN. Je ne rencontrais aucun souci en NFS entre mon serveur (Debian Etch) et mon client (Debian Lenny).

J’ai désormais choisi de me passer de la fonction pare-feu de mon modem-routeur, c’est désormais le serveur qui fait firewall, via iptables. J’ai suivi les instructions de http://smhteam.info/wiki/index.linux.php5?wiki=NFS en ce qui concerne l’assignation de ports statiques.

Je boote la Lenny, je me loggue avec mon utilisateur LDAP et mon home directory est bien monté par autofs. Je lance X, XFCE démarre et j’ouvre mon dossier Home. L’affichage du contenu du répertoire est “bloqué”. J’ouvre une console, ls sur mon home directory, je vois bien tous mes fichiers. Je lance Iceweasel, rien ne se passe.

Sur une autre machine, j’installe une Etch et je la configure comme mon client. Là l’ouverture de mon Home se fait, j’essaye Iceweasel, il est exécuté mais impossible d’afficher la moindre page web.
Puis j’ai recompilé un kernel avec la config de l’Etch, sur la Lenny et avec ce kernel j’ai les mêmes problèmes qu’avec la Etch, à savoir que j’accède à mon home directory avec l’explorateur de fichiers mais pas de page Web.

Je suis persuadé que ces soucis sont liés au firewall. Par défaut, il est bloquant, et je ne rencontre pas de soucis sur l’ensemble de mes autres règles. Question interfaces, il y a le modem (ppp0), et deux autres NIC, une pour le réseau des serveurs (eth1 / 192.168.0.1) et l’autre pour les machines clientes (eth2 / 192.168.1.1)

Voyez-vous une solution à mon problème? Des règles à me proposer?

Merci d’avance :blush:

Laurent

#2

que donne

iptables-save

:question:

#3

Je vois toutes mes règles, tout est en COMMIT et “Completed”

#4

je ne connais pas bien ce système mais tu n’as pas de règles qui ‘DROP’ le port web ?

#5

Non. J’ai un Dual boot avec Windows et que ce soit le Web, FTP, SMB ou n’importe quoi d’autre, tout marche. Le souci est uniquement lié à mes règles NFS.

#6

A priori mon problème n’est pas si inconnu que ça, même si je préférais accuser netfilter:

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/181996

J’ai effectivement des “lockd: server XXXX not responding, still trying” et les applications citées refusent également de fonctionner, mais c’est immédiat, pas dans les 24h comme indiqué sur le ticket.

Personne n’a eu de soucis en 2.6.18-6 sur vos Etch en ce qui concerne NFS?

#7

slt

Peux tu tester avec vuurmuur (firewall ncurses GUI).
Très sympa à utilisé.

@+++

#8

Je ne connaissais pas ce projet, ça m’a l’air d’être un très bon soft! Merci pour le tuyau, j’essaierai ce soir. Si entre temps certains ont des idées, qu’ils se manifestent :slightly_smiling:

#9

La meilleure façon de vérifier ce que ton FW rejette est de mettre une règle LOG en filet, derrière toutes tes autres règles. Les paquets qui arrivent jusque là et n’auront pas été acceptés (dans l’hypothèse où ta règle par défaut est un DROP, bien sûr) - seront journalisés dans syslog (par défaut). Un exemple de règle de log:

Sur ton serveur, en console, tu ouvres le fichier syslog en “live” avec:

Sur un client, tu ouvres ton navigateur ou toute autre application qui cause problème et tu observes ce qui se passe dans la console tail -f du serveur NFS.

Selon ta configuration de NFS sur le serveur, tes règles devraient autoriser quelque-chose comme:

sudo iptables -A INPUT -s ${MON_LAN} -p tcp --dport 111 -j ACCEPT sudo iptables -A INPUT -s ${MON_LAN} -p udp --dport 111 -j ACCEPT sudo iptables -A INPUT -s ${MON_LAN} -p tcp --dport 2049 -j ACCEPT sudo iptables -A INPUT -s ${MON_LAN} -p udp --dport 2049 -j ACCEPT sudo iptables -A INPUT -s ${MON_LAN} -p tcp --dport 32765:32768 -j ACCEPT sudo iptables -A INPUT -s ${MON_LAN} -p udp --dport 32765:32768 -j ACCEPT

Pour voir quels ports ta config de NFS utilise, un rpcinfo -p devrait te renseigner.

#10

Salut,

Les règles que tu as indiqué sont celles que j’utilise actuellement, donc déjà c’est rassurant. Sauf en ce qui concerne le log de tout ce qui passe en DROP (je me suis penché sur iptables que récemment, donc pas eu le temps de tout mettre)

J’ai vérifié via rpcinfo, les ports indiqués sont les bons.

Je vais rajouter cette règle et vérifier le contenu du log + check avec Vuurmuur.

Merci pour tes conseils.

#11

vuurmuur, mur de feux en néerlandais. Ça doit venir de chez nous ça non? Ou de chez nos voisins Néerlandais. Tu es sûr que tu ne veux pas essayer de te débrouiller sans ça? Le plus difficile dans un firewall, c’est d’établir ton cahier des charges. Ce que tu veux bloquer ou autoriser. Pour le reste, les commandes iptables classiques et un ou deux petit scripts d’analyse de log suffisent largement à mon avis.

#12

Si ça aide davantage à savoir ce qui bloque, pourquoi ne pas l’utiliser :wink:

Ce serait surtout pour monitorer. Je regarderai en priorité les logs.

#13

Problème réglé par le simple passage côté serveur d’une 2.6.18-6 à une 2.6.25-2 via etch-backports. C’était donc bien un problème kernel, et le même qui a été rapporté par des Ubuntu-users sur le lien que j’ai fourni plus haut.

Contrairement à ce que je pensais au préalable, iptables n’a rien à voir là dedans, le tail de syslog me l’a confirmé. Seul changement à effectuer: l’activation de l’ip_forward par sysctl.conf ne fonctionne plus. Il faut désormais passer par le classique echo > 1 /proc/sys/net/ipv4/ip_forward

Merci à tous :slightly_smiling:

#14

Curieux ton problème, NFS tourne sans problème sur mon kernel vanille 2.6.18-5

#15

C’est effectivement étrange mais ça fonctionne ainsi. Auparavant, j’avais une 2.6.18-6 qui marchait avant ma réinstall. Pourtant avec un client en 2.6.25-2 (Lenny), le seul changement que j’ai eu à opérer pour que NFS refonctionne correctement était côté serveur, par ce changement de kernel.