La connexion FTP fonctionne, mais le listing des dossiers bloque : pourquoi

Le nom d’utilisateur fonctionne, le mot de passe fonctionne, et le client dit qu’il est connecté. Puis il attend indéfiniment un listing de dossier, ou le premier transfert de fichier, et rien dans les identifiants ne l’explique. FTP ouvre une seconde connexion pour chaque listing et chaque fichier, et c’est cette seconde connexion qui échoue. La connexion ne prouve qu’une chose : la première conversation fonctionne.

Faites les vérifications dans l’ordre. Chacune écarte une couche différente, donc arrêtez-vous à la première qui produit une anomalie.

Séparez d’abord les deux connexions

Une connexion de contrôle transporte les commandes et les réponses sur le port d’écoute du serveur. Une connexion de données transporte le listing du répertoire ou le corps du fichier, et en mode passif le serveur choisit son point de terminaison et l’annonce dans la réponse PASV ou EPSV. Autoriser le port 21 ne dit rien sur l’accessibilité du port de données, et c’est exactement pourquoi une connexion réussit alors que chaque listing expire. Le guide de WinSCP sur les modes FTP expose cette séparation et ses exigences réseau.

Si le client se trouve derrière le VPN, le chemin de données traverse le même tunnel, mais pas nécessairement la même stratégie.

Lisez l’adresse dans la réponse PASV

Lancez un client détaillé et lisez la réponse au lieu de deviner. curl -v ftp://user@host/ affiche la ligne PASV avec l’adresse et le port que le serveur veut, et c’est vers cette adresse que le client se connecte ensuite. S’il s’agit d’une adresse privée qui ne signifie rien côté client du tunnel, la connexion de données ne va nulle part tandis que le canal de contrôle reste sain.

Comparez cette adresse à celle que le client a réellement atteinte. L’écart est la réponse, et il vient généralement du NAT ou d’un serveur configuré avec une adresse interne.

Vérifiez la plage de ports et la stratégie du tunnel

Les serveurs passifs allouent les ports de données dans une plage configurée, et cette plage doit être autorisée à travers le VPN et tout pare-feu sur le chemin. Une stratégie qui autorise 21 et rien d’autre est une stratégie de connexion seule. Confirmez la plage avec celui qui gère le serveur, puis testez un port de cette plage au lieu de supposer que toute la plage se comporte de la même façon.

Les canaux de contrôle chiffrés compliquent la chose, car un intermédiaire ne peut plus réécrire l’adresse annoncée en vol.

Sachez quand EPSV ou une solution de repli aide

EPSV renvoie un port sans adresse séparée, ce qui supprime l’échec d’adresse erronée lorsque les deux extrémités le prennent en charge. Certains clients peuvent aussi être configurés pour ignorer l’adresse annoncée et réutiliser la destination de la connexion de contrôle. Les deux sont des outils légitimes visant une topologie précise, pas un correctif universel.

Ne désactivez pas TLS juste pour laisser un outil inspecter la session. Cela échange un protocole qui fonctionne contre un modèle de menace cassé.

Confirmez avec un listing et un transfert

Après le changement de stratégie d’adresse ou de port, ouvrez une session neuve sur le même chemin VPN et listez un répertoire. Transférez ensuite un petit fichier, car un listing et un transfert peuvent emprunter des chemins de code différents sur certains serveurs. Vérifiez dans le journal du client une connexion de données vers l’adresse et le port attendus, et confirmez que les octets sont arrivés.

Gardez FTP, FTPS et SFTP séparés en tête pendant cette opération. Un changement de port passif n’est pas un réglage SFTP, et le correctif ne se transpose pas d’un protocole à l’autre.