FTP-сервер IIS 8.5: DIR и STOR возвращают ответ 550 при подключении с некоторых IP-адресов из белого списка

У нас есть:

• сервер IIS 8.5, который принимает FTP-соединения с IP-адресов из белого списка
• веб-приложение PHP (на сервере LEMP), которое создает файлы XML и загружает их на этот сервер IIS через FTP.

Нашему веб-приложению удалось установить соединение и загрузить свои XML-файлы. Мы также могли подключиться через Filezilla.

Список каталогов, загрузка файлов, создание папок работали без проблем в течение нескольких месяцев.

Однако в последнее время возможность перечисления или записи в папку перестала работать при подключении с определенных IP-адресов из белого списка.

Видеть этот скриншот для примера.

• Слева находится FTP-сеанс командной строки, который я открыл, используя свой IP-адрес из белого списка. Нет проблем с получением объявления (каталог пуст).
• Сеанс справа был открыт после подключения к моему серверу OpenVPN. Сразу отключился после DIR.

Аналогичный тест (Скриншот) с другим IP-адресом из белого списка дал тот же результат - DIR терпит неудачу при первой попытке (с использованием другой VPN), но успешной во второй попытке (с использованием резидентного IP-адреса).

Такое поведение сохраняется при использовании Filezilla.

Хуже того, теперь мы получаем такое поведение в сеансах FTP нашего веб-приложения. Вот Скриншот FTP-сеанса я начал с нашего LEMP-сервера через SSH.

После dir команда, она просто зависает на неопределенный срок, пока я не нажму Ctrl + C. Я заметил 550 код ответа есть.

550 появляется снова, когда наше веб-приложение пытается STOR файл:

Попытка загрузки нашим веб-приложением

2019-01-14 17:43:18 [ip removed] DOMAIN\Username 192.168.1.2 21 TYPE A 200 0 0 53e4f879-8616-435f-bef2-4a84ae0d7989 - -
2019-01-14 17:43:18 [ip removed] DOMAIN\Username 192.168.1.2 21 PORT xxx,xxx,xxx,xxx,158,231 200 0 0 53e4f879-8616-435f-bef2-4a84ae0d7989 - -
2019-01-14 17:43:39 [ip removed] DOMAIN\Username 192.168.1.2 21 STOR r4intake-general-testlname-testfname-1547487798.xml 550 4294967295 0 53e4f879-8616-435f-bef2-4a84ae0d7989 /r4intake-general-testlname-testfname-1547487798.xml -

Вот журнал попытки загрузки файла с помощью Filezilla (с моего домашнего IP). В STOR возвращается 226.

2019-01-14 17:47:49 [ip removed] DOMAIN\Username 192.168.1.2 21 TYPE A 200 0 0 808bb5b7-4e6a-4950-a204-f59a87f3d7b9 - -
2019-01-14 17:47:49 [ip removed] DOMAIN\Username 192.168.1.2 21 PORT xxx,xxx,xxx,xxx,214,2 200 0 0 808bb5b7-4e6a-4950-a204-f59a87f3d7b9 - -
2019-01-14 17:47:49 [ip removed] DOMAIN\Username 192.168.1.2 21 STOR r4intake-general-testlname-testfname-1547487999-full.xml 226 0 0 808bb5b7-4e6a-4950-a204-f59a87f3d7b9 /r4intake-general-testlname-testfname-1547487999-full.xml -

Тот же FTP-сервер, те же учетные данные, та же папка, тот же режим передачи - другой ответ.

Наблюдение:

Мы протестировали пять IP-адресов из белого списка. Команды выполняются с 2-мя и не работают с 3-мя из этих IP-адресов.

Из трех, которые потерпели неудачу, два принадлежат Digital Ocean (наш сервер LEMP и мой сервер OpenVPN), а один принадлежит известной коммерческой службе VPN.

Обычно я работаю со стеком LEMP и почти ничего не знаю о IIS, и у меня мало идей относительно того, в чем может быть причина.

Возможно ли, что IIS не нравятся определенные диапазоны IP-адресов (центр обработки данных, известные VPN и т. Д.), Или что какой-либо тип безопасности или групповая политика может влиять на способность определенных диапазонов IP-адресов читать / записывать в папку, несмотря на то, что сказал IP-адреса в белом списке для FTP-соединения?