O login FTP funciona, mas a listagem de pastas trava: por quê
Logins FTP e listagens de pastas usam duas conexões diferentes. Quando uma listagem trava, verifique o endereço de dados passivo e a faixa de portas, não a palavra-passe.
O nome de utilizador funciona, a palavra-passe funciona e o cliente diz que está ligado. Depois espera eternamente por uma listagem de pasta, ou pela primeira transferência de ficheiro, e nada nas credenciais explica isso. O FTP abre uma segunda conexão para cada listagem e cada ficheiro, e é essa segunda conexão que falha. O login só prova que a primeira conversa funciona.
Faça as verificações por ordem. Cada uma elimina uma camada diferente, por isso pare na primeira que produzir uma anomalia.
Separe primeiro as duas conexões
Uma conexão de controlo transporta comandos e respostas na porta de escuta do servidor. Uma conexão de dados transporta a listagem do diretório ou o corpo do ficheiro, e no modo passivo o servidor escolhe o seu ponto final e anuncia-o na resposta PASV ou EPSV. Permitir a porta 21 não diz nada sobre a acessibilidade da porta de dados, e é exatamente por isso que um login tem sucesso enquanto cada listagem expira. O guia do WinSCP sobre os modos FTP explica essa separação e os respetivos requisitos de rede.
Se o cliente estiver atrás da VPN, o caminho de dados atravessa o mesmo túnel, mas não necessariamente a mesma política.
Leia o endereço na resposta PASV
Execute um cliente detalhado e leia a resposta em vez de adivinhar. curl -v ftp://user@host/ imprime a linha PASV com o endereço e a porta que o servidor quer, e é para esse endereço que o cliente se liga a seguir. Se for um endereço privado que não significa nada do lado do cliente do túnel, a conexão de dados não vai a lado nenhum enquanto o canal de controlo se mantém saudável.
Compare esse endereço com o endereço que o cliente realmente alcançou. A divergência é a resposta, e normalmente vem do NAT ou de um servidor configurado com um endereço interno.
Verifique a faixa de portas e a política do túnel
Os servidores passivos atribuem portas de dados a partir de uma faixa configurada, e essa faixa tem de ser permitida através da VPN e de qualquer firewall no caminho. Uma política que permite 21 e mais nada é uma política só de login. Confirme a faixa com quem administra o servidor e depois teste uma porta dela em vez de assumir que toda a faixa se comporta da mesma forma.
Os canais de controlo cifrados tornam isto mais difícil, porque um intermediário já não pode reescrever o endereço anunciado em pleno voo.
Saiba quando o EPSV ou uma alternativa ajudam
O EPSV devolve uma porta sem um endereço separado, o que elimina a falha de endereço errado quando ambas as extremidades o suportam. Também se pode instruir alguns clientes a ignorar o endereço anunciado e a reutilizar o destino da conexão de controlo. Ambos são ferramentas legítimas para uma topologia concreta, não uma correção universal.
Não desative o TLS só para permitir que um auxiliar inspecione a sessão. Isso troca um protocolo a funcionar por um modelo de ameaça quebrado.
Confirme com uma listagem e uma transferência
Depois de alterar a política de endereço ou de porta, abra uma sessão nova pelo mesmo caminho VPN e liste um diretório. De seguida transfira um ficheiro pequeno, porque uma listagem e uma transferência podem seguir caminhos de código diferentes em alguns servidores. Verifique no registo do cliente uma conexão de dados para o endereço e a porta esperados e confirme que os bytes chegaram.
Mantenha FTP, FTPS e SFTP separados na cabeça enquanto faz isto. Uma alteração de porta passiva não é uma definição do SFTP, e a correção não passa entre protocolos.