O inicio de sesión FTP funciona, pero a lista de cartafoles colgase: por que
Os inicios de sesión FTP e as listas de cartafoles usan dúas conexións distintas. Cando unha lista se colga, comprobe o enderezo de datos pasiva e o rango de portos, non o contrasinal.
O nome de usuario funciona, o contrasinal funciona e o cliente di que está conectado. Despois espera para sempre unha lista de cartafol, ou a primeira transferencia de ficheiro, e nada nas credenciais o explica. FTP abre unha segunda conexión para cada lista e cada ficheiro, e é esa segunda conexión a que falla. O inicio de sesión só demostra que a primeira conversa funciona.
Faga as comprobacións en orde. Cada unha descarta unha capa distinta, así que detéñase na primeira que produza unha anomalía.
Separe primeiro as dúas conexións
Unha conexión de control transporta ordes e respostas no porto de escoita do servidor. Unha conexión de datos transporta a lista de directorio ou o corpo do ficheiro, e en modo pasivo o servidor escolle o seu extremo e anúnciao na resposta PASV ou EPSV. Permitir o porto 21 non di nada sobre se o porto de datos é alcanzable, e por iso exactamente un inicio de sesión ten éxito mentres cada lista expira. A guía de WinSCP sobre os modos FTP explica esa separación e os seus requisitos de rede.
Se o cliente está detrás da VPN, a ruta de datos cruza o mesmo túnel pero non necesariamente a mesma política.
Lea o enderezo na resposta PASV
Execute un cliente detallado e lea a resposta en lugar de adiviñar. curl -v ftp://user@host/ imprime a liña PASV co enderezo e o porto que quere o servidor, e é a ese enderezo onde o cliente se conecta despois. Se é un enderezo privado que non significa nada no lado do cliente do túnel, a conexión de datos non vai a ningures mentres a canle de control segue san.
Compare ese enderezo co enderezo que o cliente alcanzou realmente. A discrepancia é a resposta, e adoita vir de NAT ou dun servidor configurado cun enderezo interno.
Comprobe o rango de portos e a política do túnel
Os servidores pasivos asignan portos de datos dun rango configurado, e ese rango debe estar permitido a través da VPN e de calquera firewall na ruta. Unha política que permite 21 e nada máis é unha política só de inicio de sesión. Confirme o rango con quen xestiona o servidor e logo probe un porto del en lugar de supoñer que todo o rango se comporta igual.
As canles de control cifradas fan isto máis difícil, porque un intermediario xa non pode reescribir o enderezo anunciado en voo.
Saiba cando axuda EPSV ou unha alternativa
EPSV devolve un porto sen un enderezo separado, o que elimina o fallo por enderezo incorrecto cando ambos os extremos o admiten. Tamén se pode indicar a algúns clientes que ignoren o enderezo anunciado e reutilicen o destino da conexión de control. Ambas son ferramentas lexítimas para unha topoloxía concreta, non unha solución universal.
Non desactive TLS só para que un auxiliar inspeccione a sesión. Iso cambia un protocolo que funciona por un modelo de ameazas roto.
Confirme cunha lista e unha transferencia
Despois de cambiar a política de enderezo ou de porto, abra unha sesión nova pola mesma ruta VPN e liste un directorio. Logo transfira un ficheiro pequeno, porque unha lista e unha transferencia poden seguir camiños de código distintos nalgúns servidores. Revise o rexistro do cliente por unha conexión de datos ao enderezo e ao porto esperados e confirme que os bytes chegaron.
Manteña FTP, FTPS e SFTP separados na cabeza mentres o fai. Un cambio de porto pasivo non é un axuste de SFTP, e a corrección non se traslada entre protocolos.