Tempo limite do IIS FTP 8.5 DataChannel com um cliente linux

Question

Eu tenho uma situação estranha. Espero que alguém possa ajudar. Eu tenho dois servidores FTP IIS independentes.

1. a) O IIS 7.5 é executado como VM autônoma
2. b) O IIS 8.5 é executado na VM do Azure (Windows Server 2012 R2)

Quando me conecto a esses servidores ftp usando o FileZilla, ambos funcionam como esperado, muito bem. Modo passivo, sem problemas.

Quando um cliente linux do meu cliente está se conectando, ele funciona muito bem no IIS 7.5, mas não funciona no IIS 8.5

Ele pára após o comando PASV com um tempo limite. O cliente linux está executando algum aplicativo no fedora que possui FTP incorporado.

Para autenticação, estou usando usuários do Gerenciador do IIS.

Alguém tem uma ideia do que isso poderia ser? Ou como solucionar isso ?? Eu posso testar e ver tudo funcionando, exceto quando os processos dos clientes estão entrando em cena!

Depois de horas tentando coisas ... eu desliguei o firewall do windows inteiramente no IIS 8.5, e adicionei algumas permissões 'all ports' ao firewall do Azure ... mas sem ajuda. Para mim, parece algo no Azure ou na nova versão do IIS FTP 8.5 ... poderia ser?

Depois de instalar o Wireshark no IIS srvr, obtive isto:

230 User logged in.
USER someuser
PASS somepassword
TYPE A
200 Type set to A.
PASV
227 Entering Passive Mode (xxx,166,145,222,20,18).
ABOR
226 ABOR command successful.

Pacotes:

297 15.067087   ###.41.121.116  10.0.0.4    FTP 72  Request: PASV
298 15.067223   10.0.0.4    ###.41.121.116  FTP 117 Response: 227 Entering Passive Mode (XXX,166,145,222,20,18).
300 15.083895   ###.41.121.116  10.0.0.4    TCP 66  39240 → 21 [ACK] Seq=46 Ack=143 Win=5888 Len=0 TSval=1985344095 TSecr=659594
370 19.338991   10.0.0.4    ###.41.121.116  TCP 86  [TCP Retransmission] 21 → 58522 [PSH, ACK] Seq=72 Ack=40 Win=131072 Len=20 TSval=660021 TSecr=1985339032
431 23.746259   ###.41.121.116  10.0.0.4    FTP 72  Request: ABOR
432 23.746366   10.0.0.4    ###.41.121.116  FTP 96  Response: 226 ABOR command successful.
433 23.762471   ###.41.121.116  10.0.0.4    TCP 66  45877 → 21 [ACK] Seq=7 Ack=31 Win=46 Len=0 TSval=1985352774 TSecr=660462

os pacotes 299, 301-369, 371-430 pertencem a outros processos (principalmente PDR)

    

Answer 1

Eu vejo uma retransmissão TCP antes do aborto. Por favor, confirme se o pacote 370 é uma retransmissão de pacote 298? Se sim, significa que o servidor não recebe nenhuma resposta do cliente quando envia o pacote 298 (Entrando no Modo Passivo). A causa mais comum desse problema é que o Azure bloqueia a conexão do cliente com o canal de dados do servidor.

Podemos limitar a porta usada como canal de dados no IIS. Em seguida, podemos adicionar essas portas ao firewall do Azure para garantir que o cliente possa iniciar a transmissão de dados para o servidor.

Aqui está uma boa guia sobre isso.

========================================

Atualizar

Se você estiver usando o Azure no modo Gerenciador de recursos (ARM), precisará abrir as portas no Grupo de segurança de rede. Aqui está um bom artigo sobre o diferença entre o ARM e o ASM na rede.

Se você abriu a porta no Azure corretamente e ainda não funciona, tente executar a captura de rede no servidor e no cliente ao mesmo tempo para descobrir os pacotes descartados.

Se o cliente não receber o pacote "Entrando no Modo Passivo" do servidor, verifique o firewall de saída no lado do servidor e o firewall de entrada no lado do cliente.

Se o cliente receber os pacotes do servidor, mas não responder a ele. Então deve ser uma questão do lado do cliente.

Se o cliente enviar a resposta ao servidor, mas o servidor não o receber, você deverá verificar novamente se as ACLs no grupo de segurança de rede estão corretas. Se tiver certeza sobre isso, talvez seja necessário abrir um ticket com o suporte do Azure para executar a captura de rede no host azul para localizar o que descarta os pacotes.