Назад | Перейти на главную страницу

IIS 7.5 на Windows Server 2008 R2 отказывается создавать FTP-подключения в ПАССИВНОМ РЕЖИМЕ

Я пытаюсь получить FTP-клиент, написанный на perl, для передачи файлов с FTP-сервера IIS 7.5 в пассивном режиме.

Я настроил FTP-сервер в соответствии с инструкциями, а также настроил брандмауэр Windows, чтобы разрешить этот тип трафика. Я проверил правильность работы брандмауэра, проверив, нет ли заблокированных пакетов в журналах. Я убедился, что канал управления FTP открывается на порту 21.

Я считаю, что IIS сообщает клиенту, к какому порту подключаться в пассивном режиме, а IIS отказывается разрешить это соединение.

Журнал perl выглядит так:

C:\cygwin\Perl\lib\FMT>perl FTPTest.pl
Net::FTP>>> Net::FTP(2.77)
Net::FTP>>>   Exporter(5.64_01)
Net::FTP>>>   Net::Cmd(2.29)
Net::FTP>>>   IO::Socket::INET(1.31)
Net::FTP>>>     IO::Socket(1.31)
Net::FTP>>>       IO::Handle(1.28)
Net::FTP=GLOB(0x20abac0)<<< 220 Microsoft FTP Service
Net::FTP=GLOB(0x20abac0)>>> USER ftpuser
Net::FTP=GLOB(0x20abac0)<<< 331 Password required for ftpuser.
Net::FTP=GLOB(0x20abac0)>>> PASS ....
Net::FTP=GLOB(0x20abac0)<<< 230 User logged in.
Net::FTP=GLOB(0x20abac0)>>> CWD /Logs
Net::FTP=GLOB(0x20abac0)<<< 250 CWD command successful.
Net::FTP=GLOB(0x20abac0)>>> PASV
Net::FTP=GLOB(0x20abac0)<<< 227 Entering Passive Mode (xx,xxx,xxx,xxx,160,41).
Net::FTP=GLOB(0x20abac0)>>> RETR filename.txt
Can't use an undefined value as a symbol reference at C:/Utilities/strawberryper
l/perl/lib/Net/FTP/dataconn.pm line 54.

Журналы IIS выглядят следующим образом:

2010-10-02 17:40:06 xx.xxx.xx.xx - yy.y.yy.yy ControlChannelOpened - - 0 0 27a48c9b-9dce-4770-8bcf-fc89f2569b1a - -
2010-10-02 17:40:06 xx.xxx.xx.xx - yy.y.yy.yy USER ftpuser 331 0 0 27a48c9b-9dce-4770-8bcf-fc89f2569b1a - -
2010-10-02 17:40:06 xx.xxx.xx.xx MACHINENAME\ftpuser yy.y.yy.yy PASS *** 230 0 0 27a48c9b-9dce-4770-8bcf-fc89f2569b1a / -
2010-10-02 17:40:06 xx.xxx.xx.xx MACHINENAME\ftpuser yy.y.yy.yy CWD /Logs 250 0 0 27a48c9b-9dce-4770-8bcf-fc89f2569b1a /Logs -
2010-10-02 17:40:06 xx.xxx.xx.xx MACHINENAME\ftpuser yy.y.yy.yy PASV - 227 0 0 27a48c9b-9dce-4770-8bcf-fc89f2569b1a - -
2010-10-02 17:40:27 - MACHINENAME\ftpuser zz.z.zz.zzz 41001 DataChannelClosed - - 64 0 27a48c9b-9dce-4770-8bcf-fc89f2569b1a - -
2010-10-02 17:40:27 xx.xxx.xx.xx MACHINENAME\ftpuser yy.y.yy.yy ControlChannelClosed - - 64 0 27a48c9b-9dce-4770-8bcf-fc89f2569b1a - -
2010-10-02 17:40:27 xx.xxx.xx.xx MACHINENAME\ftpuser yy.y.yy.yy RETR filename.txt 550 1236 0 27a48c9b-9dce-4770-8bcf-fc89f2569b1a filename.txt -

Нам удалось увидеть эту проблему и с другими FTP-клиентами, я не думаю, что это что-то смешное в Perl. Мне сообщили, что это нормально работает на FTP-сервере IIS 6. Мне интересно, что-то нам здесь не хватает.

Я встречал похожие проблемы с другим программным обеспечением ftp-серверов.

вам может потребоваться сопоставление портов, если ваш ftp-сервер находится за NAT. вам также может потребоваться проверить порт, который сервер использовал для пассивного режима, и сопоставить его. Также проверьте брандмауэр, что эти порты разрешены.

У меня была такая же проблема. IIS FTP 7.5 настроен по умолчанию, чтобы разрешить только АКТИВНЫЙ FTP, а не пассивный, я считаю - по крайней мере, в двух установках по умолчанию, которые я сделал. Возможно, ваш скрипт на этом зацикливается. Веб-сайт IIS http://learn.iis.net/page.aspx/309/configuring-ftp-firewall-settings/ мне очень помогло - хотя моя проблема была с обычным FTP-клиентом (filezilla), а не с PERL, он должен применяться в этом случае. Обратите особое внимание на Шаг 3: Настройка параметров брандмауэра Windows.

Попробуйте использовать редактор конфигурации IIS, перейдите в System.applicationHost / sites -> siteDefaults -> ftpServer-> security-> dataChannelSecurity и отключите matchClientAddressForPort и matchClientAddressForPasv. Это было моим исправлением при переходе с IIS 6 на IIS 7.5.

У меня была такая же проблема с Perl-скриптом. Я подключался с частного IP-адреса. В пассивном режиме публичный IP-адрес возвращается при выполнении команды PASV! Решение заключалось в установке Passive => 0 для использования активного режима внутри брандмауэра и использования Passive => 1 вне брандмауэра.