Невозможно использовать пассивный режим FTP после недавнего обслуживания виртуальной машины Windows Azure

Недавно в Windows Azure было запланировано техническое обслуживание служб виртуальных машин.

Моя машина больше не загружалась, поэтому я воссоздал ее заново из своего образа диска, который должен работать нормально, пока работал нормально.

Запуск пассивного FTP в Windows Azure

Я запускаю FTP-службы на моем виртуальном сервере с vsftpd. И активный, и пассивный. Для пассивного FTP я выбрал порты 25003-25014 в качестве диапазона. Я установил их в свой vsftpd.conf файл, и я сопоставил все конечные точки в панели управления Azure.

Мой 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

Сопоставление портов (порт 21 находится в верхней части списка, не показан на скриншоте)

Эта проблема

Когда клиент подключается к FTP, он пытается войти в пассивный режим, но безуспешно. Дальнейшие анализы проводились с помощью tcpdump. Несколько анализов

Клиент Xftp сообщает следующий журнал активности:

STATUS:>    Session started...
STATUS:>    Resolving the host 'XXXXXXXXXXXX'...
STATUS:>    Connecting to the server 'XXXXXXXXXXX'...
        220 WELCOME
STATUS:>    Authenticating for 'YYYYYYYY'...
COMMAND:>   USER YYYYYYYYY
        331 Please specify the password.
COMMAND:>   PASS ****
        230 Login successful.
COMMAND:>   PWD
        257 "/"
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 должен быть 97*256+174=25006. Потом у меня таймаут.

# 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)

Я запустил tcpdump на сервере и обнаружил две вещи:

• 100.89.XXX.YYY, который не является частью моих кластеров (это не облачная служба, которой я владею, но находится в той же подсети, что и виртуальная машина), получает много RST-пакетов. Но кто, черт возьми, сказал этой машине подключаться к моему FTP?
• SYN пакеты с моего IP никогда не доходят до сервера

Еще я заметил еще одну интересную вещь. Когда я начинаю vsftpd с консоли SSH для запуска требуется около минуты. Собственно процесс запускается и указан в netstat, но ему требуется время, чтобы принимать входящие соединения от моего клиента.

Пытался проверить, отключен ли брандмауэр. Я побежал yast firewall но обнаружил, что другой брандмауэр активен на машине: Я их не настраивал!

Странно рабочий обходной путь

Уменьшив диапазон портов PASV до одного, я обнаружил, что после нескольких попыток он в конечном итоге подключается к порту PASV и отображает список каталогов.

Вопрос

Как заставить vsftpd снова работать должным образом? Учтите, что я никогда не менял конфигурацию.

Возможная связанная проблема (не подтверждена)

Приведенный выше анализ подсказывает мне, что существует значительная delay между accept() syscall, выполняемый FTP-сервером, и конкретная возможность для Azure маршрутизировать TCP SYN-пакеты с общедоступного IP-адреса / порта на частный IP-адрес / порт, что вызывает тайм-аут.

Поэтому я попытался запустить экземпляр Webmin и сразу же попытался подключиться к моему браузеру: демону потребовалось несколько секунд для запуска, но после запуска он выглядел так, как будто ответил немедленно, так что это не обязательно является причиной