- Un serveur vsftp en mode passif est présent sur mon serveur
- Une livebox qui forward les ports passifs ainsi que le port 21 vers mon
serveur.
Le module de suivi de connexion ftp est bien chargé et précise le port 21
comme port pour le control channel.
Les résultats obtenus :
- Un fonctionnement normal sur mon réseau en adaptant l'option de vsftpd
pasv_address pour mon reseau local. Le suivi de connexion fonctionne,
la connexion sur le data channel est bien reconnue comme étant dans
l'état RELATED et non NEW.
- Depuis l'extérieur, en adaptant l'option pasv_address pour Internet,
les connexions sur le control channel se font normalement, mais la
première connexion sur le data channel qui devrait être considérée
comme RELATED, est reconnue comme NEW
- Un serveur vsftp en mode passif est présent sur mon serveur
- Une livebox qui forward les ports passifs ainsi que le port 21 vers mon
serveur.
Le module de suivi de connexion ftp est bien chargé et précise le port 21
comme port pour le control channel.
Les résultats obtenus :
- Un fonctionnement normal sur mon réseau en adaptant l'option de vsftpd
pasv_address pour mon reseau local. Le suivi de connexion fonctionne,
la connexion sur le data channel est bien reconnue comme étant dans
l'état RELATED et non NEW.
- Depuis l'extérieur, en adaptant l'option pasv_address pour Internet,
les connexions sur le control channel se font normalement, mais la
première connexion sur le data channel qui devrait être considérée
comme RELATED, est reconnue comme NEW
- Un serveur vsftp en mode passif est présent sur mon serveur
- Une livebox qui forward les ports passifs ainsi que le port 21 vers mon
serveur.
Le module de suivi de connexion ftp est bien chargé et précise le port 21
comme port pour le control channel.
Les résultats obtenus :
- Un fonctionnement normal sur mon réseau en adaptant l'option de vsftpd
pasv_address pour mon reseau local. Le suivi de connexion fonctionne,
la connexion sur le data channel est bien reconnue comme étant dans
l'état RELATED et non NEW.
- Depuis l'extérieur, en adaptant l'option pasv_address pour Internet,
les connexions sur le control channel se font normalement, mais la
première connexion sur le data channel qui devrait être considérée
comme RELATED, est reconnue comme NEW
Salut,
Franck Joncourt a écrit :
>- Un serveur vsftp en mode passif est présent sur mon serveur
>- Une livebox qui forward les ports passifs ainsi que le port 21 vers mon
> serveur.
[...]
>Le module de suivi de connexion ftp est bien chargé et précise le port 21
>comme port pour le control channel.
>
>Les résultats obtenus :
>- Un fonctionnement normal sur mon réseau en adaptant l'option de v sftpd
> pasv_address pour mon reseau local. Le suivi de connexion fonctionne,
> la connexion sur le data channel est bien reconnue comme étant da ns
> l'état RELATED et non NEW.
Quand tu écris "en adaptant l'option pasv_address", je suppose que t u
lui affectes l'adresse privée du serveur, et que ça marcherait aussi
bien sans cette option puisque par défaut le serveur transmet sa pro pre
adresse ?
>- Depuis l'extérieur, en adaptant l'option pasv_address pour Intern et,
> les connexions sur le control channel se font normalement, mais la
> première connexion sur le data channel qui devrait être consi dérée
> comme RELATED, est reconnue comme NEW
Dans ce cas je suppose que l'option pasv_address est réglée pou r
transmettre l'adresse publique de la Livebox.
un paquet de demande
d'établissement d'une connexion de données en mode passif arriv e à la
Livebox, subit la redirection de port de la Livebox et arrive au serveur
avec comme adresse de destination l'adresse privée du serveur. Mon a vis
est que le suivi de connexion du serveur attend comme adresse de
destination l'adresse publique, qu'il a vue dans la réponse à l a
commande PASV, et ne reconnaît pas le paquet avec l'adresse privà ©e comme
lié à la connexion FTP.
Une solution simple consisterait à autoriser l'état NEW en entr ée pour
les ports passifs. Mais je pense que tu le savais déjà .
Accessoirement, tu as vérifié que la Livebox ne fait pas toute seule la
translation de l'adresse en mode passif, comme je suppose qu'elle le
fait en mode actif ?
Salut,
Franck Joncourt a écrit :
>- Un serveur vsftp en mode passif est présent sur mon serveur
>- Une livebox qui forward les ports passifs ainsi que le port 21 vers mon
> serveur.
[...]
>Le module de suivi de connexion ftp est bien chargé et précise le port 21
>comme port pour le control channel.
>
>Les résultats obtenus :
>- Un fonctionnement normal sur mon réseau en adaptant l'option de v sftpd
> pasv_address pour mon reseau local. Le suivi de connexion fonctionne,
> la connexion sur le data channel est bien reconnue comme étant da ns
> l'état RELATED et non NEW.
Quand tu écris "en adaptant l'option pasv_address", je suppose que t u
lui affectes l'adresse privée du serveur, et que ça marcherait aussi
bien sans cette option puisque par défaut le serveur transmet sa pro pre
adresse ?
>- Depuis l'extérieur, en adaptant l'option pasv_address pour Intern et,
> les connexions sur le control channel se font normalement, mais la
> première connexion sur le data channel qui devrait être consi dérée
> comme RELATED, est reconnue comme NEW
Dans ce cas je suppose que l'option pasv_address est réglée pou r
transmettre l'adresse publique de la Livebox.
un paquet de demande
d'établissement d'une connexion de données en mode passif arriv e à la
Livebox, subit la redirection de port de la Livebox et arrive au serveur
avec comme adresse de destination l'adresse privée du serveur. Mon a vis
est que le suivi de connexion du serveur attend comme adresse de
destination l'adresse publique, qu'il a vue dans la réponse à l a
commande PASV, et ne reconnaît pas le paquet avec l'adresse privà ©e comme
lié à la connexion FTP.
Une solution simple consisterait à autoriser l'état NEW en entr ée pour
les ports passifs. Mais je pense que tu le savais déjà .
Accessoirement, tu as vérifié que la Livebox ne fait pas toute seule la
translation de l'adresse en mode passif, comme je suppose qu'elle le
fait en mode actif ?
Salut,
Franck Joncourt a écrit :
>- Un serveur vsftp en mode passif est présent sur mon serveur
>- Une livebox qui forward les ports passifs ainsi que le port 21 vers mon
> serveur.
[...]
>Le module de suivi de connexion ftp est bien chargé et précise le port 21
>comme port pour le control channel.
>
>Les résultats obtenus :
>- Un fonctionnement normal sur mon réseau en adaptant l'option de v sftpd
> pasv_address pour mon reseau local. Le suivi de connexion fonctionne,
> la connexion sur le data channel est bien reconnue comme étant da ns
> l'état RELATED et non NEW.
Quand tu écris "en adaptant l'option pasv_address", je suppose que t u
lui affectes l'adresse privée du serveur, et que ça marcherait aussi
bien sans cette option puisque par défaut le serveur transmet sa pro pre
adresse ?
>- Depuis l'extérieur, en adaptant l'option pasv_address pour Intern et,
> les connexions sur le control channel se font normalement, mais la
> première connexion sur le data channel qui devrait être consi dérée
> comme RELATED, est reconnue comme NEW
Dans ce cas je suppose que l'option pasv_address est réglée pou r
transmettre l'adresse publique de la Livebox.
un paquet de demande
d'établissement d'une connexion de données en mode passif arriv e à la
Livebox, subit la redirection de port de la Livebox et arrive au serveur
avec comme adresse de destination l'adresse privée du serveur. Mon a vis
est que le suivi de connexion du serveur attend comme adresse de
destination l'adresse publique, qu'il a vue dans la réponse à l a
commande PASV, et ne reconnaît pas le paquet avec l'adresse privà ©e comme
lié à la connexion FTP.
Une solution simple consisterait à autoriser l'état NEW en entr ée pour
les ports passifs. Mais je pense que tu le savais déjà .
Accessoirement, tu as vérifié que la Livebox ne fait pas toute seule la
translation de l'adresse en mode passif, comme je suppose qu'elle le
fait en mode actif ?
Quand tu écris "en adaptant l'option pasv_address", je suppose que tu
lui affectes l'adresse privée du serveur, et que ça marcherait aussi
bien sans cette option puisque par défaut le serveur transmet sa propre
adresse ?
Oui c'est ça, sauf que je ne savais pas quelle adresse il mettait dans
la réponse à une requête pasv si je ne définissais pas celle-ci
explicitement.
Une solution simple consisterait à autoriser l'état NEW en entrée pour
les ports passifs. Mais je pense que tu le savais déjà.
Oui, mais cela me déplait un peu.
Accessoirement, tu as vérifié que la Livebox ne fait pas toute seule la
translation de l'adresse en mode passif, comme je suppose qu'elle le
fait en mode actif ?
Qu'entends tu par translation de l'adresse en mode passif ?
Donc d'après ce que je comprends, deux cas se présentent (dans tous les
cas le dialogue sur le control channel se passe bien)
1/ cas 1: la réponse du serveur FTP, au client extérieur, à la commande
PASV contient l'adresse local, et le port de connexion sur lequel le
serveur est à l'écoute. La xxbox se charge de modifier les en-tête
des trames ip pour la prise en compte de l'adresse publique. Le client
tente de se connecter alors sur le data channel mais échoue à cause de
l'ip destination qui est l'ip local du serveur. La solution serait que
la xxbox modifie l'ip présente dans la réponse à la commande PASV (ip
locale du serveur) par l'ip publique.
=> Il n'y a aucune chance que ce soit possible. Dans ce cas, le suivi
de connexion aurait fonctionné.
2/ cas 2 : celui que je rencontre et que tu as expliqué ci-dessus.
Le suivi de connexion ne fonctionne pas.
Au final, il n'y a pas d'issue hormis d'autoriser les connexions de
types NEW sur les ports passifs du serveur.
Quand tu écris "en adaptant l'option pasv_address", je suppose que tu
lui affectes l'adresse privée du serveur, et que ça marcherait aussi
bien sans cette option puisque par défaut le serveur transmet sa propre
adresse ?
Oui c'est ça, sauf que je ne savais pas quelle adresse il mettait dans
la réponse à une requête pasv si je ne définissais pas celle-ci
explicitement.
Une solution simple consisterait à autoriser l'état NEW en entrée pour
les ports passifs. Mais je pense que tu le savais déjà.
Oui, mais cela me déplait un peu.
Accessoirement, tu as vérifié que la Livebox ne fait pas toute seule la
translation de l'adresse en mode passif, comme je suppose qu'elle le
fait en mode actif ?
Qu'entends tu par translation de l'adresse en mode passif ?
Donc d'après ce que je comprends, deux cas se présentent (dans tous les
cas le dialogue sur le control channel se passe bien)
1/ cas 1: la réponse du serveur FTP, au client extérieur, à la commande
PASV contient l'adresse local, et le port de connexion sur lequel le
serveur est à l'écoute. La xxbox se charge de modifier les en-tête
des trames ip pour la prise en compte de l'adresse publique. Le client
tente de se connecter alors sur le data channel mais échoue à cause de
l'ip destination qui est l'ip local du serveur. La solution serait que
la xxbox modifie l'ip présente dans la réponse à la commande PASV (ip
locale du serveur) par l'ip publique.
=> Il n'y a aucune chance que ce soit possible. Dans ce cas, le suivi
de connexion aurait fonctionné.
2/ cas 2 : celui que je rencontre et que tu as expliqué ci-dessus.
Le suivi de connexion ne fonctionne pas.
Au final, il n'y a pas d'issue hormis d'autoriser les connexions de
types NEW sur les ports passifs du serveur.
Quand tu écris "en adaptant l'option pasv_address", je suppose que tu
lui affectes l'adresse privée du serveur, et que ça marcherait aussi
bien sans cette option puisque par défaut le serveur transmet sa propre
adresse ?
Oui c'est ça, sauf que je ne savais pas quelle adresse il mettait dans
la réponse à une requête pasv si je ne définissais pas celle-ci
explicitement.
Une solution simple consisterait à autoriser l'état NEW en entrée pour
les ports passifs. Mais je pense que tu le savais déjà.
Oui, mais cela me déplait un peu.
Accessoirement, tu as vérifié que la Livebox ne fait pas toute seule la
translation de l'adresse en mode passif, comme je suppose qu'elle le
fait en mode actif ?
Qu'entends tu par translation de l'adresse en mode passif ?
Donc d'après ce que je comprends, deux cas se présentent (dans tous les
cas le dialogue sur le control channel se passe bien)
1/ cas 1: la réponse du serveur FTP, au client extérieur, à la commande
PASV contient l'adresse local, et le port de connexion sur lequel le
serveur est à l'écoute. La xxbox se charge de modifier les en-tête
des trames ip pour la prise en compte de l'adresse publique. Le client
tente de se connecter alors sur le data channel mais échoue à cause de
l'ip destination qui est l'ip local du serveur. La solution serait que
la xxbox modifie l'ip présente dans la réponse à la commande PASV (ip
locale du serveur) par l'ip publique.
=> Il n'y a aucune chance que ce soit possible. Dans ce cas, le suivi
de connexion aurait fonctionné.
2/ cas 2 : celui que je rencontre et que tu as expliqué ci-dessus.
Le suivi de connexion ne fonctionne pas.
Au final, il n'y a pas d'issue hormis d'autoriser les connexions de
types NEW sur les ports passifs du serveur.
Franck Joncourt a écrit :
>>
>Oui c'est ça, sauf que je ne savais pas quelle adresse il mettait d ans
>la réponse à une requête pasv si je ne définissais p as celle-ci
>explicitement.
Normalement il devrait mettre l'adresse avec laquelle il répond, qui est
l'adresse sur laquelle il a reçu la connection de contrôle du c lient.
[...]
>>Une solution simple consisterait à autoriser l'état NEW en en trée pour
>>les ports passifs. Mais je pense que tu le savais déjà .
>
>Oui, mais cela me déplait un peu.
Sinon, j'avais aussi pensé à charger le module de suivi de conn ection
FTP ip_conntrack_ftp ou nf_conntrack_ftp avec l'option loose=1. Je ne
suis pas certain du rôle de cette option, peut-être que c'est p lutôt
pour le FXP (transfert de serveur à serveur), mais ça ne te co ûte pas
grand chose d'essayer. Moi je n'ai pas trop le temps de monter une manip
pour tester, mais retour bienvenu.
>Qu'entends tu par translation de l'adresse en mode passif ?
La translation de l'adresse transmise par le serveur dans la réponse Ã
la commande PASV afin qu'elle corresponde à l'adresse source du paqu et.
Il est assez courant que les routeurs NAT fassent cette translation dans
les commandes PORT afin que les transferts FTP en mode actif initiés
depuis un client masqué passent. Or l'opération est quasiment l a même
dans les deux cas.
>Donc d'après ce que je comprends, deux cas se présentent (dans tous les
>cas le dialogue sur le control channel se passe bien)
>
> 1/ cas 1: la réponse du serveur FTP, au client extérieur, à la commande
> PASV contient l'adresse local, et le port de connexion sur lequel le
> serveur est à l'écoute. La xxbox se charge de modifier les en -tête
> des trames ip pour la prise en compte de l'adresse publique. Le client
> tente de se connecter alors sur le data channel mais échoue à cause de
> l'ip destination qui est l'ip local du serveur. La solution serait que
> la xxbox modifie l'ip présente dans la réponse à la comm ande PASV (ip
> locale du serveur) par l'ip publique.
Oui, comme toute box basée sur un noyau Linux avec Netfilter et les
modules de suivi de connexion et NAT pour FTP le ferait.
> => Il n'y a aucune chance que ce soit possible. Dans ce cas, le suivi
> de connexion aurait fonctionné.
Comment ça ?
> 2/ cas 2 : celui que je rencontre et que tu as expliqué ci-dessus.
> Le suivi de connexion ne fonctionne pas.
>
>Au final, il n'y a pas d'issue hormis d'autoriser les connexions de
>types NEW sur les ports passifs du serveur.
En fait il y en a une troisième : ne pas utiliser le mode passif
classique (PASV) mais le mode passif étendu (EPSV) qui ne transmet q ue
le port et pas l'adresse (redondante puisque c'est forcément l'adres se
du serveur). Cela suppose d'utiliser uniquement un serveur FTP et des
clients FTP qui le supportent.
Franck Joncourt a écrit :
>>
>Oui c'est ça, sauf que je ne savais pas quelle adresse il mettait d ans
>la réponse à une requête pasv si je ne définissais p as celle-ci
>explicitement.
Normalement il devrait mettre l'adresse avec laquelle il répond, qui est
l'adresse sur laquelle il a reçu la connection de contrôle du c lient.
[...]
>>Une solution simple consisterait à autoriser l'état NEW en en trée pour
>>les ports passifs. Mais je pense que tu le savais déjà .
>
>Oui, mais cela me déplait un peu.
Sinon, j'avais aussi pensé à charger le module de suivi de conn ection
FTP ip_conntrack_ftp ou nf_conntrack_ftp avec l'option loose=1. Je ne
suis pas certain du rôle de cette option, peut-être que c'est p lutôt
pour le FXP (transfert de serveur à serveur), mais ça ne te co ûte pas
grand chose d'essayer. Moi je n'ai pas trop le temps de monter une manip
pour tester, mais retour bienvenu.
>Qu'entends tu par translation de l'adresse en mode passif ?
La translation de l'adresse transmise par le serveur dans la réponse Ã
la commande PASV afin qu'elle corresponde à l'adresse source du paqu et.
Il est assez courant que les routeurs NAT fassent cette translation dans
les commandes PORT afin que les transferts FTP en mode actif initiés
depuis un client masqué passent. Or l'opération est quasiment l a même
dans les deux cas.
>Donc d'après ce que je comprends, deux cas se présentent (dans tous les
>cas le dialogue sur le control channel se passe bien)
>
> 1/ cas 1: la réponse du serveur FTP, au client extérieur, à la commande
> PASV contient l'adresse local, et le port de connexion sur lequel le
> serveur est à l'écoute. La xxbox se charge de modifier les en -tête
> des trames ip pour la prise en compte de l'adresse publique. Le client
> tente de se connecter alors sur le data channel mais échoue à cause de
> l'ip destination qui est l'ip local du serveur. La solution serait que
> la xxbox modifie l'ip présente dans la réponse à la comm ande PASV (ip
> locale du serveur) par l'ip publique.
Oui, comme toute box basée sur un noyau Linux avec Netfilter et les
modules de suivi de connexion et NAT pour FTP le ferait.
> => Il n'y a aucune chance que ce soit possible. Dans ce cas, le suivi
> de connexion aurait fonctionné.
Comment ça ?
> 2/ cas 2 : celui que je rencontre et que tu as expliqué ci-dessus.
> Le suivi de connexion ne fonctionne pas.
>
>Au final, il n'y a pas d'issue hormis d'autoriser les connexions de
>types NEW sur les ports passifs du serveur.
En fait il y en a une troisième : ne pas utiliser le mode passif
classique (PASV) mais le mode passif étendu (EPSV) qui ne transmet q ue
le port et pas l'adresse (redondante puisque c'est forcément l'adres se
du serveur). Cela suppose d'utiliser uniquement un serveur FTP et des
clients FTP qui le supportent.
Franck Joncourt a écrit :
>>
>Oui c'est ça, sauf que je ne savais pas quelle adresse il mettait d ans
>la réponse à une requête pasv si je ne définissais p as celle-ci
>explicitement.
Normalement il devrait mettre l'adresse avec laquelle il répond, qui est
l'adresse sur laquelle il a reçu la connection de contrôle du c lient.
[...]
>>Une solution simple consisterait à autoriser l'état NEW en en trée pour
>>les ports passifs. Mais je pense que tu le savais déjà .
>
>Oui, mais cela me déplait un peu.
Sinon, j'avais aussi pensé à charger le module de suivi de conn ection
FTP ip_conntrack_ftp ou nf_conntrack_ftp avec l'option loose=1. Je ne
suis pas certain du rôle de cette option, peut-être que c'est p lutôt
pour le FXP (transfert de serveur à serveur), mais ça ne te co ûte pas
grand chose d'essayer. Moi je n'ai pas trop le temps de monter une manip
pour tester, mais retour bienvenu.
>Qu'entends tu par translation de l'adresse en mode passif ?
La translation de l'adresse transmise par le serveur dans la réponse Ã
la commande PASV afin qu'elle corresponde à l'adresse source du paqu et.
Il est assez courant que les routeurs NAT fassent cette translation dans
les commandes PORT afin que les transferts FTP en mode actif initiés
depuis un client masqué passent. Or l'opération est quasiment l a même
dans les deux cas.
>Donc d'après ce que je comprends, deux cas se présentent (dans tous les
>cas le dialogue sur le control channel se passe bien)
>
> 1/ cas 1: la réponse du serveur FTP, au client extérieur, à la commande
> PASV contient l'adresse local, et le port de connexion sur lequel le
> serveur est à l'écoute. La xxbox se charge de modifier les en -tête
> des trames ip pour la prise en compte de l'adresse publique. Le client
> tente de se connecter alors sur le data channel mais échoue à cause de
> l'ip destination qui est l'ip local du serveur. La solution serait que
> la xxbox modifie l'ip présente dans la réponse à la comm ande PASV (ip
> locale du serveur) par l'ip publique.
Oui, comme toute box basée sur un noyau Linux avec Netfilter et les
modules de suivi de connexion et NAT pour FTP le ferait.
> => Il n'y a aucune chance que ce soit possible. Dans ce cas, le suivi
> de connexion aurait fonctionné.
Comment ça ?
> 2/ cas 2 : celui que je rencontre et que tu as expliqué ci-dessus.
> Le suivi de connexion ne fonctionne pas.
>
>Au final, il n'y a pas d'issue hormis d'autoriser les connexions de
>types NEW sur les ports passifs du serveur.
En fait il y en a une troisième : ne pas utiliser le mode passif
classique (PASV) mais le mode passif étendu (EPSV) qui ne transmet q ue
le port et pas l'adresse (redondante puisque c'est forcément l'adres se
du serveur). Cela suppose d'utiliser uniquement un serveur FTP et des
clients FTP qui le supportent.
Qu'entends tu par translation de l'adresse en mode passif ?
La translation de l'adresse transmise par le serveur dans la réponse à
la commande PASV afin qu'elle corresponde à l'adresse source du paquet.
Il est assez courant que les routeurs NAT fassent cette translation dans
les commandes PORT afin que les transferts FTP en mode actif initiés
depuis un client masqué passent. Or l'opération est quasiment la même
dans les deux cas.
Malheureusement, elle n'a pas l'air de faire cela. En espionnant les
trames du côté client, je vois bien que le client tente d'effectuer la
connexion sur le data channel, en fonction de l'adresse placée dans la
réponse à la commande PASV. Et donc, si mon option pasv_address est
192.168.1.10 alors le client recoit l'ip 192.168.1.10 et tente d'établir
la connexion avec 192.168.1.10 et non plus sur mon adresse publique.
En fait il y en a une troisième : ne pas utiliser le mode passif
classique (PASV) mais le mode passif étendu (EPSV) qui ne transmet que
le port et pas l'adresse (redondante puisque c'est forcément l'adresse
du serveur). Cela suppose d'utiliser uniquement un serveur FTP et des
clients FTP qui le supportent.
Cela m'a l'air bien ça (EPSV), je vais aussi regarder ça.
et refaire mes manips car j'ai forcément loupé quelque chose.
Qu'entends tu par translation de l'adresse en mode passif ?
La translation de l'adresse transmise par le serveur dans la réponse à
la commande PASV afin qu'elle corresponde à l'adresse source du paquet.
Il est assez courant que les routeurs NAT fassent cette translation dans
les commandes PORT afin que les transferts FTP en mode actif initiés
depuis un client masqué passent. Or l'opération est quasiment la même
dans les deux cas.
Malheureusement, elle n'a pas l'air de faire cela. En espionnant les
trames du côté client, je vois bien que le client tente d'effectuer la
connexion sur le data channel, en fonction de l'adresse placée dans la
réponse à la commande PASV. Et donc, si mon option pasv_address est
192.168.1.10 alors le client recoit l'ip 192.168.1.10 et tente d'établir
la connexion avec 192.168.1.10 et non plus sur mon adresse publique.
En fait il y en a une troisième : ne pas utiliser le mode passif
classique (PASV) mais le mode passif étendu (EPSV) qui ne transmet que
le port et pas l'adresse (redondante puisque c'est forcément l'adresse
du serveur). Cela suppose d'utiliser uniquement un serveur FTP et des
clients FTP qui le supportent.
Cela m'a l'air bien ça (EPSV), je vais aussi regarder ça.
et refaire mes manips car j'ai forcément loupé quelque chose.
Qu'entends tu par translation de l'adresse en mode passif ?
La translation de l'adresse transmise par le serveur dans la réponse à
la commande PASV afin qu'elle corresponde à l'adresse source du paquet.
Il est assez courant que les routeurs NAT fassent cette translation dans
les commandes PORT afin que les transferts FTP en mode actif initiés
depuis un client masqué passent. Or l'opération est quasiment la même
dans les deux cas.
Malheureusement, elle n'a pas l'air de faire cela. En espionnant les
trames du côté client, je vois bien que le client tente d'effectuer la
connexion sur le data channel, en fonction de l'adresse placée dans la
réponse à la commande PASV. Et donc, si mon option pasv_address est
192.168.1.10 alors le client recoit l'ip 192.168.1.10 et tente d'établir
la connexion avec 192.168.1.10 et non plus sur mon adresse publique.
En fait il y en a une troisième : ne pas utiliser le mode passif
classique (PASV) mais le mode passif étendu (EPSV) qui ne transmet que
le port et pas l'adresse (redondante puisque c'est forcément l'adresse
du serveur). Cela suppose d'utiliser uniquement un serveur FTP et des
clients FTP qui le supportent.
Cela m'a l'air bien ça (EPSV), je vais aussi regarder ça.
et refaire mes manips car j'ai forcément loupé quelque chose.
Franck Joncourt a écrit :
>>
Sinon, j'avais aussi pensé à charger le module de suivi de conn ection
FTP ip_conntrack_ftp ou nf_conntrack_ftp avec l'option loose=1. Je ne
suis pas certain du rôle de cette option, peut-être que c'est p lutôt
pour le FXP (transfert de serveur à serveur), mais ça ne te co ûte pas
grand chose d'essayer. Moi je n'ai pas trop le temps de monter une manip
pour tester, mais retour bienvenu.
En fait il y en a une troisième : ne pas utiliser le mode passif
classique (PASV) mais le mode passif étendu (EPSV) qui ne transmet q ue
le port et pas l'adresse (redondante puisque c'est forcément l'adres se
du serveur). Cela suppose d'utiliser uniquement un serveur FTP et des
clients FTP qui le supportent.
Franck Joncourt a écrit :
>>
Sinon, j'avais aussi pensé à charger le module de suivi de conn ection
FTP ip_conntrack_ftp ou nf_conntrack_ftp avec l'option loose=1. Je ne
suis pas certain du rôle de cette option, peut-être que c'est p lutôt
pour le FXP (transfert de serveur à serveur), mais ça ne te co ûte pas
grand chose d'essayer. Moi je n'ai pas trop le temps de monter une manip
pour tester, mais retour bienvenu.
En fait il y en a une troisième : ne pas utiliser le mode passif
classique (PASV) mais le mode passif étendu (EPSV) qui ne transmet q ue
le port et pas l'adresse (redondante puisque c'est forcément l'adres se
du serveur). Cela suppose d'utiliser uniquement un serveur FTP et des
clients FTP qui le supportent.
Franck Joncourt a écrit :
>>
Sinon, j'avais aussi pensé à charger le module de suivi de conn ection
FTP ip_conntrack_ftp ou nf_conntrack_ftp avec l'option loose=1. Je ne
suis pas certain du rôle de cette option, peut-être que c'est p lutôt
pour le FXP (transfert de serveur à serveur), mais ça ne te co ûte pas
grand chose d'essayer. Moi je n'ai pas trop le temps de monter une manip
pour tester, mais retour bienvenu.
En fait il y en a une troisième : ne pas utiliser le mode passif
classique (PASV) mais le mode passif étendu (EPSV) qui ne transmet q ue
le port et pas l'adresse (redondante puisque c'est forcément l'adres se
du serveur). Cela suppose d'utiliser uniquement un serveur FTP et des
clients FTP qui le supportent.
On Wed, Jun 20, 2007 at 01:37:43AM +0200, Pascal Hambourg wrote:
Sinon, j'avais aussi pensé à charger le module de suivi de connection
FTP ip_conntrack_ftp ou nf_conntrack_ftp avec l'option loose=1. Je ne
suis pas certain du rôle de cette option, peut-être que c'est plutôt
pour le FXP (transfert de serveur à serveur), mais ça ne te coûte pas
grand chose d'essayer. Moi je n'ai pas trop le temps de monter une manip
pour tester, mais retour bienvenu.
Et bien je n'ai vu aucune différence :(!
Par contre, coté client FTP, je n'ai pas encore réussi à en
trouver/configurer un pour utiliser EPSV (coté windows).
Pour linux,
je n'ai pas encore vraiment essayé, j'ai simplement remarqué que gftp
proposait une option "ignore PASV address" ; donc cela devrait
fonctionner aussi.
On Wed, Jun 20, 2007 at 01:37:43AM +0200, Pascal Hambourg wrote:
Sinon, j'avais aussi pensé à charger le module de suivi de connection
FTP ip_conntrack_ftp ou nf_conntrack_ftp avec l'option loose=1. Je ne
suis pas certain du rôle de cette option, peut-être que c'est plutôt
pour le FXP (transfert de serveur à serveur), mais ça ne te coûte pas
grand chose d'essayer. Moi je n'ai pas trop le temps de monter une manip
pour tester, mais retour bienvenu.
Et bien je n'ai vu aucune différence :(!
Par contre, coté client FTP, je n'ai pas encore réussi à en
trouver/configurer un pour utiliser EPSV (coté windows).
Pour linux,
je n'ai pas encore vraiment essayé, j'ai simplement remarqué que gftp
proposait une option "ignore PASV address" ; donc cela devrait
fonctionner aussi.
On Wed, Jun 20, 2007 at 01:37:43AM +0200, Pascal Hambourg wrote:
Sinon, j'avais aussi pensé à charger le module de suivi de connection
FTP ip_conntrack_ftp ou nf_conntrack_ftp avec l'option loose=1. Je ne
suis pas certain du rôle de cette option, peut-être que c'est plutôt
pour le FXP (transfert de serveur à serveur), mais ça ne te coûte pas
grand chose d'essayer. Moi je n'ai pas trop le temps de monter une manip
pour tester, mais retour bienvenu.
Et bien je n'ai vu aucune différence :(!
Par contre, coté client FTP, je n'ai pas encore réussi à en
trouver/configurer un pour utiliser EPSV (coté windows).
Pour linux,
je n'ai pas encore vraiment essayé, j'ai simplement remarqué que gftp
proposait une option "ignore PASV address" ; donc cela devrait
fonctionner aussi.
Franck Joncourt a écrit :
>On Wed, Jun 20, 2007 at 01:37:43AM +0200, Pascal Hambourg wrote:
>Et bien je n'ai vu aucune différence :(!
Bah, je n'y croyais guère moi-même. Merci pour le retour.
[...]
>Par contre, coté client FTP, je n'ai pas encore réussi à en
>trouver/configurer un pour utiliser EPSV (coté windows).
Je ne peux guère t'aider de ce côté. La dernière fois que j'ai
regardé, il ne me semble pas que FileZilla supportait les modes
passif/actif étendus. Sous Linux, j'utilise lukemftp en ligne de com mande
qui les supporte.
>Pour linux,
>je n'ai pas encore vraiment essayé, j'ai simplement remarqué q ue gftp
>proposait une option "ignore PASV address" ; donc cela devrait
>fonctionner aussi.
Ãa peut être une bonne solution effectivement, à condition qu'il n'y ait
pas en chemin un firewall qui ait la riche idée de vérifier la cohérence
entre l'adresse source dans l'en-tête IP et l'adresse dans la rà ©ponse
PASV...
Franck Joncourt a écrit :
>On Wed, Jun 20, 2007 at 01:37:43AM +0200, Pascal Hambourg wrote:
>Et bien je n'ai vu aucune différence :(!
Bah, je n'y croyais guère moi-même. Merci pour le retour.
[...]
>Par contre, coté client FTP, je n'ai pas encore réussi à en
>trouver/configurer un pour utiliser EPSV (coté windows).
Je ne peux guère t'aider de ce côté. La dernière fois que j'ai
regardé, il ne me semble pas que FileZilla supportait les modes
passif/actif étendus. Sous Linux, j'utilise lukemftp en ligne de com mande
qui les supporte.
>Pour linux,
>je n'ai pas encore vraiment essayé, j'ai simplement remarqué q ue gftp
>proposait une option "ignore PASV address" ; donc cela devrait
>fonctionner aussi.
Ãa peut être une bonne solution effectivement, à condition qu'il n'y ait
pas en chemin un firewall qui ait la riche idée de vérifier la cohérence
entre l'adresse source dans l'en-tête IP et l'adresse dans la rà ©ponse
PASV...
Franck Joncourt a écrit :
>On Wed, Jun 20, 2007 at 01:37:43AM +0200, Pascal Hambourg wrote:
>Et bien je n'ai vu aucune différence :(!
Bah, je n'y croyais guère moi-même. Merci pour le retour.
[...]
>Par contre, coté client FTP, je n'ai pas encore réussi à en
>trouver/configurer un pour utiliser EPSV (coté windows).
Je ne peux guère t'aider de ce côté. La dernière fois que j'ai
regardé, il ne me semble pas que FileZilla supportait les modes
passif/actif étendus. Sous Linux, j'utilise lukemftp en ligne de com mande
qui les supporte.
>Pour linux,
>je n'ai pas encore vraiment essayé, j'ai simplement remarqué q ue gftp
>proposait une option "ignore PASV address" ; donc cela devrait
>fonctionner aussi.
Ãa peut être une bonne solution effectivement, à condition qu'il n'y ait
pas en chemin un firewall qui ait la riche idée de vérifier la cohérence
entre l'adresse source dans l'en-tête IP et l'adresse dans la rà ©ponse
PASV...