FtpWebRequest работает с явным TLS / SSL

Question

Я пытаюсь передать файл через явный TLS / SSL.

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

Но если я отключил UserPassive, он выдаст «Сервер вернул адрес в ответ на команду PASV, который отличается от адреса, с которым было установлено FTP-соединение».и в соответствии с этим потоком:

Сервер возвратил адрес в ответ на команду PASV, который отличается от адреса, с которым было установлено FTP-соединение и

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=97409&wa=wsignin1.0 все еще не работает.

Кстати, если я точно знаю общедоступный IP-адрес и внутренний IP-адрес, могу ли я принять новый внутренний IP-адрес, чтобы он хотя бы работал?По первой ссылке все заработало, но я не понимаю, почему и как ему это удалось?что такое myProxyServerIP?Нужно ли иметь прокси-сервер?

Странная вещь, хотя мое приложение не может загрузить файл или каталог списка через ftp, но оно успешно удалит файл на сервере и выдаст код успеха?Я предполагаю, что мое приложение может только передавать / отправлять управляющий / командный код на ftp-сервер, но не может получить данные через другие порты с сервера?

Answer 1

Есть несколько вопросов, давайте попробуем ответить на них один за другим:

Почему удаление работает, а загрузка, загрузка и список - нет?

Протокол FTP использует два отдельных соединения. Первый (называется управляющее соединение ) используется для команд с простым ответом - таких как вход в систему, удаление, создание каталога и т. Д. Обычно он выполняется на порту 21.

Когда клиент FTP запрашивает операцию передачи данных, устанавливается другое соединение (называемое data data ). В активном режиме FTP-сервер подключается к клиенту, а в пассивном режиме клиент подключается к серверу. Если это соединение заблокировано брандмауэром, операция передачи данных завершится неудачно. Операции передачи данных: загрузка, загрузка, а также список каталогов Вот почему удаление работает, а список - нет.

Сервер возвратил адрес в ответ на команду PASV, отличный от адреса, с которым было установлено FTP-соединение

В пассивном режиме FTP-разговор происходит следующим образом:

client: PASV
(i would like to transfer files. Tell me which port and ip address should I use)

server: 227 Entering Passive Mode (172,16,3,4,204,173)
(ok, use port 52397 on IP address 172.16.3.4.)

client: connects to this IP address/port and starts data transfer.

Это может вызвать проблемы на FTP-серверах с несколькими IP-адресами. Я столкнулся с некоторыми FTP-серверами, которые имеют общедоступный IP-адрес (скажем, 1.2.3.4) и частный (192.168.2.3).

Когда FTP-клиент подключился к общему IP-адресу (1.2.3.4) и запросил операцию по передаче данных, сервер попросил его использовать частный IP-адрес (192.168.2.3). Это невозможно, потому что это был NAT.

Решение

Переключение в активный режим.

В активном режиме FTP-сервер подключается к FTP-клиенту для передачи данных. Это решило бы эту проблему, но не дружественно к брандмауэру. Он не будет работать, когда входящие комментарии заблокированы (очень часто).

Игнорирование IP-адреса, отправленного в ответ на команду PASV

Если общедоступный IP-адрес ftp-сервера является общедоступным, а IP-адрес, возвращаемый в ответ на команду PASV, относится к частному диапазону (например, 10. , 192.168. ). В таком случае клиент FTP должен использовать публичный IP-адрес.

Именно это и делает Rebex FTP в такой ситуации. Работает хорошо (такое поведение можно отключить). Я не знаю, возможен ли подобный обходной путь с FtpWebRequest.

Вы можете загрузить пробную версию и проверить, решает ли она вашу проблему.