Pas de download FTP au-delà de 1380 octets
fb.orpheon
Messages postés
11
Statut
Membre
-
fb.orpheon -
fb.orpheon -
Bonjour,
Je ne suis pas informaticien de base mais avec le boulot j'ai dû me plonger dans les réseaux.
J'ai à faire à un bug particulièrement étonnant et dont je n'ai pas trouvé la solution malgré moultes recherches et autres appels à l'aide du côté des divers supports techniques.
Pour tout de suite couper court à la réponse la plus vue de tous les temps dans les forums FTP : le problème est le même en passif ou en actif !
J'utilise un Windows 7 - 64 bit, avec divers clients FTP (FileZilla 3.5.3, service ftp Microsoft en ligne de commande, LeechFTP, BitKinex...), le problème est toujours le même.
Le client FTP est derrière un firewall/routeur/NATeur, idem pour le serveur FTP :
client FTP <-> NAT router <-> Firewall <-> Internet <-> Firewall <-> NAT router <-> Serveur FTP (NAS synology)
La redirection des ports est correcte, j'en veux pour preuve les deux expériences suivantes :
- avec un serveur FTP public (directement dans l'Internet), pas de problème de download (montrant que le firewall devant le client FTP est OK)
- le gars du support Synology a réussi à downloader tous les fichiers qu'il voulait (montrant que le firewall devant le serveur FTP est OK)
La curiosité est la suivante : je peux uploader tous les fichiers que je veux. Et je peux downloader tous les fichiers TANT QU'ILS ONT UNE TAILLE INFERIEURE à 1380 octets. Véridique. Le symptôme du transfert échoué est le suivant : "150 Open Binary mode..." et puis... plus rien. Ça ne démarre jamais.
J'ai fait l'expérience avec des fichiers .txt (qui m'ont permis de trouver à l'octet près la limite 1380 octets), .jpg, .htm, etc.
C'est extrêmement curieux. Pour rassurer tout le monde, je précise que les firewalls internes du NAS Synology et des ordinateurs supportant le client FTP sont désactivés.
Les tests ne permettent pas de discriminer un des maillons de la chaîne, ça ressemble à une sorte d'incompatibilité générale lorsque le client et le serveur sont derrière un NAT router. Mais pas pour les fichiers de moins de 1380 octets...
En toute dernière idée, je me suis dit que le firewall côté client pouvait éventuellement laisser les premiers paquets passer pour les "analyser" ou autre, si vous voyez ce que je veux dire, ce qui fait que la petite taille des fichiers qui passent leur permet d'être reçus entièrement avant que la porte ne se ferme. Ca me semblerait bizarre quand même, d'autant que je le rappelle, lorsque le serveur est public, il n'y a aucun problème.
Je vous remercie par avance de votre aide.
Florian
P.S : il semblerait que finalement, malgré tout ce qu'on nous dit, c'est la taille qui compte
Je ne suis pas informaticien de base mais avec le boulot j'ai dû me plonger dans les réseaux.
J'ai à faire à un bug particulièrement étonnant et dont je n'ai pas trouvé la solution malgré moultes recherches et autres appels à l'aide du côté des divers supports techniques.
Pour tout de suite couper court à la réponse la plus vue de tous les temps dans les forums FTP : le problème est le même en passif ou en actif !
J'utilise un Windows 7 - 64 bit, avec divers clients FTP (FileZilla 3.5.3, service ftp Microsoft en ligne de commande, LeechFTP, BitKinex...), le problème est toujours le même.
Le client FTP est derrière un firewall/routeur/NATeur, idem pour le serveur FTP :
client FTP <-> NAT router <-> Firewall <-> Internet <-> Firewall <-> NAT router <-> Serveur FTP (NAS synology)
La redirection des ports est correcte, j'en veux pour preuve les deux expériences suivantes :
- avec un serveur FTP public (directement dans l'Internet), pas de problème de download (montrant que le firewall devant le client FTP est OK)
- le gars du support Synology a réussi à downloader tous les fichiers qu'il voulait (montrant que le firewall devant le serveur FTP est OK)
La curiosité est la suivante : je peux uploader tous les fichiers que je veux. Et je peux downloader tous les fichiers TANT QU'ILS ONT UNE TAILLE INFERIEURE à 1380 octets. Véridique. Le symptôme du transfert échoué est le suivant : "150 Open Binary mode..." et puis... plus rien. Ça ne démarre jamais.
J'ai fait l'expérience avec des fichiers .txt (qui m'ont permis de trouver à l'octet près la limite 1380 octets), .jpg, .htm, etc.
C'est extrêmement curieux. Pour rassurer tout le monde, je précise que les firewalls internes du NAS Synology et des ordinateurs supportant le client FTP sont désactivés.
Les tests ne permettent pas de discriminer un des maillons de la chaîne, ça ressemble à une sorte d'incompatibilité générale lorsque le client et le serveur sont derrière un NAT router. Mais pas pour les fichiers de moins de 1380 octets...
En toute dernière idée, je me suis dit que le firewall côté client pouvait éventuellement laisser les premiers paquets passer pour les "analyser" ou autre, si vous voyez ce que je veux dire, ce qui fait que la petite taille des fichiers qui passent leur permet d'être reçus entièrement avant que la porte ne se ferme. Ca me semblerait bizarre quand même, d'autant que je le rappelle, lorsque le serveur est public, il n'y a aucun problème.
Je vous remercie par avance de votre aide.
Florian
P.S : il semblerait que finalement, malgré tout ce qu'on nous dit, c'est la taille qui compte
A voir également:
- Pas de download FTP au-delà de 1380 octets
- Télécharger music mp3 gratuit download pc - Télécharger - Conversion & Extraction
- Microsoft store download - Guide
- Canva download - Télécharger - Divers Photo & Graphisme
- Word 2013 free download - Télécharger - Traitement de texte
- Direct download - Accueil - Outils
9 réponses
Merci pour la réponse rapide.
Oui cela vaut pour d'autres machines (avec des OS différents d'ailleurs, Windows antérieurs - vista et XP - et même un Fedora que j'avais en backup).
Oui cela vaut pour d'autres machines (avec des OS différents d'ailleurs, Windows antérieurs - vista et XP - et même un Fedora que j'avais en backup).
Serait-il possible de créer une règle express sur le FW côté serveur ?
- Source : IP du serveur FTP
- Destination : IP du client
- Any vers Any
- Source : IP du serveur FTP
- Destination : IP du client
- Any vers Any
C'est déjà le cas. La sortie du serveur vers l'extérieur est autorisée tous azimuts, seules les entrées sont réglementées. (les connexions FTP depuis l'extérieur arrivant sur le port 21 sont natées vers le serveur FTP)
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Je vois peut-être le filtrage des paquets sortant du FTP ?
Ca serait intéressant d'analyser les logs du FW et le serveur FTP.
Par curiosité, quel est l'OS et le logiciel FTP du serveur ?
La limite des 1380 octets me laisse perplexe.
Ca serait intéressant d'analyser les logs du FW et le serveur FTP.
Par curiosité, quel est l'OS et le logiciel FTP du serveur ?
La limite des 1380 octets me laisse perplexe.
Le serveur est un NAS Synology reposant sur un Linux, mais je ne sais pas quelle est la distribution. Je n'ai aucun nom à disposition. L'interface de gestion du NAS est propre à Synology et je serais bien incapable d'aller "fouiner" dedans.
Le logiciel FTP du serveur est celui inclus dans DSM 4.0, le logiciel de gestion du NAS. Il est simplement nommé "FTP" dans le Panneau de configuration.
En ce qui concerne les logs côté serveur, je pourrais dans le meilleur des cas coller un sniffeur de paquets mais cette manip ne sera pas faite tout de suite, j'ai besoin de l'aide du collègue qui a les clés du FW. Oui au fait je précise que je n'ai pas forcément accès à tout de manière simple et que certains points peuvent demander un peu de temps à vérifier. En tout cas merci pour ton intérêt.
Le logiciel FTP du serveur est celui inclus dans DSM 4.0, le logiciel de gestion du NAS. Il est simplement nommé "FTP" dans le Panneau de configuration.
En ce qui concerne les logs côté serveur, je pourrais dans le meilleur des cas coller un sniffeur de paquets mais cette manip ne sera pas faite tout de suite, j'ai besoin de l'aide du collègue qui a les clés du FW. Oui au fait je précise que je n'ai pas forcément accès à tout de manière simple et que certains points peuvent demander un peu de temps à vérifier. En tout cas merci pour ton intérêt.
De rien, ça m'intéresse beaucoup à cette bizarrerie.
Depuis 2 mois, le FW de mon entreprise a des comportements aléatoires concernant les sites en SFTP, mon provider a changé des routeurs entretemps.
D'ailleurs, je travaillais avec le produit Checkpoint NGX, on avait le système SmartDefense qui filtrait les en-têtes des fichiers téléchargés à la hauteur de 1024 octets ( paramétrable ). D'où mes questions ci-dessus ;-)
Blague à part, le MTU est à combien sur ta ligne internet ?
Depuis 2 mois, le FW de mon entreprise a des comportements aléatoires concernant les sites en SFTP, mon provider a changé des routeurs entretemps.
D'ailleurs, je travaillais avec le produit Checkpoint NGX, on avait le système SmartDefense qui filtrait les en-têtes des fichiers téléchargés à la hauteur de 1024 octets ( paramétrable ). D'où mes questions ci-dessus ;-)
Blague à part, le MTU est à combien sur ta ligne internet ?
Le MTU! Voilà la réponse!
Je l'ai modifié sur mon poste local en créant une clé de registre. En le mettant à 1000 (à mon avis, quelque soit la valeur tant qu'elle est inférieure à ma limite de 1380 octets), ça fonctionne désormais.
Je n'ai pas encore la vraie explication, je continue d'enquêter pour découvrir d'où ça vient parce que là j'ai juste "soigné les symptômes".
Je note simplement pour l'instant que le MTU du firewall côté serveur, en "out", donc vers Internet, est à 1420 (car à 1500 l'accès à Internet était impossible).
Mille fois merci pour avoir évoquer l'idée du MTU, un concept qui m'était totalement étranger en me levant ce matin.
Je l'ai modifié sur mon poste local en créant une clé de registre. En le mettant à 1000 (à mon avis, quelque soit la valeur tant qu'elle est inférieure à ma limite de 1380 octets), ça fonctionne désormais.
Je n'ai pas encore la vraie explication, je continue d'enquêter pour découvrir d'où ça vient parce que là j'ai juste "soigné les symptômes".
Je note simplement pour l'instant que le MTU du firewall côté serveur, en "out", donc vers Internet, est à 1420 (car à 1500 l'accès à Internet était impossible).
Mille fois merci pour avoir évoquer l'idée du MTU, un concept qui m'était totalement étranger en me levant ce matin.
Salut,
étonnant .
tu parles bien de connexion IPV4, pas IPV6 ?
en ipv4 les routeurs s'adaptent à la MTU, sauf si le flag don't fragment est monté sur les paquets.
il faudrait faire une capture wireshark pour voir si c'est un défaut du stack ip windows ou autre chose.
https://fr.wikipedia.org/wiki/Maximum_transmission_unit#Exemple_de_valeur_de_la_MTU_selon_le_type_de_r.C3.A9seau
d'autant plus que quand tu la règles sur ton PC client, tu ne la règle que pour les paquets émis, par pour ceux reçus or tu as le problème en download
par contre tu pourrais vérifier que ton routeur ou ton firewall ou ton FAI ne bloque pas ICMP au cas où le mécanisme mtu path discovery serait mis en oeuvre par le NAS.
étonnant .
tu parles bien de connexion IPV4, pas IPV6 ?
en ipv4 les routeurs s'adaptent à la MTU, sauf si le flag don't fragment est monté sur les paquets.
il faudrait faire une capture wireshark pour voir si c'est un défaut du stack ip windows ou autre chose.
https://fr.wikipedia.org/wiki/Maximum_transmission_unit#Exemple_de_valeur_de_la_MTU_selon_le_type_de_r.C3.A9seau
d'autant plus que quand tu la règles sur ton PC client, tu ne la règle que pour les paquets émis, par pour ceux reçus or tu as le problème en download
par contre tu pourrais vérifier que ton routeur ou ton firewall ou ton FAI ne bloque pas ICMP au cas où le mécanisme mtu path discovery serait mis en oeuvre par le NAS.
Salut.
Merci brupala, mais là on commence à atteindre les limites de mes capacités :) !
Alors je vais essayer de reprendre point par point:
- c'est bien du IPv4, et je confirme bien que ça s'est mis à fonctionner après modification du MTU côté client
- pour le sniffage de paquets avec Wireshark, je promets rien je vais voir ce que je peux faire
- je suspecte mon FAI d'avoir une infrastructure anormale entre Internet et le firewall (le serveur étant en datacenter... qui sait vraiment ce qu'il s'y passe franchement... ils peuvent encapsuler tout et n'importe quoi)
- il ne me semble pas que le firewall/routeur bloque ICMP
Merci brupala, mais là on commence à atteindre les limites de mes capacités :) !
Alors je vais essayer de reprendre point par point:
- c'est bien du IPv4, et je confirme bien que ça s'est mis à fonctionner après modification du MTU côté client
- pour le sniffage de paquets avec Wireshark, je promets rien je vais voir ce que je peux faire
- je suspecte mon FAI d'avoir une infrastructure anormale entre Internet et le firewall (le serveur étant en datacenter... qui sait vraiment ce qu'il s'y passe franchement... ils peuvent encapsuler tout et n'importe quoi)
- il ne me semble pas que le firewall/routeur bloque ICMP
Hey,
Je viens de lire cet article , intéressant sur MTU & PPoE.
http://irp.nain-t.net/doku.php/140pppoe:070_mtu_mss_etc
Je viens de lire cet article , intéressant sur MTU & PPoE.
http://irp.nain-t.net/doku.php/140pppoe:070_mtu_mss_etc
