Подключение к пассивному FTP через SSL (ftps)

Я настроил службу FTP в Windows Azure, используя это руководство http://www.itq.nl/blogs/post/Walkthrough-Hosting-FTP-on-IIS-75-in-Windows-Azure-VM.aspx

FTP-сервер работает хорошо, когда я подключаюсь без SSL, когда я работаю за своим офисным брандмауэром.

НО, когда я пытаюсь соединиться с SSL (порт 21, AUTH TLS - явный, CuteFTP), я получаю тайм-аут. Когда я делаю точно так же дома, соединение работает (SSL). Что я делаю неправильно? Использует ли SSL-соединение другие порты?

Аутентификация работает нормально, когда клиент отправляет команду LIST, время ожидания истекло

STATUS:>    [11.02.2013 12:56:28] Using UTF-8.
STATUS:>    [11.02.2013 12:56:28] This site can resume broken downloads.
COMMAND:>   [11.02.2013 12:56:28] REST 0
        [11.02.2013 12:56:28] 350 Restarting at 0.
COMMAND:>   [11.02.2013 12:56:28] PBSZ 0
        [11.02.2013 12:56:28] 200 PBSZ command successful.
COMMAND:>   [11.02.2013 12:56:28] PROT P
        [11.02.2013 12:56:28] 200 PROT command successful.
COMMAND:>   [11.02.2013 12:56:28] PASV
        [11.02.2013 12:56:28] 227 Entering Passive Mode (***,**,**,201,27,92).
COMMAND:>   [11.02.2013 12:56:28] LIST
STATUS:>    [11.02.2013 12:56:28] Connecting FTP data socket... ***.**.**.201:7004...
ERROR:>     [11.02.2013 12:56:49] The connection failed due to an error or timeout.

Я читал что-то о проблемах с FTP S и NAT, но не совсем понял

Источник

1 ответ

Решение

Ах, это имеет больше смысла. Проблема здесь заключается в двухканальной природе FTP, плюс шифрование и (скорее всего) адаптивный межсетевой экран в пути.

Когда управляющее соединение FTP запрашивает некоторые данные (включая список каталогов), происходит следующее: создается новое соединение; от сервера к клиенту в режиме ACTIVE (что является редкостью) или от клиента к серверу в режиме PASSIVE (что более распространено).

Детали этого соединения согласованы по каналу управления, новое соединение открывается в направлении, соответствующем режиму, и затем данные передаются (я буду считать, что это режим PASSIVE для остальной части этого ответа; все аналогично, но еще сложнее, если вы пытаетесь использовать режим ACTIVE).

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

Если брандмауэр не умен и не наблюдает за потоком данных управления, ищет FTP PORT команда, которая является предшественником строящегося канала данных. Затем умный брандмауэр откроет временное разрешение и / или отображение порта на время этого канала данных. Это часто называют адаптивным межсетевым экраном.

Если канал управления не является сквозным зашифрованным, в этом случае брандмауэр не имеет представления о том, что канал данных согласовывается, и временные разрешения не могут быть предоставлены.

Имеет ли это смысл? По сути, использование вами SSL, скорее всего, не позволяет вашему брандмауэру узнать, что ему следует с этим разобраться, поэтому он работает без SSL в офисе и отлично работает из дома, где у вас, вероятно, нет такого сложного брандмауэра.

Единственный способ заставить это работать из офиса без снятия шифрования - это заставить администратора брандмауэра разрешить вам устанавливать произвольные TCP-соединения, исходящие с вашего рабочего стола на ftp-сервер.

Источник
Другие вопросы по тегам