Résolution d’une Erreur FTP: 426 Failure Reading Network Stream

Introduction

L’erreur « 426 Failure reading network stream » est une erreur courante lors du transfert de fichiers via FTP, surtout lorsqu’une connexion sécurisée SSL/TLS est impliquée. Ce problème est souvent rencontré dans les environnements où les transferts de fichiers sont critiques, comme les échanges de données entre des systèmes de gestion et des serveurs FTP.

Dans cet article, je vais partager un mode opératoire pour le dépannage et la résolution de cette erreur en fournissant des détails techniques sur les étapes entreprises, les outils utilisés, ainsi que le mode opératoire des tests.

Contexte

Un transfert de fichier depuis un système vers un serveur FTP a échoué avec l’erreur suivante :

426 Failure reading network stream

Analyse et Diagnostic

Étape 1 : Utilisation de tcpdump

Pour diagnostiquer le problème, des captures réseau ont été effectuées à l’aide de l’outil tcpdump sur le client et le serveur FTP.

Commandes utilisées :

Sur le client :

tcpdump -i any dst host 192.168.1.1

Sur le serveur FTP :

tcpdump -i any src host 192.168.1.192

Observation des captures :

Les captures ont révélé plusieurs étapes de la connexion FTP sécurisée (FTPS) :

1. Connexion et Authentification :
   • Le client se connecte avec succès au serveur et s’authentifie en utilisant le protocole TLSv1.3, garantissant une connexion sécurisée.
2. Tentative de Téléchargement Échouée :
   • Le client tente de récupérer un fichier mais reçoit une erreur 550 Failed to open file. Cela indique que le fichier demandé n’a pas pu être ouvert ou trouvé sur le serveur.
3. Tentative d’Envoi avec Erreur de Lecture :
   • Le client change de répertoire et tente d’envoyer un fichier. Le serveur répond initialement avec 150 Ok to send data, indiquant qu’il est prêt à recevoir le fichier.
   • Cependant, la transmission est interrompue, aboutissant à l’erreur 426 Failure reading network stream. Cela signifie qu’il y a eu un problème avec la lecture du flux réseau durant le transfert du fichier, ce qui a conduit à l’interruption de l’envoi.
4. ICMP Host Unreachable :
   • Les trames tcpdump montrent des messages ICMP host unreachable, suggérant que des restrictions réseau ou des règles de pare-feu pourraient interférer avec la connexion.
   • Exemple de trame :09:49:45.070927 IP srv.test.fr > 192.168.1.1: ICMP host srv.test.fr unreachable - admin prohibited, length 48

Étape 2 : Identification de la cause

Un problème a été identifié avec la gestion de TLS 1.3 par le client FTP (lftp). Il a été découvert que le client FTP fermait prématurément la connexion TCP, déclenchant des paquets RST au lieu de paquets FIN appropriés.

Diagnostic avec lftp :

Pour confirmer le problème, un test supplémentaire a été effectué en utilisant lftp avec des paramètres de forçage de SSL/TLS :

Commande de test :

lftp -u user,xxxxxx -e "set ftp:ssl-force true; cd /user/; put fichier_bidon_5Mo.csv; bye;" ftps://ftp.test.fr

Résultat :

Interrompu
Interrompu

Les logs de tcpdump ont montré des messages ICMP host unreachable similaires à ceux observés précédemment :

10:41:34.155351 IP 192.168.1.192 > ftp.test.fr: ICMP host 192.168.1.192 unreachable - admin prohibited, length 48

Cette observation a renforcé l’hypothèse que le problème était lié à la gestion de TLS 1.3 par le client FTP.

Résolutions potentielles

Option 1 : Désactivation de TLS 1.3 sur le serveur

En désactivant TLS 1.3 sur le serveur FTP (vsftpd), le problème ne se reproduit plus.

Modification du fichier de configuration de vsftpd :

ssl_tlsv1_3=NO

Option 2 : Forcer TLS 1.2 sur le client FTP

Si la modification côté serveur n’est pas souhaitable, il est également possible de forcer l’utilisation de TLS 1.2 sur le client FTP.

Tests et Validation

Test avec lftp :

lftp -u user,xxxxxx -e "set ftp:ssl-force true; set ftp:ssl-protect-data true; cd /user/; put fichier_bidon_5Mo.csv; bye;" ftps://ftp.test.fr

Le transfert a été testé avec succès après la désactivation de TLS 1.3. Un code de retour 200 a été observé, indiquant un transfert réussi.

Test avec Fiddler :

Pour valider la résolution, des tests ont été effectués avec Fiddler, un outil de capture de trafic HTTP et HTTPS, pour simuler les transferts FTP et vérifier la stabilité de la connexion.

Mode Opératoire avec Fiddler :

1. Configuration de Fiddler :
   • Installer Fiddler sur un poste de travail.
   • Configurer Fiddler pour intercepter le trafic HTTPS en activant le déchiffrement SSL.
2. Configuration de la Requête :
   • Utiliser les paramètres suivants dans Fiddler pour simuler la requête vers le serveur en charge du transfert FTP
     User-Agent: Fiddler
Host: serveur.test.fr:6543
Content-Type: application/json
     Content-Length: 607935
3. Exécution de la Requête :
   • Préparer un fichier de test (par exemple, fichier_bidon_5Mo.csv).
   • Configurer Fiddler pour envoyer une requête POST au serveur avec le fichier de test.
4. Observation des Résultats :
   • Vérifier les réponses du serveur dans Fiddler.
   • S’assurer que le code de retour est 200 OK, indiquant que le transfert est réussi.

Conclusion

L’erreur « 426 Failure reading network stream » a été résolue en ajustant la configuration TLS sur le serveur FTP, une solution qui a permis de surmonter un bug connu du client FTP avec TLS 1.3. Cette expérience souligne l’intérêt des diagnostics réseaux détaillés et de la compréhension des protocoles de sécurité dans le dépannage des problèmes de transfert de fichiers.

Références

1. Documentation de vsftpd : https://security.appspot.com/vsftpd.html
2. https://github.com/curl/curl/issues/6149
3. https://github.com/curl/curl/issues/13556
4. Lftp Man Page : https://lftp.yar.ru/lftp-man.html
5. RFC 4217 – Securing FTP with TLS : https://tools.ietf.org/html/rfc4217