Algo não está funcionando aqui. Eu tenho o seguinte erro ao usar o FileZilla para se conectar a uma máquina remota executando vsftpd :
Command: LIST
Error: Connection timed out
Error: Failed to retrieve directory listing
Estou tentando configurar serviços FTP em 3 máquinas atrás de um firewall residencial de ISP. Todos são Ubuntu 12.04 Server LTS, e estou impedido de usar a porta 21 externamente no site remoto.
Bem ... Ok, confesso, sou eu quem está impondo a restrição. Eu só queria parecer que estava trabalhando para uma empresa real. De qualquer forma, apenas 1 dos 3 sistemas poderia ter sido atribuído a 21, então ainda seria um problema.
Eu tentei as soluções para adicionar linhas "pasv _...", mas ainda não consigo passar do estágio LIST da conexão.
Então, tendo falhado, qual seria o problema?
Eu li no este site que preciso encaminhar as portas 20 e 21. Neste momento, os sites remotos têm portas como 10000, 11000, 12000 encaminhadas para a porta interna 21 em cada um dos sistemas. Devo encaminhar algumas portas adicionais para 20? não faz sentido porque essa porta não está nem aberta, o vsftpd está apenas ouvindo 21.
Tudo que eu quero é ter uma conexão ftp bem-sucedida por meio dessas portas encaminhadas, estou frustrado porque fui encaminhado com sucesso para serviços como SSH, apache2 etc. e não entendo o que está quebrado aqui.
thx Joren por corrigir minha formatação!
EDIT: Eu tenho brincado com o meu teste VPS que está diretamente exposto à internet, eu instalei o vsftpd só para ver o que acontece, e a saída do 'netstat -tuna' mostra que uma conexão bem-sucedida do meu cliente filezilla assim:
tcp 0 0 vps.vps.vps.vps:21 fi.le.zil.la:54288 ESTABLISHED
tcp 0 0 vps.vps.vps.vps:46403 fi.le.zil.la:54289 TIME_WAIT
Nota: o servidor FTP no meu VPS também não funcionou no início, devido a um problema completamente não relacionado envolvendo ambientes virtualizados ("500 OOPS: priv_sock_get_cmd"). Leia: Eu estou começando a ver que o vsftpd do Ubuntu não funciona 'out-of-the-box' como o apache2 e o sshd, para qualquer administrador novato frustrado por aí, não acho que você ' re estúpido se não está funcionando a primeira coisa ...
Meu teste VPS não tem um firewall, portanto todas as portas estão diretamente disponíveis para acesso pelo daemon FTP. Depois de executar esse teste, vejo que é possível que essa conexão secundária esteja sendo bloqueada no site remoto onde estou tendo problemas (portas aleatórias, como 46403).
Pelo menos agora eu confirmei que não há problemas de NAT com o meu Filezilla, porque claramente o filezilla está abrindo portas aleatórias e falando com o meu VPS ok.
A única coisa que não faz sentido, é a configuração 'connect_from_port_20 = YES' está definida na minha configuração de FTP do VPS, mas não consigo ver nenhuma conexão usando a porta 20 !!! É por isso que nem sei se essa porta precisa ser encaminhada por um firewall.
Uma das minhas deficiências de conhecimento é que eu nem sei o que é a porta 20, e não consigo aprender com a experiência porque nunca vi qualquer indicação de que a porta é usada durante a conexão, download ou upload.
OK, eu encontrei alguns problemas (há claramente mais de uma coisa errada) - Isso tem a ver com o encaminhamento de porta.
Suspeite de um problema original (antes de personalizar o vsftpd.conf)
- O Filezilla inicialmente se conecta à porta remota 10000, == & gt; vai para 21 no servidor FTP interno (ok)
- O servidor FTP abre uma porta aleatória (NÃO 20) como 45678, mas o roteador obviamente não tem uma regra para essa porta atribuída aleatoriamente. Ele envia uma mensagem dizendo ao FileZilla para também se conectar ao 45678.
- O cliente do Filezilla abre sua própria porta do meu lado atrás do NAT (ok)
- O Filezilla envia solicitação de conexão para 45678, mas o roteador remoto não aceita a conexão, pois não há regra de encaminhamento para essa porta.
Agora, o (s) problema (s) que criei:
pasv_enable=YES
pasv_min_port=10000
pasv_max_port=10000
- O Filezilla se conecta à porta remota 10000, == & gt; vai para 21 no servidor FTP interno (ok)
- O servidor FTP abre a única porta possível, 10000, [momento estúpido] porque tenho essa porta na minha cabeça associada a esse sistema. Mas 10000 é na verdade a contraparte do lado da WAN para 21 neste sistema.O servidor envia uma mensagem para o FileZilla se conectar a 10000 e escuta internamente em 10000
- O cliente do Filezilla abre sua própria porta aleatória no meu lado (ok)
- O Filezilla tenta a conexão secundária na porta 10000, o roteador remoto a desvia para a porta 21 novamente onde deve ser ignorado ou perdido, enquanto o servidor FTP aguarda por uma conexão à porta interna 10000 que nunca chega. (falha)
Segundo problema que criei: Eu tentei ligar a porta 21 dessa vez, mas acho que isso bagunçou o filezilla.
pasv_enable=YES
pasv_min_port=21
pasv_max_port=21
- O Filezilla se conecta à porta remota 10000, == & gt; vai para 21 no servidor FTP interno (ok)
- O servidor FTP abre a porta 21 (ou talvez falhe porque 21 já está sendo usado) se for bem-sucedido, enviou uma mensagem para o filezilla se conectar à porta 21.
- O cliente do Filezilla abre sua própria porta aleatória no meu lado (ok)
- O Filezilla envia uma solicitação para LISTA para 21, que o roteador não aceitará ... (falha)
Conclusão: enquanto a porta estiver sendo alterada por um roteador, o servidor FTP nunca poderá informar ao cliente para se conectar à porta correta. Se você tentar usar a porta interna, o cliente será executado contra o roteador. Se você tentar especificar a porta externa, o roteador irá desviar a conexão de entrada para um número diferente - o que o servidor não esperava.
Vou testar uma solução e relatar aqui com os resultados.
Eu acho que, porque o protocolo do servidor FTP aparece para informar ao cliente a qual porta se conectar, essa conexão secundária DEVE ter o mesmo número de porta externa que o interno.
Eu chamarei isso de 'conexão secundária' e acho que tem algo a ver com a porta 20 que não entendo.
Portanto, entrarei em contato com o site remoto e terei uma porta adicional encaminhada diretamente , para que o servidor FTP possa abrir uma conexão internamente e o cliente possa enviar uma solicitação de conexão para esse exato número da porta.
Novo plano:
(nota: o '%' serve para mostrar a porta sendo alterada pelo roteador remoto).
server #1
primary connection: 21 <--%--> 10000
secondary connection 10001 <-----> 10001
vsftp.conf:
pasv_min_port=10001
pasv_max_port=10001
server #2
primary connection 21 <--%--> 11000
secondary connection 11001 <-----> 11001
vsftp.conf:
pasv_min_port=11001
pasv_max_port=11001
server #3
primary connection 21 <--%--> 12000
secondary connection 12001 <-----> 12001
vsftp.conf:
pasv_min_port=12001
pasv_max_port=12001