FTP desconecta após entrar no modo passivo b / c pacotes são perdidos

3

Por alguma razão, não importa quantas vezes eu tente, depois que um cliente envia o comando PASV (que é recebido corretamente pelo servidor), a resposta do servidor (227 Inserindo Modo Passivo) não retorna ao cliente. Cheguei a analisar o tráfego de clientes e servidores com o Wireshark para descobrir isso. O que é especialmente estranho é que o último pacote enviado pelo servidor tenha exatamente as mesmas configurações de TCP que qualquer outro pacote enviado com sucesso até o momento. Está tudo indo para o mesmo cliente, na mesma porta, e ainda por algum motivo essa resposta nunca chega. Estou completamente chocado quanto ao porquê.

Aqui estão as capturas de tela das interações entre cliente e servidor:

Captura de cliente

Comovocêpodever,elenuncarecebeoACKparaseucomandoPASV.Eletentamaisumavezedepoisdesiste.

Capturadeservidor

Como você pode ver, ele recebe o comando PASV e envia uma resposta, mas nunca chega ao cliente. Recebe a retransmissão mais tarde e envia a resposta mais 3 vezes, mas novamente nunca passa. Então desconecta.

Não consigo imaginar como é possível que todos os outros pacotes TCP passem de servidor para cliente sem problemas, mas esse pacote TCP em particular não. Os cabeçalhos TCP são idênticos para todos os pacotes de e para o servidor respectivamente, então, pelo que entendi, todos os roteadores, firewalls, ISPs, etc. devem tratá-los igualmente, a menos que sejam sniffing de pacotes.

    
por Alain 11.06.2013 / 00:53

4 respostas

3

Acabei de me debater com o mesmo problema e encontrei esta questão quando pesquisei uma solução. No meu caso, o problema foi causado pelo firewall (Sonic Wall), que detectou a resposta do servidor como um possível ataque de salto FTP e caiu a conexão. A solução foi alterar a configuração passiva no servidor FTP e inserir o endereço IP interno como resposta a um PASV. O firewall detectou-o como uma resposta legítima e converteu a resposta para o endereço externo antes de transmiti-lo ao cliente. Parece muito errado configurar isso, mas funciona em conjunto com esse firewall.

    
por 10.10.2014 / 21:27
1

Solução aparente: andei mexendo com qualquer coisa no roteador que pensei estar corrompendo pacotes de saída. Desativei algo chamado "NAT ALG" ( gateway no nível do aplicativo ) e o cliente e servidor FTP começaram a se comunicar normalmente modo passivo novamente. Aparentemente, esse protocolo de bisbilhotice causa problemas para muitas pessoas.

Para leitores futuros, meu modem / roteador é um Surfboarder SBG6580 da Motorola. Problema padrão para o meu ISP EastLink. Ele veio pré-configurado com muitos desses "recursos" e alguns pareciam estar corrompendo os pacotes de saída no nível do quadro Ethernet II.

    
por 11.06.2013 / 05:36
0

Acho que esse é um problema conhecido com a versão do FileZilla < 3.6.0.2, você por acaso usa a versão mais antiga?

    
por 11.06.2013 / 00:58
0

Eu encontrei exatamente o mesmo problema no meu servidor Windows 7. O cliente não pôde receber o pacote "227 entrando no modo passivo". O problema tem que estar no lado do servidor. Eu desliguei todos os firewalls, mas ainda obtive o mesmo resultado. Finalmente encontrei o motivo. No Centro de Rede e Compartilhamento, você não pode definir seu local de rede como "Rede pública". Porque as janelas tratam a Public Network como não confiável. Qualquer tentativa de conectar seu computador será considerada como risco e bloqueada. Basta configurá-lo para "Work Network" e o servidor funciona bem então.

    
por 31.03.2016 / 12:27