El nombre de usuario funciona, la contraseña funciona y el cliente dice que está conectado. Luego espera para siempre una lista de carpeta, o la primera transferencia de archivo, y nada en las credenciales lo explica. FTP abre una segunda conexión para cada lista y cada archivo, y es esa segunda conexión la que falla. El inicio de sesión solo demuestra que la primera conversación funciona.

Realice las comprobaciones en orden. Cada una descarta una capa distinta, así que deténgase en la primera que produzca una anomalía.

Separe primero las dos conexiones

Una conexión de control transporta comandos y respuestas en el puerto de escucha del servidor. Una conexión de datos transporta la lista de directorio o el cuerpo del archivo, y en modo pasivo el servidor elige su extremo y lo anuncia en la respuesta PASV o EPSV. Permitir el puerto 21 no dice nada sobre si el puerto de datos es alcanzable, y por eso exactamente un inicio de sesión tiene éxito mientras cada lista expira. La guía de WinSCP sobre los modos FTP explica esa separación y sus requisitos de red.

Si el cliente está detrás de la VPN, la ruta de datos cruza el mismo túnel pero no necesariamente la misma política.

Lea la dirección en la respuesta PASV

Ejecute un cliente detallado y lea la respuesta en lugar de adivinar. curl -v ftp://user@host/ imprime la línea PASV con la dirección y el puerto que quiere el servidor, y es a esa dirección donde el cliente se conecta después. Si es una dirección privada que no significa nada en el lado del cliente del túnel, la conexión de datos no va a ninguna parte mientras el canal de control sigue sano.

Compare esa dirección con la que el cliente alcanzó realmente. La discrepancia es la respuesta, y suele venir de NAT o de un servidor configurado con una dirección interna.

Compruebe el rango de puertos y la política del túnel

Los servidores pasivos asignan puertos de datos de un rango configurado, y ese rango debe estar permitido a través de la VPN y de cualquier cortafuegos en la ruta. Una política que permite 21 y nada más es una política solo de inicio de sesión. Confirme el rango con quien administra el servidor y luego pruebe un puerto de él en lugar de suponer que todo el rango se comporta igual.

Los canales de control cifrados lo dificultan, porque un intermediario ya no puede reescribir la dirección anunciada en vuelo.

Sepa cuándo ayuda EPSV o un recurso alternativo

EPSV devuelve un puerto sin una dirección separada, lo que elimina el fallo por dirección incorrecta cuando ambos extremos lo admiten. También se puede indicar a algunos clientes que ignoren la dirección anunciada y reutilicen el destino de la conexión de control. Ambas son herramientas legítimas para una topología concreta, no una solución universal.

No desactive TLS solo para que un auxiliar inspeccione la sesión. Eso cambia un protocolo que funciona por un modelo de amenazas roto.

Confirme con una lista y una transferencia

Después de cambiar la política de dirección o de puerto, abra una sesión nueva por la misma ruta VPN y liste un directorio. Luego transfiera un archivo pequeño, porque una lista y una transferencia pueden tomar rutas de código distintas en algunos servidores. Revise el registro del cliente por una conexión de datos a la dirección y el puerto esperados y confirme que los bytes llegaron.

Mantenga FTP, FTPS y SFTP separados en la cabeza mientras lo hace. Un cambio de puerto pasivo no es un ajuste de SFTP, y la corrección no se traslada entre protocolos.

Artículos relacionados