☰

Proftpd no responde al comando "PASV"

tag-icon • tag-icon ftp port-forwarding proftpd ftps
Proftpd no responde al comando "PASV"

He estado intentando configurar mi servidor FTPS que está detrás de NAT. así que abrí los puertos 20, 21 y 2120-2180 en mi NAT (TCP+UDP) y configuré proftpd para usar estos puertos para comunicaciones pasivas.

Sin embargo, intentar conectarse usando FileZilla conduce al siguiente registro: (en francés, pero bastante claro en realidad)

Statut :    Résolution de l'adresse de heardrones.com
Statut :    Connexion à 93.30.208.56:21...
Statut :    Connexion établie, attente du message d'accueil...
Réponse :   220 ProFTPD 1.3.5 Server (HEAR Server) [93.30.208.56]
Commande :  USER hear_downloader
Réponse :   331 Mot de passe requis pour hear_downloader
Commande :  PASS ********
Réponse :   230 Utilisateur hear_downloader authentifié
Commande :  OPTS UTF8 ON
Réponse :   200 UTF-8 activé
Statut :    Connecté
Statut :    Récupération du contenu du dossier...
Commande :  PWD
Réponse :   257 "/" est le répertoire courant
Commande :  TYPE I
Réponse :   200 Type paramétré à I
Commande :  PASV
Erreur :    Délai d'attente expiré
Erreur :    Impossible de récupérer le contenu du dossier

¡Se agota el tiempo incluso antes de poder enviar la respuesta "PASV"! Que podria causar esto ? La respuesta al comando PASV utiliza el mismo puerto que todos los demás comandos (PWD, TYPE...), entonces, ¿de dónde podría venir?

Aquí está el diseño de la red:

    Server
        Proftpd, no iptables, fix IP 192.168.0.13
        -> (Wifi)
    ISP Box - French ISP (SFR)
        port transfer 20,21,22,2120-2180 to 192.168.0.13
        -> (optic fiber !)
    Internet

Puedo proporcionar capturas de pantalla de la configuración de Box y archivos de configuración proftpd si es necesario. La conexión desde LAN/Localhost funciona perfectamente.

Respuesta1

FTP es un protocolo horrible. Utiliza dos puertos: uno para comandos y otro para datos. Esto hace que sea notoriamente difícil realizar NAT, ya que un enrutador necesitaría analizar el canal de comando y descubrir que se espera una segunda conexión para esta conversación FTP. Hacerlo es feo, pero también es la única forma de hacer que NAT funcione con FTP.

FTPScifrael canal de comando, lo que hace imposible que cualquier enrutador inspeccione los paquetes y determine dónde estará el canal de datos. Obviamente eso significa que entonces no podrá dar cuenta de eso; de modo que cuando el cliente inicie su canal de datos (como lo requiere PASV), su enrutador NATting no sabrá qué hacer con él. No es posible solucionar este problema debido a la forma en que funciona FTP.

Simplemente diga no a FTP y use SFTP o algo por el estilo (que transfiere archivos a través de un túnel SSH y, por lo tanto, solo requiere una conexión TCP). La mayoría de los clientes FTP gráficos también son compatibles con SFTP en estos días.

información relacionada