Я настроил 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 - Explicit, 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.
Я читал что-то о проблемах с FTPS и NAT, но не совсем уловил
Ах, в этом больше смысла. Проблема здесь в двухканальном характере FTP, плюс шифрование, плюс (скорее всего) адаптивный межсетевой экран. по пути.
Когда управляющее соединение FTP запрашивает некоторые данные (включая список каталогов), создается новое соединение; от сервера к клиенту в АКТИВНОМ режиме (что редко) или от клиента к серверу в ПАССИВНОМ режиме (что чаще).
Детали этого соединения согласовываются по каналу управления, новое соединение открывается в направлении, соответствующем режиму, а затем данные передаются (я предполагаю, что это ПАССИВНЫЙ режим для остальной части этого ответа; все аналогично, но даже сложнее, если вы пытаетесь использовать АКТИВНЫЙ режим).
Если только там установлен брандмауэр. Если брандмауэр не разрешает произвольные TCP-соединения изнутри наружу, канал данных не может быть построен.
Если только брандмауэр умен и наблюдает за потоком управляющих данных, ища FTP PORT команда, которая является предшественником создаваемого канала данных. Затем умный брандмауэр откроет временное разрешение и / или сопоставление портов на время этого канала данных. Это часто называют адаптивный межсетевой экран.
Если только канал управления зашифрован сквозным шифрованием, и в этом случае межсетевой экран не знает, что канал данных согласован, и временные разрешения не могут быть предоставлены.
Имеет ли это смысл? По сути, использование SSL, скорее всего, мешает вашему брандмауэру знать, что он должен быть умным в этом отношении, поэтому он работает без SSL в офисе и отлично работает из дома, где у вас, вероятно, нет такого сложного брандмауэра.
Единственный способ заставить это работать из офиса без потери шифрования - это заставить администратора брандмауэра разрешать вам создавать произвольные исходящие TCP-соединения с вашего рабочего стола на ftp-сервер.