ftp : xxbox et suivi de connexion

Le
Franck Joncourt
--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Bonsoir,

Je rencontre un problème qui commence à m'agacer sérieusemen=
t, et je
vous l'expose dans l'espoir qu'il y ait quelqu'un qui aurait une
explication.

Les états de connexions mentionnés sont associés à ipta=
bles/netfilter

Le contexte :
- 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.
- Un firewall qui autorise :
- pour la chaine INPUT, le port 21 en NEW et ESTABLISHED, les
ports passif en RELATED, ESTABLISHED
- pour la chaine OUTPUT, le port 21 en ESTABLISHED, les ports
passifs en ESTABLISHED

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 vsft=
pd
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 REALTED, est reconnue comme NEW ; du coup mon firewall bloque
l'accès au client.

Ma question est donc, pourquoi la première connexion sur le data
channel, depuis l'extérieur, est elle considérée comme NEW e=
t non pas
RELATED ?

Au final, la connexion FTP sur mon serveur est impossible depuis des
clients ftp classiques.

--
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

--IJpNTDwzlM2Ie8A6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--BEGIN PGP SIGNATURE--
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGdt5pxJBTTnXAif4RAg8WAKCA4vSsbztkfPwUINpW8de3mr4hngCg0Weg
jktj+iMkf23nxXHnfE0YuhQ=
=vENs
--END PGP SIGNATURE--

--IJpNTDwzlM2Ie8A6--


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter 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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #9787111
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 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.



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 ?

- 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



Dans ce cas je suppose que l'option pasv_address est réglée pour
transmettre l'adresse publique de la Livebox. Or un paquet de demande
d'établissement d'une connexion de données en mode passif arrive à 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 avis
est que le suivi de connexion du serveur attend comme adresse de
destination l'adresse publique, qu'il a vue dans la réponse à la
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 ?


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Franck Joncourt
Le #9786931
--RnlQjJ0d97Da+TV1
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 18, 2007 at 11:33:49PM +0200, Pascal Hambourg wrote:
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 ?



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.


>- 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.



Toujours bon :p!

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.



Maintenenant que tu me le dis, celà me paraît logique. Mais je n' y avais
pas pensé.

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 ?
Je considère le fait que la livebox change l'adresse publique contenue
dans l'en-tête des trames ip par l'adresse de mon serveur en local,
comme de la translation d'adresse. C'est ce qui est fait, quand un
client tente de se connecter sur mon serveur FTP en utilisant mon
adresse publique. C'est la façon dont je vois les choses.

Donc d'après ce que je comprends, deux cas se présentent (dans to us 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 à ca use 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 command e 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 aurais 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.
Si, il y a bien une autre solution qui est toute a fait envisageable,
remplacer cette livebox par un modem ; cela fait longtemps que je me dis
cela, mais elle me nargue toujours depuis le temps :p!

--
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

--RnlQjJ0d97Da+TV1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGeCvfxJBTTnXAif4RAuJCAKC633KTS38mIXCfnvxB5Ku5bL/ZrACgt1OI
dh8ZQoLfSSewF/+sbnuETPY Äp0
-----END PGP SIGNATURE-----

--RnlQjJ0d97Da+TV1--


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Le #9786831
Franck Joncourt a écrit :

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.



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 client.

[...]
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.



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.

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 ?



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.

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.



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 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.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Franck Joncourt
Le #9784601
--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 20, 2007 at 01:37:43AM +0200, Pascal Hambourg wrote:
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.




Je verrais, ce n'est pas dificile à mettre en évidence de toute f açon.

[...]
>>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.




J'essaierais aussi et je te dirais ce qu'il en est.

>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.




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'effectu er 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 e st
192.168.1.10 alors le client recoit l'ip 192.168.1.10 et tente d'établ ir
la connexion avec 192.168.1.10 et non plus sur mon adresse publique.
Comme la requete doit passer via Internet, elle se perd en chemin.
C'est ce que je tente d'expliquer dans le cas 1 ci dessous.

Si l'option pasv_address contient mon ip publique, alors c'est le cas 2.


>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 ?



Ca ne fonctionne pas chez moi, comme je le précise dans ce mail un peu
plus haut.


> 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.




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
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

--vkogqOf2sHV7VnPd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGeYIAxJBTTnXAif4RAp30AKCqFqf+NAFjxxNxYTSkPCJTC/WCIACguiXp
4rF3JBpuBiFTVERBlRB0xZY =6OEc
-----END PGP SIGNATURE-----

--vkogqOf2sHV7VnPd--


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Le #9784511
Franck Joncourt a écrit :

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.



Au moins ça a le mérite d'être clair : ta box ne sait pas traiter
correctement les réponses PASV. :-(

[...]
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.



Ça a même été prévu pour être compatible avec IPv6. :-)

et refaire mes manips car j'ai forcément loupé quelque chose.



Je ne vois pas quoi. Le suivi de connexion de Netfilter fait son boulot
correctement, le NAT de la box ne fait pas le sien. On voit bien que la
modification de l'adresse passive à la source par le serveur a ses
limite : le seul vrai bon endroit pour le faire et là où est fait le NAT.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Franck Joncourt
Le #9784211
--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 20, 2007 at 01:37:43AM +0200, Pascal Hambourg wrote:
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.




Et bien je n'ai vu aucune différence :(!

nf_conntrack_ftp loose=1 ports!.

J'ai pris la pécaution de décharger le module avant, et de le rec harger
avec les nouvelles options.

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.




Dans un premier temps, j'ai tenté de savoir si mon serveur vsftp
supportait cette option. Je n'ai pas trouvé de doc, donc je l'ai test é
directement avec telnet et la commande FEAT. Elle est mentionné dans la
liste donc c'est bon.
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.

Pour ceux qui veulent de plus amples informations sur FEAT :
http://www.ietf.org/rfc/rfc2389.txt

et sur EPSV :
http://www.ietf.org/rfc/rfc2428.txt

--
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGfQAixJBTTnXAif4RAiUeAJwJbuNjr+3npupPalhAxNw62FKtbwCgkUz+
UVxdsOpuB/Jy0Eoa//TbMt4 CkV
-----END PGP SIGNATURE-----

--W/nzBZO5zC0uMSeA--


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Le #9784061
Franck Joncourt a écrit :
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 :(!



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 commande qui les
supporte.

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.



Ç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...


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Franck Joncourt
Le #9784021
--jCrbxBqMcLqd4mOl
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 23, 2007 at 06:23:45PM +0200, Pascal Hambourg wrote:
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.



Pas de quoi.


[...]
>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...



J'ai l'habitude d'utiliser la commande ftp pour faire mes petites
affaires sur mon serveur, mais je cherchais une interface graphique pour
les utilisateurs un peu plus réticents à la console. Cela devrait se
trouver, je ne m'inquiète pas.
Pour les utilisateurs windows, et bien tant pis. J'ai déjà rà ©ussi à les
faire utiliser knoppix, alors ils pourront faire un petit effort et
passer sous Linux :p!

Pour ce qui est d'ignorer l'adresse ip présente dans la réponse à la
requête PASV, ce n'est pas ce que j'ai l'intention d'adopter. Comme tu
l'as mentionné dans un mail précédent, c'est bel et bien la commande
EPSV qu'il faut utiliser, puisse qu'elle existe.

Merci pour le coup de pouce.

--
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

--jCrbxBqMcLqd4mOl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGfWPixJBTTnXAif4RAqfAAKC4NntxqD2UmadYVsQ1wBFPZqknRgCfaxPy
PU9e3ptOB6aQBYnfwzdRwO8 ì7E
-----END PGP SIGNATURE-----

--jCrbxBqMcLqd4mOl--


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Publicité
Poster une réponse
Anonyme