J'ai un serveur sous Linux avec Proftpd installé hébergé en data center.
J'ai mis en place un accès FTP en mode passif sur ce serveur.
L'hôte du serveur FTP est l'adresse IP du serveur.
Je me connecte tout à fait sur la connexion FTP (de PC et de MAC).
L'upload et le download fonctionne très bien.
Par contre chez mon voisin, impossible d'avoir le listage du dossier initial. La connexion se passe bien lors de l'identification (logs proftpd) :
"USER XXXXX" 331 -
"PASS (hidden)" 230 -
"PWD" 257 -
"FEAT" 211 -
"REST 100" 350 -
"REST 0" 350 -
"PASV" 227 -
et là plus rien et timeout.
Si chez moin voisin j'essaie une connexion FTP en mode passif sur un autre serveur (OVH par exmple) : aucun problème tout marche bien. Filezilla avec le même paramétrage est utilisé.
Un autre de mes clients à le même problème.
Un autre n'a aucun problème.
Que se passe-t-il ?
Des idées ?
Résumé :
A la boite, chez moi et d'autres personnes aucun soucis pour uploader un fichier sur un serveur via FTP mode passif.
Par contre certaines autres personnes ont un timeout après le login au serveur. Ces mêmes personnes pouvant tout à fait bien uploader des fichiers en FTP mode passif sur d'autres serveurs.
Forum général.général Problème avec connexion FTP
4
fév.
2008
# Problème de port
Posté par Kerro . Évalué à 2.
En mode passif c'est le serveur qui décide quel port est utilisé pour le transfert des données, ce qui, en principe, fonctionne à tous les coups si le serveur est bien paramétré au niveau de son pare-feu.
Souvent le logiciel client fait un peu ce qui lui chante. Au vu de ton log ça à l'air de bien être du passif. Par contre il faudrait que tu regardes quel ports sont utilisés. Regarde dans le log de FileZila (partie haute de l'écran), tu y trouveras les numéros de ports. Compare avec les numéros de ports utilisés vers d'autres serveurs FTP passifs.
D'expérience, beaucoup de problèmes viennent du fait qu'on croit être dans un mode alors que le logiciel décide tout seul comme un grand d'utiliser l'autre mode.
# Une trace réseau ?
Posté par Steve Azriel . Évalué à 1.
A moins qu'il y ait une corrélation entre les différents clients (en échec, ou en succès comme par exemple, un regroupement par FAI ou par version OS), il serait peut-être intéressant de faire une petite trace réseau (wireshark ou tcpdump ^__^) de part et d'autre (client & serveur).
Est-ce que la commande "PASV" envoyée par l'un des clients en échec obtient-elle une réponse semblable (227 - Entering in Passive Mode (@IP, Port_Part1, Port_Part2) à celle d'un client OK ? En particulier, au niveau IP mais aussi numéro de port (conformité entre le range de IP+ports ouvert côté firewall et côté ProFTPD [entre autre, le paramètre PassivePorts] ?
Il y aurait à voir aussi du côté de l'utilisation ou non du(des) module(s) "ip_nat_ftp/ip_conntrack_ftp".
Sinon, la trace réseau reste un bon moyen de comprendre le comportement du client et de ses échanges avec le serveur surtout dans ce type de problématique.
Bon courage !
Cdlt,
[^] # Re: Une trace réseau ?
Posté par scoubi38 . Évalué à 1.
-----------------------------------------------------------------------
Etat : Connexion à 195.XXXXXXX ...
Etat : Connecté à 195.XXXXXXX. Attente du message d'accueil...
Réponse : 220 FTP Server ready.
Commande : USER ZZZZZZZ
Réponse : 331 Password required for ZZZZZZ.
Commande : PASS ******
Réponse : 230 User ZZZZZ logged in.
Commande : SYST
Réponse : 215 UNIX Type: L8
Commande : FEAT
Réponse : 211-Features:
Réponse : MDTM
Réponse : REST STREAM
Réponse : SIZE
Réponse : 211 End
Etat : Connecté
Etat : Récupération de la liste de répertoires...
Commande : PWD
Réponse : 257 "/" is current directory.
Commande : TYPE A
Réponse : 200 Type set to A
Commande : PASV
Réponse : 227 Entering Passive Mode (195.XXXXXXX,197,50).
Commande : LIST
Erreur : Le canal de transfert n'a pas pu être ouvert. Raison : Une tentative de connexion a échoué car le parti connecté n'a pas répondu convenablement au-delà d'une certaine durée ou une connexion établie a échoué car l'hôte de connexion n'a pas répondu.
Erreur : N'a pas pu récupérer la liste du répertoire
-----------------------------------------------------------------------
Au niveau de mon proftpd.conf, j'ai ligne :
PassivePorts 50000 55000
donc la connexion est bonne : 197*256+50=50482
Faut-il que le port (ici le 50482) soit ouvert au niveau du firewall du client ?
Pour ma part, voici ce que j'ai sur Filezilla lorsque je me connecte :
---------------------------------------------------------------------------
Commande : PASV
Réponse : 227 Entering Passive Mode (195,XXXXXXXXX,204,93).
Commande : LIST
Réponse : 150 Opening ASCII mode data connection for file list
Réponse : 226 Transfer complete.
--------------------------------------------------------------------------------
[^] # Re: Une trace réseau ?
Posté par Steve Azriel . Évalué à 1.
Merci pour ce retour d'information :-) !
[mode=blabla]
D'après les traces applicatives que tu donnes, le serveur ProFTPD ne semble pas faire pas de distinction par rapport aux clients potentiels (par exemple avec des ACLs au niveau des commandes disponibles ou autre).
En outre, un client en échec sur ton serveur FTP, ne l'est pas sur un autre serveur FTP (ovh?) dans un mode opératoire semblable (même application + même configuration de l'application [même mode de transfert passif]).
Côté serveur, a priori, il ne devrait pas y avoir de filtrage concernant ProFTPD (notamment par le fait que des clients différents arrivent à utiliser pleinement le service FTP).
Côté client, il semblerait (oui, c'est bien une hypothèse) bien que les flux sortant à destination de ton serveur (@IP=195.X.Y.Z) pour le range de ports définit [50000-55000] ne soit pas autorisé...
... mais à quel niveau (directement sur le poste client via son firewall personnel, sur le firewall au niveau de la sortie internet du client, ...)
[/mode=blabla]
En l'état, je te suggère, dans la mesure du possible, de réaliser une trace réseau, au plus proche de l'extrémité entrante d'internet du côté de ton serveur FTP.
Un telnet depuis le poste client vers ton serveur FTP sur un des ports du range [50000, 55000] devrait (encore une hypothèse, désolé !) au moins arriver jusqu'à l'entrée de ton réseau et sera traitée conformément à la politique de sécurité/filtrage (drop ou return reset ou autre).
Bon courage !
Cdlt,
[^] # Re: Une trace réseau ?
Posté par scoubi38 . Évalué à 1.
Voici les trames lorsque qqn se connecte et la connexion FTP foire (timeout après la commande LIST)
-------------------------------------------------------------------------------------
No. Time Source Destination Protocol Info
1 0.000000 XX.XX.XX.XX YY.YY.YY.YY TCP gxs-data-port > ftp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
2 0.000045 YY.YY.YY.YY XX.XX.XX.XX TCP ftp > gxs-data-port [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
3 0.138574 XX.XX.XX.XX YY.YY.YY.YY TCP gxs-data-port > ftp [ACK] Seq=1 Ack=1 Win=65535 Len=0
4 0.139603 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 220 FTP Server ready.
5 0.321382 XX.XX.XX.XX YY.YY.YY.YY FTP Request: USER ZZZZZZZ
6 0.321411 YY.YY.YY.YY XX.XX.XX.XX TCP ftp > gxs-data-port [ACK] Seq=24 Ack=21 Win=5840 Len=0
7 0.321891 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 331 Password required for ZZZZZZZZZZ.
8 0.461581 XX.XX.XX.XX YY.YY.YY.YY FTP Request: PASS azerty
9 0.472637 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 230 User ZZZZZZZZZZZZ logged in.
10 0.613901 XX.XX.XX.XX YY.YY.YY.YY FTP Request: SYST
11 0.614071 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 215 UNIX Type: L8
12 0.785961 XX.XX.XX.XX YY.YY.YY.YY FTP Request: FEAT
13 0.786095 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 211-Features:
14 0.786117 YY.YY.YY.YY XX.XX.XX.XX FTP Response: MDTM
15 0.935781 XX.XX.XX.XX YY.YY.YY.YY TCP gxs-data-port > ftp [ACK] Seq=46 Ack=142 Win=65394 Len=0
16 0.935796 YY.YY.YY.YY XX.XX.XX.XX FTP Response: REST STREAM
17 1.102095 XX.XX.XX.XX YY.YY.YY.YY FTP Request: PWD
18 1.102398 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 257 "/" is current directory.
19 1.250290 XX.XX.XX.XX YY.YY.YY.YY FTP Request: TYPE A
20 1.250426 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 200 Type set to A
21 1.409232 XX.XX.XX.XX YY.YY.YY.YY FTP Request: PASV
22 1.409605 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 227 Entering Passive Mode (YY,YY,YY,YY,2
23 1.552179 XX.XX.XX.XX YY.YY.YY.YY FTP Request: LIST
24 1.593084 YY.YY.YY.YY XX.XX.XX.XX TCP ftp > gxs-data-port [ACK] Seq=274 Ack=71 Win=5840 Len=0
25 52.132002 XX.XX.XX.XX YY.YY.YY.YY TCP gxs-data-port > ftp [RST, ACK] Seq=71 Ack=274 Win=0 Len=0
-------------------------------------------------------------------------------------
Et voici les trames quand tout fonctionne bien :
-------------------------------------------------------------------------------------
No. Time Source Destination Protocol Info
1 0.000000 XX.XX.XX.XX YY.YY.YY.YY TCP biolink-auth > ftp [SYN] Seq=0 Win=65535 Len=0 MSS=1452 WS=3 TSV=0 TSER=0
2 0.000035 YY.YY.YY.YY XX.XX.XX.XX TCP ftp > biolink-auth [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=2
3 0.053506 XX.XX.XX.XX YY.YY.YY.YY TCP biolink-auth > ftp [ACK] Seq=1 Ack=1 Win=372296 Len=0
4 0.054482 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 220 FTP Server ready.
5 0.109015 XX.XX.XX.XX YY.YY.YY.YY FTP Request: USER ZZZZZZZZZ
6 0.109044 YY.YY.YY.YY XX.XX.XX.XX TCP ftp > biolink-auth [ACK] Seq=24 Ack=21 Win=5840 Len=0
7 0.109501 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 331 Password required for ZZZZZZZZZZZZ.
8 0.163522 XX.XX.XX.XX YY.YY.YY.YY FTP Request: PASS azerty
9 0.174532 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 230 User dl-pge-client logged in.
10 0.228532 XX.XX.XX.XX YY.YY.YY.YY FTP Request: SYST
11 0.228695 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 215 UNIX Type: L8
12 0.282281 XX.XX.XX.XX YY.YY.YY.YY FTP Request: FEAT
13 0.282408 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 211-Features:
14 0.282430 YY.YY.YY.YY XX.XX.XX.XX FTP Response: MDTM
15 0.337011 XX.XX.XX.XX YY.YY.YY.YY TCP biolink-auth > ftp [ACK] Seq=46 Ack=142 Win=372152 Len=0
16 0.337025 YY.YY.YY.YY XX.XX.XX.XX FTP Response: REST STREAM
17 0.392871 XX.XX.XX.XX YY.YY.YY.YY FTP Request: PWD
18 0.393496 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 257 "/" is current directory.
19 0.448852 XX.XX.XX.XX YY.YY.YY.YY FTP Request: TYPE I
20 0.449109 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 200 Type set to I
21 0.502950 XX.XX.XX.XX YY.YY.YY.YY FTP Request: PASV
22 0.503364 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 227 Entering Passive Mode (YY,YY,YY,YY,2
23 0.560055 XX.XX.XX.XX YY.YY.YY.YY FTP Request: LIST
24 0.600810 YY.YY.YY.YY XX.XX.XX.XX TCP ftp > biolink-auth [ACK] Seq=273 Ack=71 Win=5840 Len=0
25 0.612740 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 150 Opening ASCII mode data connection for
26 0.668824 YY.YY.YY.YY XX.XX.XX.XX FTP Response: 226 Transfer complete.
27 0.722869 XX.XX.XX.XX YY.YY.YY.YY TCP biolink-auth > ftp [ACK] Seq=71 Ack=351 Win=371944 Len=0
-------------------------------------------------------------------------------------
Pour ma part cela ne m'éclaire pas plus...
[^] # Re: Une trace réseau ?
Posté par Steve Azriel . Évalué à 1.
Essayons de voir ce que nous avons là:
1) Lignes 1 à 3
Il y a le début de la connexion vers le serveur FTP (séquence SYN, SYN+ACK, ACK)
=> Les deux clients se connectent bien au serveur sans problème mais on le savait déjà ;-)
2) Lignes 4 à 24
Même dialogue pour les deux clients qui poursuivent l'avancement de la session FTP (authentification, message du jour, ...)
=> Jusqu'ici ça va ! :-)
NB: Le masquage des informations "sensibles" n'est pas complet ^__^ (cf Lignes 8+9 du client 2)
3) Lignes ABSENTES
Il manque la séquence TCP { SYN, SYN+ACK, ACK } pour l'ouverture de la connexion sur le port donné par le serveur ?!?
=> Cette séquence est équivalente à celle de départ (cf point n°1), sauf que la destination est l'adresse IP du serveur et un port dans l'intervalle [50000, 55000]
NB: Serait-ce du au fait que tu ais appliqué un filtre sur l'écoute réseau du type "port 21" ? Cela pourrait expliquer pourquoi on ne voit pas tous les échanges liés au protocole FTP Passif.
4.a) Ligne 25 du client 1
Le client aurait détecté un dépassement de timeout (env 50 secondes) lors de sa tentative de mise en relation passive avec le serveur FTP et initie une fin de connexion via le flag TCP ReSeT.
=> Je pense que le serveur a du lui répondre positivement.
4.b) Lignes 25 à 27 du client 2
Evénements d'informations échangés sur le canal de contrôle ouvert préalablement en 1 signalant aucune erreur particulière :-)
=> Comme tu l'as si bien résumé, nous ne voyons pas les raisons de l'échec du client 1.
Pourrais tu lever le doute sur ma question soulevée au point n°3 concernant un éventuel filtre type "port 21" ?
Si tel est le cas, il faudrait recommencer la trace en utilisant un filtre plus adapté pour ce type de protocole qu'est FTP, comme "host X.X.X.X" où X.X.X.X est l'adresse IP du client.
Il ne sera pas nécessaire d'avoir les messages déjà analysés mais bien regarder ce qui se passe à partir de l'entrée en mode Passif (point n°3).
Bon courage !
Cdlt,
PS: Dernière petite question, la trace a lieu à quel niveau ? Sur le serveur lui-même ?
[^] # Re: Une trace réseau ?
Posté par scoubi38 . Évalué à 1.
Client 1 (tout fonctionne bien) :
---------------------------------------------------------------------------------------
No. Time Source Destination Protocol Info
25 36.586701 yy.yy.yy.yy xx.xx.xx.xx FTP Response: 227 Entering Passive Mode (yy,yy,yy,yy,2
Frame 25 (105 bytes on wire, 96 bytes captured)
Internet Protocol, Src: yy.yy.yy.yy (yy.yy.yy.yy), Dst: xx.xx.xx.xx (xx.xx.xx.xx)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: must-backplane (3515), Seq: 222, Ack: 65, Len: 51
File Transfer Protocol (FTP)
No. Time Source Destination Protocol Info
26 36.642267 xx.xx.xx.xx yy.yy.yy.yy TCP smartcard-port > 54318 [SYN] Seq=0 Win=65535 Len=0 MSS=1422 WS=3 TSV=0 TSER=0
Frame 26 (78 bytes on wire, 78 bytes captured)
Internet Protocol, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: yy.yy.yy.yy (yy.yy.yy.yy)
Transmission Control Protocol, Src Port: smartcard-port (3516), Dst Port: 54318 (54318), Seq: 0, Len: 0
No. Time Source Destination Protocol Info
27 36.642287 yy.yy.yy.yy xx.xx.xx.xx TCP 54318 > smartcard-port [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=2
Frame 27 (66 bytes on wire, 66 bytes captured)
Internet Protocol, Src: yy.yy.yy.yy (yy.yy.yy.yy), Dst: xx.xx.xx.xx (xx.xx.xx.xx)
Transmission Control Protocol, Src Port: 54318 (54318), Dst Port: smartcard-port (3516), Seq: 0, Ack: 1, Len: 0
No. Time Source Destination Protocol Info
28 36.642933 xx.xx.xx.xx yy.yy.yy.yy FTP Request: LIST
Frame 28 (60 bytes on wire, 60 bytes captured)
Internet Protocol, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: yy.yy.yy.yy (yy.yy.yy.yy)
Transmission Control Protocol, Src Port: must-backplane (3515), Dst Port: ftp (21), Seq: 65, Ack: 273, Len: 6
File Transfer Protocol (FTP)
No. Time Source Destination Protocol Info
29 36.682779 yy.yy.yy.yy xx.xx.xx.xx TCP ftp > must-backplane [ACK] Seq=273 Ack=71 Win=5840 Len=0
Frame 29 (54 bytes on wire, 54 bytes captured)
Internet Protocol, Src: yy.yy.yy.yy (yy.yy.yy.yy), Dst: xx.xx.xx.xx (xx.xx.xx.xx)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: must-backplane (3515), Seq: 273, Ack: 71, Len: 0
No. Time Source Destination Protocol Info
30 36.695941 xx.xx.xx.xx yy.yy.yy.yy TCP smartcard-port > 54318 [ACK] Seq=1 Ack=1 Win=372296 Len=0
Frame 30 (60 bytes on wire, 60 bytes captured)
Internet Protocol, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: yy.yy.yy.yy (yy.yy.yy.yy)
Transmission Control Protocol, Src Port: smartcard-port (3516), Dst Port: 54318 (54318), Seq: 1, Ack: 1, Len: 0
No. Time Source Destination Protocol Info
31 36.696020 yy.yy.yy.yy xx.xx.xx.xx FTP Response: 150 Opening ASCII mode data connection for
Frame 31 (108 bytes on wire, 96 bytes captured)
Internet Protocol, Src: yy.yy.yy.yy (yy.yy.yy.yy), Dst: xx.xx.xx.xx (xx.xx.xx.xx)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: must-backplane (3515), Seq: 273, Ack: 71, Len: 54
File Transfer Protocol (FTP)
No. Time Source Destination Protocol Info
32 36.697031 yy.yy.yy.yy xx.xx.xx.xx TCP 54318 > smartcard-port [PSH, ACK] Seq=1 Ack=1 Win=5840 Len=62
Frame 32 (116 bytes on wire, 96 bytes captured)
Internet Protocol, Src: yy.yy.yy.yy (yy.yy.yy.yy), Dst: xx.xx.xx.xx (xx.xx.xx.xx)
Transmission Control Protocol, Src Port: 54318 (54318), Dst Port: smartcard-port (3516), Seq: 1, Ack: 1, Len: 62
Data (42 bytes)
0000 64 72 77 78 72 77 78 72 2d 78 20 20 20 32 20 77 drwxrwxr-x 2 w
0010 77 77 64 61 74 61 20 20 77 77 77 64 61 74 61 20 wwdata wwwdata
0020 20 20 20 20 20 34 30 39 36 20 4096
No. Time Source Destination Protocol Info
33 36.697074 yy.yy.yy.yy xx.xx.xx.xx TCP 54318 > smartcard-port [FIN, ACK] Seq=63 Ack=1 Win=5840 Len=0
Frame 33 (54 bytes on wire, 54 bytes captured)
Internet Protocol, Src: yy.yy.yy.yy (yy.yy.yy.yy), Dst: xx.xx.xx.xx (xx.xx.xx.xx)
Transmission Control Protocol, Src Port: 54318 (54318), Dst Port: smartcard-port (3516), Seq: 63, Ack: 1, Len: 0
No. Time Source Destination Protocol Info
34 36.750449 xx.xx.xx.xx yy.yy.yy.yy TCP smartcard-port > 54318 [ACK] Seq=1 Ack=64 Win=372232 Len=0
Frame 34 (60 bytes on wire, 60 bytes captured)
Internet Protocol, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: yy.yy.yy.yy (yy.yy.yy.yy)
Transmission Control Protocol, Src Port: smartcard-port (3516), Dst Port: 54318 (54318), Seq: 1, Ack: 64, Len: 0
No. Time Source Destination Protocol Info
35 36.751283 xx.xx.xx.xx yy.yy.yy.yy TCP smartcard-port > 54318 [FIN, ACK] Seq=1 Ack=64 Win=372232 Len=0
-----------------------------------------------------------------------------------------
Client 2 (problème) :
------------------------------------------------------------------------------------------
No. Time Source Destination Protocol Info
21 1.357257 xx.xx.xx.xx yy.yy.yy.yy FTP Response: 200 Type set to A
Frame 21 (73 bytes on wire, 73 bytes captured)
Internet Protocol, Src: yy.yy.yy.yy (yy.yy.yy.yy), Dst: xx.xx.xx.xx (xx.xx.xx.xx)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: serialgateway (1243), Seq: 203, Ack: 59, Len: 19
File Transfer Protocol (FTP)
No. Time Source Destination Protocol Info
22 1.512068 xx.xx.xx.xx yy.yy.yy.yy FTP Request: PASV
Frame 22 (60 bytes on wire, 60 bytes captured)
Internet Protocol, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: yy.yy.yy.yy (yy.yy.yy.yy)
Transmission Control Protocol, Src Port: serialgateway (1243), Dst Port: ftp (21), Seq: 59, Ack: 222, Len: 6
File Transfer Protocol (FTP)
No. Time Source Destination Protocol Info
23 1.512439 yy.yy.yy.yy xx.xx.xx.xx FTP Response: 227 Entering Passive Mode (195,200,78,75,2
Frame 23 (106 bytes on wire, 96 bytes captured)
Internet Protocol, Src: yy.yy.yy.yy (yy.yy.yy.yy), Dst: xx.xx.xx.xx (xx.xx.xx.xx)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: serialgateway (1243), Seq: 222, Ack: 65, Len: 52
File Transfer Protocol (FTP)
No. Time Source Destination Protocol Info
24 1.668510 xx.xx.xx.xx yy.yy.yy.yy FTP Request: LIST
Frame 24 (60 bytes on wire, 60 bytes captured)
Internet Protocol, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: yy.yy.yy.yy (yy.yy.yy.yy)
Transmission Control Protocol, Src Port: serialgateway (1243), Dst Port: ftp (21), Seq: 65, Ack: 274, Len: 6
File Transfer Protocol (FTP)
No. Time Source Destination Protocol Info
25 1.708075 yy.yy.yy.yy xx.xx.xx.xx TCP ftp > serialgateway [ACK] Seq=274 Ack=71 Win=5840 Len=0
Frame 25 (54 bytes on wire, 54 bytes captured)
Internet Protocol, Src: yy.yy.yy.yy (yy.yy.yy.yy), Dst: xx.xx.xx.xx (xx.xx.xx.xx)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: serialgateway (1243), Seq: 274, Ack: 71, Len: 0
No. Time Source Destination Protocol Info
26 53.006899 xx.xx.xx.xx yy.yy.yy.yy TCP serialgateway > ftp [RST, ACK] Seq=71 Ack=274 Win=0 Len=0
Frame 26 (60 bytes on wire, 60 bytes captured)
Internet Protocol, Src: xx.xx.xx.xx (xx.xx.xx.xx), Dst: yy.yy.yy.yy (yy.yy.yy.yy)
Transmission Control Protocol, Src Port: serialgateway (1243), Dst Port: ftp (21), Seq: 71, Ack: 274, Len: 0
------------------------------------------------------------------------------------------
Il n'y a effectivement aucune trame échangée en dehors du port 21 côté serveur.
Après la réponse du serveur "Entering Passive Mode", le client 1 envoie la trame [SYN] sur le port indiqué (ici 54318). Pour le client 2, cette trame n'est pas envoyée.
Le port n'est donc pas ouvert en "sortie" au niveau du firewall chez le client 2 et c'est pour cette raison que la requête n'est pas envoyée au serveur ?
[^] # Re: Une trace réseau ?
Posté par Steve Azriel . Évalué à 1.
Comme l'a dit Kerro (en première reponse, ou plus bas ^__^), ça ressemble bien à un filtrage de port côté client !
A toi de voir ce qui t'arrange le mieux parmi les 2 propositions de Kerro :-)
Bon courage !
Cdlt,
[^] # Port interdit
Posté par Kerro . Évalué à 2.
Ton client a un interval de ports interdits.
Pour le savoir, fais un netcat depuis chez ton client vers un numéro de port dans cet interval, ça ne doit rien donner. Alors que depuis un autre lieu ça fonctionne.
Si tu n'as pas le netcat facile, tente avec un serveur compréhensif :
http://google.fr:50000 doit échouer au bout de plus 5 secondes car leur serveur ne répond pas sur les mauvais ports.
http://www.mon-ip.fr:50000/ doit échouer au bout de 1 ou 2 secondes car ce serveur répond sur les mauvais ports.
Remplace 50000 par une valeur dans l'interval de ton serveur FTP.
Chez ton client, si http://www.mon-ip.fr:50000/ met plus de 1 à 2 secondes pour échouer, c'est qu'il y a un filtrage de ports.
Il reste alors à trouver une autre plage de port pour ton serveur FTP. Ou à trouver pourquoi/comment est filtré cette plage.
[^] # Re: Port interdit
Posté par scoubi38 . Évalué à 1.
host : 74.200.67.71
username : demo@javaatwork.com
passwd : ftpdemo
La connexion s'est magnifiquement bien passée, connexion en mode passif sur le port serveur 44424.
J'ai fait des tests de connexion et les ports utilisés varient de 31000 à 43000.
Du coup j'ai modifié mon fichier proftpd.conf en mettant :
PassivePorts 30000 48000
J'ai redemandé à mon client de se connecter sur mon serveur et... ça foire toujours. La connexion s'est faite sur le port 35355 (dixit Filezilla).
[^] # Re: Port interdit
Posté par Steve Azriel . Évalué à 1.
Malheureusement, sans avoir la main sur le réseau de ton client, tu ne pourras que tester des cas particuliers qui fonctionnent chez certains et pas chez d'autres :( !
Ton objectif étant d'offrir un service FTP Passif à un ensemble de clients.
A priori, de ton côté, tu as fait le nécessaire (routage, flux, service).
=> Si cela est possible, il faudrait peut-être "formaliser" ton service avec, pour chaque client (en échec ou non), une demande explicite d'ouverture de flux de type FTP (Passif) à destination de ton serveur.
Après, tu réalises une petite "recette" telle que celle que nous (tu) avons(as) faite et qui a montré que le client en échec [voir ci-dessus]:
1) accède bien à ton serveur FTP pour le canal de controle (port 21)
2) échoue dans l'établissement du canal data sur un port dans le range [50000, 55000].
Voili, voilou.
Sur ce, bon courage !
Cdlt,
[^] # Re: Port interdit
Posté par scoubi38 . Évalué à 1.
[^] # Re: Port interdit
Posté par Steve Azriel . Évalué à 1.
Le post de Kerro [https://linuxfr.org/comments/901668.html#901668] te donne déjà des tests "prêts à l'emploi"...
... quel est le sens de ta demande ?
De mon côté, j'ai eu une idée pour toi et tes clients en échec: un accès Web à ton serveur FTP !
A priori, tu devrais rencontrer moins de problème dans la mesure où les flux Web (http, https) sont plus courants que les flux FTP :-)
Par exemple:
¤ net2ftp [http://www.net2ftp.com]
¤ web-ftp [http://web-ftp.sf.net/]
En espérant que tu puisses rapidement dire:
scoubi38: Quiescence reached :-)
Bon courage !
Cdlt,
# Happy end ?
Posté par Kerro . Évalué à 1.
[^] # Re: Happy end ?
Posté par scoubi38 . Évalué à 1.
Je ne sais toujours pas où cela bloque.
Après en avoir parler autour de moi, personne ne voit où se situe le blocage.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.