je desespere quand a la configuration de mon serveur vsftpd. je n'arrive pas
a recuperer la liste de mes dossiers bien que j'arrive a me connecter.
mon architecture reseau est la suivante:
- un routeur assure la connexion entre la dmz et l'internet via du nat.
- le serveur a pour ip 192.168.25.10
- sur le serveur un iptables avec comme regles a la fin un logging des
packets non autorisés
- une configuration de vsftpd en mode passif pour des hotes virtuels:
listen=YES
pasv_enable=YES
pasv_promiscuous=YES
pasv_min_port000
pasv_max_port 000
ssl_enable=YES
seulement lorsque je me connectes avec mon client ftp filezilla 2.2.18 en
ftp sur tls, j'obtiens le log suivant:
Commande : PASV
Réponse : 227 Entering Passive Mode (192,168,25,10,59,167)
Commande : LIST
Erreur : Le canal de transfert n'a pas pu être ouvert.
et puis plus rien. rien dans le syslog concernant iptables, rien dans les
logs de mon routeur concernant des paquets rejetés.
que puis je faire ou que me manque t'il dans ma configuration vsftpd ou ssl
pour que je puisse utiliser vsftpd sur ssl?
je desespere quand a la configuration de mon serveur vsftpd. je n'arrive pas
a recuperer la liste de mes dossiers bien que j'arrive a me connecter.
mon architecture reseau est la suivante:
- un routeur assure la connexion entre la dmz et l'internet via du nat.
- le serveur a pour ip 192.168.25.10
- sur le serveur un iptables avec comme regles a la fin un logging des
packets non autorisés
- une configuration de vsftpd en mode passif pour des hotes virtuels:
listen=YES
pasv_enable=YES
pasv_promiscuous=YES
pasv_min_port000
pasv_max_port 000
ssl_enable=YES
seulement lorsque je me connectes avec mon client ftp filezilla 2.2.18 en
ftp sur tls, j'obtiens le log suivant:
Commande : PASV
Réponse : 227 Entering Passive Mode (192,168,25,10,59,167)
Commande : LIST
Erreur : Le canal de transfert n'a pas pu être ouvert.
et puis plus rien. rien dans le syslog concernant iptables, rien dans les
logs de mon routeur concernant des paquets rejetés.
que puis je faire ou que me manque t'il dans ma configuration vsftpd ou ssl
pour que je puisse utiliser vsftpd sur ssl?
je desespere quand a la configuration de mon serveur vsftpd. je n'arrive pas
a recuperer la liste de mes dossiers bien que j'arrive a me connecter.
mon architecture reseau est la suivante:
- un routeur assure la connexion entre la dmz et l'internet via du nat.
- le serveur a pour ip 192.168.25.10
- sur le serveur un iptables avec comme regles a la fin un logging des
packets non autorisés
- une configuration de vsftpd en mode passif pour des hotes virtuels:
listen=YES
pasv_enable=YES
pasv_promiscuous=YES
pasv_min_port000
pasv_max_port 000
ssl_enable=YES
seulement lorsque je me connectes avec mon client ftp filezilla 2.2.18 en
ftp sur tls, j'obtiens le log suivant:
Commande : PASV
Réponse : 227 Entering Passive Mode (192,168,25,10,59,167)
Commande : LIST
Erreur : Le canal de transfert n'a pas pu être ouvert.
et puis plus rien. rien dans le syslog concernant iptables, rien dans les
logs de mon routeur concernant des paquets rejetés.
que puis je faire ou que me manque t'il dans ma configuration vsftpd ou ssl
pour que je puisse utiliser vsftpd sur ssl?
Salut,
Matthieu a écrit :
>
> je desespere quand a la configuration de mon serveur vsftpd. je n'arriv e
pas
> a recuperer la liste de mes dossiers bien que j'arrive a me connecter.
Sans lire la suite je parie déjà qu'il y a du NAT ou du filtrage
là-dessous. Le protocole FTP, à cause de sa complexité, ne fait pas
toujours bon ménage avec ces deux-là.
> mon architecture reseau est la suivante:
> - un routeur assure la connexion entre la dmz et l'internet via du nat.
Du NAT -> gagné ! ;-)
Sous Linux le routeur ?
> - le serveur a pour ip 192.168.25.10
> - sur le serveur un iptables avec comme regles a la fin un logging des
> packets non autorisés
Et comment sont gérées les connexions de données FTP ?
> - une configuration de vsftpd en mode passif pour des hotes virtuels:
>
> listen=YES
> pasv_enable=YES
> pasv_promiscuous=YES
> pasv_min_port000
> pasv_max_port 000
> ssl_enable=YES
[...]
> seulement lorsque je me connectes avec mon client ftp filezilla 2.2.18e n
> ftp sur tls, j'obtiens le log suivant:
[...]
> Commande : PASV
> Réponse : 227 Entering Passive Mode (192,168,25,10,59,167)
> Commande : LIST
> Erreur : Le canal de transfert n'a pas pu être ouvert.
> et puis plus rien. rien dans le syslog concernant iptables, rien dans
les
> logs de mon routeur concernant des paquets rejetés.
Examine la réponse du serveur à la commande PASV : l'adresse transmis e
en vue d'établir la connexion de données est 192.168.25.10, l'adresse
privée du serveur. Il est évidemment impossible pour un client exté rieur
de joindre le serveur à cette adresse qui n'a de sens que sur le rése au
local du serveur. Comme le client cherche à se connecter à cette adre sse
privée non routée sur internet, il est normal que ni le routeur ni le
serveur ne voient rien arriver.
> que puis je faire ou que me manque t'il dans ma configuration vsftpd ou
ssl
> pour que je puisse utiliser vsftpd sur ssl?
Quand le routeur NAT est un Linux 2.4 ou ultérieur, la solution
classique consiste à utiliser les modules de suivi et de NAT FTP
ip_conntrack_ftp et ip_nat_ftp de Netfilter qui lisent et modifient à l a
volée l'adresse et le port des commandes PASV et PORT dans le flux de l a
connexion FTP de contrôle. Mais le chiffrement par SSL/TLS de cette
connexion les empêche de le faire.
Que reste-t-il ?
Première option, passer vsftpd en mode FTP actif. Ainsi les connexions
de données seront sortantes. Mais si le client est aussi derrière un NAT
ou un firewall, il risque d'avoir en mode actif le même problème que le
serveur en mode passif.
L'autre solution que je connais consiste à :
- limiter la plage de ports en mode passif de vsftpd (déjà fait mais la
plage 10000-20000 me semble inutilement étendue) ;
- au niveau du routeur NAT et du firewall, autoriser en entrée depuis
l'extérieur et rediriger cette plage de ports vers l'adresse privée d u
serveur ;
- forcer vsftpd à annoncer l'adresse IP publique du routeur au lieu de
son adresse locale dans les réponses aux commandes PASV avec l'option
"pasv_address". (*)
(*) Ça peut être laborieux si l'adresse en question n'est pas fixe : il
faut la récupérer, modifier vsftpd.conf et relancer vsftpd s'il
fonctionne en démon.
Opinion personnelle : ce ne devrait pas être bien difficile de permettr e
de spécifier un nom d'hôte au lieu d'une adresse IP numérique et de
résoudre ce nom d'hôte à chaque commande PASV, afin de pouvoir util iser
un DNS dynamique et de ne pas avoir besoin de modifier vsftpd.conf ni de
relancer vsftpd à chaque changement d'adresse.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Salut,
Matthieu a écrit :
>
> je desespere quand a la configuration de mon serveur vsftpd. je n'arriv e
pas
> a recuperer la liste de mes dossiers bien que j'arrive a me connecter.
Sans lire la suite je parie déjà qu'il y a du NAT ou du filtrage
là-dessous. Le protocole FTP, à cause de sa complexité, ne fait pas
toujours bon ménage avec ces deux-là.
> mon architecture reseau est la suivante:
> - un routeur assure la connexion entre la dmz et l'internet via du nat.
Du NAT -> gagné ! ;-)
Sous Linux le routeur ?
> - le serveur a pour ip 192.168.25.10
> - sur le serveur un iptables avec comme regles a la fin un logging des
> packets non autorisés
Et comment sont gérées les connexions de données FTP ?
> - une configuration de vsftpd en mode passif pour des hotes virtuels:
>
> listen=YES
> pasv_enable=YES
> pasv_promiscuous=YES
> pasv_min_port=10000
> pasv_max_port=20000
> ssl_enable=YES
[...]
> seulement lorsque je me connectes avec mon client ftp filezilla 2.2.18e n
> ftp sur tls, j'obtiens le log suivant:
[...]
> Commande : PASV
> Réponse : 227 Entering Passive Mode (192,168,25,10,59,167)
> Commande : LIST
> Erreur : Le canal de transfert n'a pas pu être ouvert.
> et puis plus rien. rien dans le syslog concernant iptables, rien dans
les
> logs de mon routeur concernant des paquets rejetés.
Examine la réponse du serveur à la commande PASV : l'adresse transmis e
en vue d'établir la connexion de données est 192.168.25.10, l'adresse
privée du serveur. Il est évidemment impossible pour un client exté rieur
de joindre le serveur à cette adresse qui n'a de sens que sur le rése au
local du serveur. Comme le client cherche à se connecter à cette adre sse
privée non routée sur internet, il est normal que ni le routeur ni le
serveur ne voient rien arriver.
> que puis je faire ou que me manque t'il dans ma configuration vsftpd ou
ssl
> pour que je puisse utiliser vsftpd sur ssl?
Quand le routeur NAT est un Linux 2.4 ou ultérieur, la solution
classique consiste à utiliser les modules de suivi et de NAT FTP
ip_conntrack_ftp et ip_nat_ftp de Netfilter qui lisent et modifient à l a
volée l'adresse et le port des commandes PASV et PORT dans le flux de l a
connexion FTP de contrôle. Mais le chiffrement par SSL/TLS de cette
connexion les empêche de le faire.
Que reste-t-il ?
Première option, passer vsftpd en mode FTP actif. Ainsi les connexions
de données seront sortantes. Mais si le client est aussi derrière un NAT
ou un firewall, il risque d'avoir en mode actif le même problème que le
serveur en mode passif.
L'autre solution que je connais consiste à :
- limiter la plage de ports en mode passif de vsftpd (déjà fait mais la
plage 10000-20000 me semble inutilement étendue) ;
- au niveau du routeur NAT et du firewall, autoriser en entrée depuis
l'extérieur et rediriger cette plage de ports vers l'adresse privée d u
serveur ;
- forcer vsftpd à annoncer l'adresse IP publique du routeur au lieu de
son adresse locale dans les réponses aux commandes PASV avec l'option
"pasv_address". (*)
(*) Ça peut être laborieux si l'adresse en question n'est pas fixe : il
faut la récupérer, modifier vsftpd.conf et relancer vsftpd s'il
fonctionne en démon.
Opinion personnelle : ce ne devrait pas être bien difficile de permettr e
de spécifier un nom d'hôte au lieu d'une adresse IP numérique et de
résoudre ce nom d'hôte à chaque commande PASV, afin de pouvoir util iser
un DNS dynamique et de ne pas avoir besoin de modifier vsftpd.conf ni de
relancer vsftpd à chaque changement d'adresse.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Salut,
Matthieu a écrit :
>
> je desespere quand a la configuration de mon serveur vsftpd. je n'arriv e
pas
> a recuperer la liste de mes dossiers bien que j'arrive a me connecter.
Sans lire la suite je parie déjà qu'il y a du NAT ou du filtrage
là-dessous. Le protocole FTP, à cause de sa complexité, ne fait pas
toujours bon ménage avec ces deux-là.
> mon architecture reseau est la suivante:
> - un routeur assure la connexion entre la dmz et l'internet via du nat.
Du NAT -> gagné ! ;-)
Sous Linux le routeur ?
> - le serveur a pour ip 192.168.25.10
> - sur le serveur un iptables avec comme regles a la fin un logging des
> packets non autorisés
Et comment sont gérées les connexions de données FTP ?
> - une configuration de vsftpd en mode passif pour des hotes virtuels:
>
> listen=YES
> pasv_enable=YES
> pasv_promiscuous=YES
> pasv_min_port000
> pasv_max_port 000
> ssl_enable=YES
[...]
> seulement lorsque je me connectes avec mon client ftp filezilla 2.2.18e n
> ftp sur tls, j'obtiens le log suivant:
[...]
> Commande : PASV
> Réponse : 227 Entering Passive Mode (192,168,25,10,59,167)
> Commande : LIST
> Erreur : Le canal de transfert n'a pas pu être ouvert.
> et puis plus rien. rien dans le syslog concernant iptables, rien dans
les
> logs de mon routeur concernant des paquets rejetés.
Examine la réponse du serveur à la commande PASV : l'adresse transmis e
en vue d'établir la connexion de données est 192.168.25.10, l'adresse
privée du serveur. Il est évidemment impossible pour un client exté rieur
de joindre le serveur à cette adresse qui n'a de sens que sur le rése au
local du serveur. Comme le client cherche à se connecter à cette adre sse
privée non routée sur internet, il est normal que ni le routeur ni le
serveur ne voient rien arriver.
> que puis je faire ou que me manque t'il dans ma configuration vsftpd ou
ssl
> pour que je puisse utiliser vsftpd sur ssl?
Quand le routeur NAT est un Linux 2.4 ou ultérieur, la solution
classique consiste à utiliser les modules de suivi et de NAT FTP
ip_conntrack_ftp et ip_nat_ftp de Netfilter qui lisent et modifient à l a
volée l'adresse et le port des commandes PASV et PORT dans le flux de l a
connexion FTP de contrôle. Mais le chiffrement par SSL/TLS de cette
connexion les empêche de le faire.
Que reste-t-il ?
Première option, passer vsftpd en mode FTP actif. Ainsi les connexions
de données seront sortantes. Mais si le client est aussi derrière un NAT
ou un firewall, il risque d'avoir en mode actif le même problème que le
serveur en mode passif.
L'autre solution que je connais consiste à :
- limiter la plage de ports en mode passif de vsftpd (déjà fait mais la
plage 10000-20000 me semble inutilement étendue) ;
- au niveau du routeur NAT et du firewall, autoriser en entrée depuis
l'extérieur et rediriger cette plage de ports vers l'adresse privée d u
serveur ;
- forcer vsftpd à annoncer l'adresse IP publique du routeur au lieu de
son adresse locale dans les réponses aux commandes PASV avec l'option
"pasv_address". (*)
(*) Ça peut être laborieux si l'adresse en question n'est pas fixe : il
faut la récupérer, modifier vsftpd.conf et relancer vsftpd s'il
fonctionne en démon.
Opinion personnelle : ce ne devrait pas être bien difficile de permettr e
de spécifier un nom d'hôte au lieu d'une adresse IP numérique et de
résoudre ce nom d'hôte à chaque commande PASV, afin de pouvoir util iser
un DNS dynamique et de ne pas avoir besoin de modifier vsftpd.conf ni de
relancer vsftpd à chaque changement d'adresse.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Examine la réponse du serveur à la commande PASV : l'adresse transmise
en vue d'établir la connexion de données est 192.168.25.10
<http://192.168.25.10>, l'adresse privée du serveur. Il est évidemment
impossible pour un client extérieur de joindre le serveur à cette
adresse qui n'a de sens que sur le réseau local du serveur. Comme le
client cherche à se connecter à cette adresse privée non routée sur
internet, il est normal que ni le routeur ni le serveur ne voient rien
arriver.
oui j'ai bien vu la reponse, mais ce comportement n'est pas genant en
mode non ssl.
L'autre solution que je connais consiste à :
- limiter la plage de ports en mode passif de vsftpd (déjà fait mais
la plage 10000-20000 me semble inutilement étendue) ;
ok
en ce qui concerne ces trois points, ils sont a utiliser separement
j'imagines?
- au niveau du routeur NAT et du firewall, autoriser en entrée depuis
l'extérieur et rediriger cette plage de ports vers l'adresse privée du
serveur ; *
heu, il faut que je fasse du filtrage sur un grand nombre de port?
pas que ce soit impossible mais moins j'ai de ports d'ouverts, mieux
je me porte :)
- forcer vsftpd à annoncer l'adresse IP publique du routeur au lieu de
son adresse locale dans les réponses aux commandes PASV avec l'option
"pasv_address".
merci pour toutes ses pistes en tout cas :)
Examine la réponse du serveur à la commande PASV : l'adresse transmise
en vue d'établir la connexion de données est 192.168.25.10
<http://192.168.25.10>, l'adresse privée du serveur. Il est évidemment
impossible pour un client extérieur de joindre le serveur à cette
adresse qui n'a de sens que sur le réseau local du serveur. Comme le
client cherche à se connecter à cette adresse privée non routée sur
internet, il est normal que ni le routeur ni le serveur ne voient rien
arriver.
oui j'ai bien vu la reponse, mais ce comportement n'est pas genant en
mode non ssl.
L'autre solution que je connais consiste à :
- limiter la plage de ports en mode passif de vsftpd (déjà fait mais
la plage 10000-20000 me semble inutilement étendue) ;
ok
en ce qui concerne ces trois points, ils sont a utiliser separement
j'imagines?
- au niveau du routeur NAT et du firewall, autoriser en entrée depuis
l'extérieur et rediriger cette plage de ports vers l'adresse privée du
serveur ; *
heu, il faut que je fasse du filtrage sur un grand nombre de port?
pas que ce soit impossible mais moins j'ai de ports d'ouverts, mieux
je me porte :)
- forcer vsftpd à annoncer l'adresse IP publique du routeur au lieu de
son adresse locale dans les réponses aux commandes PASV avec l'option
"pasv_address".
merci pour toutes ses pistes en tout cas :)
Examine la réponse du serveur à la commande PASV : l'adresse transmise
en vue d'établir la connexion de données est 192.168.25.10
<http://192.168.25.10>, l'adresse privée du serveur. Il est évidemment
impossible pour un client extérieur de joindre le serveur à cette
adresse qui n'a de sens que sur le réseau local du serveur. Comme le
client cherche à se connecter à cette adresse privée non routée sur
internet, il est normal que ni le routeur ni le serveur ne voient rien
arriver.
oui j'ai bien vu la reponse, mais ce comportement n'est pas genant en
mode non ssl.
L'autre solution que je connais consiste à :
- limiter la plage de ports en mode passif de vsftpd (déjà fait mais
la plage 10000-20000 me semble inutilement étendue) ;
ok
en ce qui concerne ces trois points, ils sont a utiliser separement
j'imagines?
- au niveau du routeur NAT et du firewall, autoriser en entrée depuis
l'extérieur et rediriger cette plage de ports vers l'adresse privée du
serveur ; *
heu, il faut que je fasse du filtrage sur un grand nombre de port?
pas que ce soit impossible mais moins j'ai de ports d'ouverts, mieux
je me porte :)
- forcer vsftpd à annoncer l'adresse IP publique du routeur au lieu de
son adresse locale dans les réponses aux commandes PASV avec l'option
"pasv_address".
merci pour toutes ses pistes en tout cas :)