Mise en « production »

Puisque nous avons résolu à peu près tous les problèmes, nous pouvons envisager de fixer tout ceci pour que le fonctionnement perdure après redémarrage de la machine. Nous sommes toujours ici dans la configuration simplifiée :

Nous devons nous assurer que les règles Iptables seront restaurées. Une solution pas vilaine consiste à sauvegarder les règles en place :

mkdir /etc/iptables
iptables-save > /etc/iptables/rules

Et de les recharger lorsque l'interface eth0 est activée. Nous devons aussi charger le module nf-conntrack-ftp. Tout ceci peut être fait avec un script placé dans /etc/network/if-up.d/ (Sur Debian et dérivées) :

# cat /etc/network/if-up.d/netfilter 
#! /bin/sh
if [ "$IFACE" = eth0 ]; then
	/sbin/modprobe nf-conntrack-ftp
	/sbin/iptables-restore < /etc/iptables/rules
fi

Ne pas oublier de rendre ce script exécutable et éventuellement l'améliorer pour par exemple s'assurer que tout s'est bien passé.

Il nous faut ajouter dans le fichier /etc/inetd.conf la ligne suivante :

ftp  stream tcp nowait root /usr/sbin/pure-ftpd -j -lpuredb:/etc/pure-ftpd/pureftpd.pdb -E -T:30 -c3 -C2 -Y1 -p 65525:65535

Puis demander à inetd de recharger sa configuration.

Tout devrait fonctionner, du moins en IPv4.

Pure-ftpd sait le faire, c'est clairement indiqué dans sa documentation et nous aurions pu le tester lorsqu'il était démarré « à la main » dans un shell.

Ici cependant, ça ne fonctionnera pas, non pas à cause du Pure-ftpd mais du service inetd qui par défaut ne fonctionne qu'en IPv4. Cependant, la version fournie avec squeeze supporte IPv6 si on le lui demande poliment.

La méthode polie étant d'ajouter cette ligne dans inetd.conf :

ftp  stream tcp6 nowait root /usr/sbin/pure-ftpd -j -lpuredb:/etc/pure-ftpd/pureftpd.pdb -E -T:30 -c3 -C2 -Y1 -p 65525:65535

Jusqu'ici, nous avons travaillé sur des nœuds situés sur des réseaux privés, routés entre eux. Une sorte de gros réseau local donc. Mais si les nœuds doivent se joindre par l'internet, il y aura de nouveaux problèmes à régler.

Probablement que dans tous les cas, les clients seront placés derrière un routeur NAT muni d'un pare-feu…

Si le serveur est placé sur la passerelle elle-même, il n'y aura pas de problèmes supplémentaires du côté du serveur, il faudra juste adapter les règles IPtables de la passerelle comme nous l'avons vu plus haut.

Si le serveur est placé derrière le routeur NAT, deux cas de figure seront alors possibles :

La passerelle se comporte en routeur NAT en IPv4 et en simple pont en IPv6. Dans ce cas, l'hôte du serveur FTP peut disposer d'une adresse IPv6 publique et il n'y a toujours pas de problèmes.

Notons que nous avons étudié le filtrage en IPv4 seulement. Il serait décent d'en faire autant en IPv6 dans un tel cas.

Malheureusement, IPv6 est loin d'être déployé chez tous les fournisseurs d'accès (à l'heure où ces lignes sont écrites), ce qui rend la solution moins intéressante.

Il va falloir faire de la redirection de port (DNAT) sur la passerelle. Pas de problèmes pour le canal de contrôle (port 21), mais c'est une autre affaire pour les canaux de DATA. La page suivante va détailler ce cas de figure.