Não é possível usar o modo passivo de FTP após a manutenção recente da VM do Windows Azure

Question

Recentemente, o Windows Azure tinha uma manutenção agendada nos serviços da Máquina Virtual.

Eu não tinha mais inicialização da minha máquina, então recriou-a nova na minha imagem de disco, que deve funcionar bem, até agora.

Executando FTP passivo no Windows Azure

Eu executo serviços FTP no meu servidor virtual com vsftpd . Ativo e passivo. Para o FTP passivo, escolhi as portas 25003-25014 como intervalo. Eu os defini no meu arquivo vsftpd.conf e mapeei todos os endpoints no painel de controle do Azure.

Meu vsftpd.conf :

write_enable=YES
dirmessage_enable=YES
nopriv_user=ftpsecure
local_enable=YES
anonymous_enable=NO
anon_world_readable_only=YES
syslog_enable=NO
xferlog_enable=YES
vsftpd_log_file=/var/log/vsftpd.log
xferlog_std_format=YES
xferlog_file=/var/log/vsftpd.log
connect_from_port_20=YES
ascii_upload_enable=YES
pam_service_name=vsftpd
ssl_enable=NO
pasv_min_port=25003
pasv_max_port=25014
anon_mkdir_write_enable=NO
anon_root=/srv/ftp
anon_upload_enable=NO
chroot_local_user=YES
ftpd_banner=WELCOME
idle_session_timeout=900
listen=YES
log_ftp_protocol=YES
max_clients=30
max_per_ip=8
pasv_enable=YES
ssl_sslv2=NO
ssl_sslv3=NO
ssl_tlsv1=YES
pasv_addr_resolve=YES
pasv_address=<myhost>.cloudapp.net

Port mapings (a porta 21 está no topo da listagem, não mostrada na captura de tela)

Oproblema

QuandoumclienteseconectaaoFTP,eletentaentrarnomodopassivo,masnãoconsegue.Outrasanálisesrealizadasusandootcpdump.Váriasanálises

OclienteXftpreportaoseguinteregistrodeatividades:

STATUS:>Sessionstarted...STATUS:>Resolvingthehost'XXXXXXXXXXXX'...STATUS:>Connectingtotheserver'XXXXXXXXXXX'...220WELCOMESTATUS:>Authenticatingfor'YYYYYYYY'...COMMAND:>USERYYYYYYYYY331Pleasespecifythepassword.COMMAND:>PASS****230Loginsuccessful.COMMAND:>PWD257"/"
STATUS:>    Listing folder '/'...
COMMAND:>   CWD /
        250 Directory successfully changed.
COMMAND:>   PWD
        257 "/"
COMMAND:>   TYPE A
        200 Switching to ASCII mode.
COMMAND:>   PASV
        227 Entering Passive Mode (XXX,XXX,XXX,XXX,97,174).

97,174 deve ser 97*256+174=25006 . Então eu tenho tempo limite.

# netstat -oanp | grep vsftpd
tcp        1      0 100.89.XXX.X:25013      0.0.0.0:*               LISTEN      26084/vsftpd        off (0.00/0/0)
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      25500/vsftpd        off (0.00/0/0)
tcp        0      0 100.89.XXX.X:21         100.89.XXX.YYY:57307    ESTABLISHED 26155/vsftpd        keepalive (7212,10/0/0)
tcp        0      0 100.89.XXX.X:21         MY.IP.ADDR.!!:57255       ESTABLISHED 26084/vsftpd        keepalive (7081,01/0/0)

Eu executei o tcpdump no servidor e descobri duas coisas:

• 100.89.XXX.YYY , que não faz parte de nenhum cluster meu (não é um serviço em nuvem que possuo, mas está na mesma sub-rede que a máquina virtual), obtém muitos pacotes RST. Mas quem diabos disse essa máquina para se conectar ao meu FTP?
• SYN pacotes do meu IP nunca chegam ao servidor

Eu também notei outra coisa interessante. Quando inicio vsftpd do console SSH, demora cerca de um minuto para ser ativado. Na verdade, o processo é iniciado e está listado em netstat , mas demora um pouco para aceitar conexões de entrada do meu cliente .

Eu tentei verificar se o firewall está desativado. Eu corri yast firewall mas descobri que outro firewall está ativo na máquina : eu configurei nenhum deles!

A estranha solução alternativa

Ao reduzir o intervalo de portas PASV para apenas um, descobri que, após algumas tentativas, ele eventualmente se conecta à porta PASV e exibe a listagem de diretórios

A questão

Como faço o vsftpd funcionar novamente como esperado? Por favor, note que eu nunca mudei de configuração.

Possível problema relacionado (não confirmado)

A análise acima sugere que há um delay considerável entre o accept() syscall feito pelo servidor FTP e a possibilidade concreta de o Azure rotear pacotes SYN do TCP de IP / porta pública para IP / porta privada, causando tempo limite.

Então eu tentei rodar uma instância do Webmin e imediatamente tentei conectar com meu navegador: demorou uma dúzia de segundos para o daemon iniciar, mas depois de iniciado pareceu responder de imediato, então isso não parece necessariamente seja a causa

    

Answer 1

Recentemente, tive um problema muito semelhante que consegui resolver usando a resposta para este post no fórum (o crédito vai para Craig Landis para a solução)

link .

algum texto de fundo do artigo:

We believe this may have to do with a recent change to how the portal creates endpoints. Now by default it configures a probe port on the endpoint where the probe port is the same as the endpoint port. The load balancer sends packets to the probe port to determine the health of the endpoint and if it does not get a response after a few retries, it will stop forwarding traffic to the endpoint port.

Example scenario:

Port 21 is open to all in Windows Firewall in the VM, so probe is successful, the endpoint is healthy and remote IPs can connect to it.

Port 60005 (for example) is likely only open in the Windows Firewall in the VM to those remote IPs that negotiated the passive mode ftp. It is not open to the load balancer so the load balancer is unable to probe this port. As a result, the endpoint as unhealthy and stops sending traffic to the endpoint port.

The 10.x.x.x address you see in the VM is the host server's IP address that the load balancer uses as the source IP to probe the port.

Workaround:

Remove the endpoints and then create them with Azure PowerShell using Add-AzureEndpoint, specifying only the name, protocol, localport and publicport parameters. This will create the endpoint without a probe port (which was the portal behavior until recently).

Há instruções adicionais na postagem sobre como adicionar os pontos de extremidade usando o PowerShell, caso você não saiba como fazer isso. Além disso, esse recurso me ajudou a começar a usar o PowerShell: link

Espero que isso ajude,

Yabbi