Modo FTP pasivo (Filezilla) Windows Server 2012 ocasional " 426 Conexión cerrada; transferencia cancelada de ""

Question

Buenos días a todos,

Estoy alojando un servidor FTP FileZilla (modo pasivo) en un servidor WIN 2012 R2 alojado en MS Azure.

Las transferencias FTP generalmente funcionan bien: diariamente se realizan varias cargas y recuperaciones de FTP.

He abierto una gama relativamente grande de puertos (puntos finales) en el Portal/lado de Azure para permitir el modo pasivo.

Esporádicamente (en promedio una vez cada dos días) veo problemas de transferencias FTP como los siguientes:

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 ([email protected])

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 se mencionó, hay varias transferencias FTP que se realizan diariamente (automatizadas) y abarcan el rango de más de 140 puertos asignados al servidor FTP de FileZilla (que actúa en modo pasivo).

Tengo una captura de Wireshark ejecutándose en la máquina virtual alojada en Azure; Puedo ver en las capturas de Wireshark que los eventos de "conexión 426 cerrada" en realidad coinciden con un RST generado por la VM en Azure y enviado de vuelta al cliente que emitió el comando PASV (es decir, en el ejemplo anterior, el servidor FTP responde a el comando PASV del cliente con el puerto: 234,235 -> 60139; el cliente intenta abrir un canal de datos al puerto 60139 para iniciar la transferencia -> el servidor FTP responde inmediatamente (dentro de MS según la captura de Wireshark) emitiendo un RST al cliente).

Pensé en algún problema de asignación de puertos efímeros en el lado del servidor FTP -> así que reduje el rango de puertos efímeros del sistema operativo dinámico permitido para no superponer el rango de puertos pasivos FTP - usando el

netsh int ipv4 set dynamicport tcp start=49152 num=10000

Además, agregué explícitamente la reserva de rango de puertos a la pila netsh mediante el comando

netsh int ip add excludeportrange protocol=tcp startport=60000 numberofports=141 store=persistent

Aún así, el problema sigue ocurriendo ocasionalmente.

Leí las extensas discusiones técnicas en este sitio web, así como en la sesión de technet de MS Azure, sobre cómo Azure monitorea el estado de los puntos finales (cuando forman parte de un conjunto LB), pero esto no se aplica en mi caso como transferencias FTP pasivas (recuperación y cargas). en puertos aleatorios dentro del rango de puertos pasivos FTP reservados generalmente funcionan bien.

Puedo proporcionar detalles adicionales si es necesario; mientras tanto, agradecería sugerencias adicionales sobre solución de problemas/investigaciones en el lado del servidor y del cliente (es casi seguro que el problema no está relacionado con la red o la configuración de la red).

También me gustaría solicitar sugerencias/consejos adicionales para la solución de problemas/investigación sobre cómo depurar Winsock para detectar posibles problemas de disponibilidad de sockets del lado del servidor.