Bom Dia a todos,
Estou hospedando um servidor FTP do FileZilla (modo passivo) em um servidor WIN 2012 R2 hospedado no MS Azure.
As transferências de FTP geralmente estão funcionando bem - vários uploads e recuperações de FTP são executados diariamente.
Abri uma grande variedade de portas (pontos de extremidade) no Portal / lado do Azure para permitir o modo passivo.
Esporadicamente (em média, uma vez a cada 2 dias), estou vendo problemas de transferências via FTP como o seguinte:
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> MDTM dev_updates/file1
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 213 20160728071048
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> MDTM dev_updates/file2
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 213 20160728071048
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> MDTM dev_updates/file3
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 213 20160728071050
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> CWD dev_updates/Infrastructure/folder
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 250 CWD successful. "dev_updates/Infrastructure/folder" is current directory.
8/8/2016 9:10:00 AM - USER_FILEZILLA (62.154.Y.X)> PASV
8/8/2016 9:10:00 AM - USER_FILEZILLA (62.154.Y.X)> 227 Entering Passive Mode (104,40,Y,X,234,235)
8/8/2016 9:10:00 AM - USER_FILEZILLA (62.154.Y.X)> 426 Connection closed; aborted transfer of ""
8/8/2016 9:10:01 AM - USER_FILEZILLA (62.154.Y.X)> disconnected.
8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> Connected on port 21, sending welcome message...
8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 220-FileZilla Server 0.9.57 beta
8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 220-written by Tim Kosse (tim.kosse@filezilla-project.org)
8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 220 Please visit https://filezilla-project.org/
8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> USER USER_FILEZILLA
8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 331 Password required for
Como mencionado, existem várias transferências de FTP diariamente (automatizadas) e varrendo o intervalo de mais de 140 portas atribuído ao servidor FTP do FileZilla (atuando no modo passivo).
Eu tenho uma captura do Wireshark em execução na VM hospedada no Azure; Vejo nas capturas do Wireshark que os eventos "426 conexão fechada" são na verdade correspondidos por um RST originado pela VM no Azure e enviado de volta ao cliente que emitiu o comando PASV (ou seja, no exemplo acima, o servidor FTP responde a o comando PASV do cliente com a porta: 234.235 -> 60139; o cliente tenta abrir um canal de dados na porta 60139 para iniciar a transferência -> o servidor FTP responde imediatamente (no MS de acordo com a captura do Wireshark) emitindo um RST para o cliente).
Pensei em algum problema de alocação de portas efêmeras no servidor FTP -> então reduzi o intervalo de portas efêmeras dinâmico permitido do SO para não sobrepor o intervalo de portas passivas do FTP - usando o
netsh int ipv4 set dynamicport tcp start=49152 num=10000
Além disso, adicionei explicitamente a reserva do intervalo de portas à pilha netsh por meio do comando
netsh int ip add excludeportrange protocol=tcp startport=60000 numberofports=141 store=persistent
Ainda assim, o problema ainda está acontecendo ocasionalmente.
Eu li as extensas discussões técnicas neste site e na sessão do technet do MS Azure sobre como o Azure monitora o status dos pontos de extremidade (quando parte de um conjunto LB), mas isso não é aplicável no meu caso como transferências passivas de FTP (recuperação e uploads) em portas aleatórias dentro do intervalo de portas passivas FTP reservadas, geralmente estão funcionando bem.
Posso fornecer detalhes adicionais, se necessário - enquanto isso, ficaria grato por sugestões adicionais sobre solução de problemas / investigações no lado do servidor e do cliente (com certeza o problema não está relacionado à rede ou à configuração da rede).
Também gostaria de pedir sugestões / soluções de problemas / investigações adicionais sobre como depurar o winsock para possíveis problemas de disponibilidade de soquetes do lado do servidor.
426
erro de aborto sempre seguia alguns segundos atrás de outra sessão, obtendo um 550
erro de permissão negada. Eu suspeito que isso seja um bug do FileZilla, mas para nós a correção foi impedir o 550 (no nosso caso, um sistema de teste estava tentando acessar a pasta de teste, mas usando credenciais de produção; portanto, apenas tivemos que corrigir as credenciais do sistema) .