Сервер отправил пассивный ответ с не маршрутизируемым адресом при подключении к FTP-сайту с помощью FileZilla
Я получаю сообщение об ошибке «Сервер отправил пассивный ответ с не маршрутизируемым адресом. Вместо этого используется адрес сервера». при подключении к FTP-сайту (не SFTP).
Я подключался к этому сайту много раз, однако FileZilla впервые попросила меня принять сертификат по этому поводу.
Это не похоже на проблему с учетной записью, с которой я подключаюсь, поскольку это происходит со всеми учетными записями на этом сервере.
Когда клиент инициирует передачу данных, он спрашивает FTP-сервер, куда ему подключиться. IP-адрес, который предоставляет ваш сервер, скорее всего, является его внутренним адресом в его сети, а не внешним IP-адресом, который может использоваться клиентом. Это неправильная конфигурация на стороне сервера.
Но поскольку это довольно распространенная ошибка в конфигурации, многие FTP-клиенты, включая FileZilla, могут ее исправить. Они просто игнорируют любой IP-адрес, предоставляемый сервером, если он не маршрутизируется из сетевого расположения клиента, и вместо этого используют адрес FTP-сервера. Вот что случилось.
См. Мой недавний ответ на объяснение архитектуры пассивного режима.
Что касается принятия сертификата: поскольку вы не сообщили нам, по какой причине FileZilla попросила вас принять сертификат, мы не можем вам помочь.
Это старый вопрос, но подумал, что он может помочь другим. У меня аналогичная проблема, о которой упоминал @HBrujin, у меня также указан правильный адрес pasv_address, но все еще отображается аналогичное сообщение в Filezilla.
Прежде всего узнайте, какой IP-адрес вы получаете в качестве команды PASV, включив режим отладки в FileZilla, и вы можете увидеть строку, как показано ниже
Response: 227 Entering Passive Mode (0,0,0,0,4,7).
Я надеялся, что мой публичный адрес вместо 0.0.0.0, так как я уже указал pasv_address. Позже понял, что это было из-за настройки listen_ipv6 = YES, а у pasv_address IP4. Просто добавьте конфигурацию изменений в
#listen_ipv6=YES
listen=YES
решил мою проблему.
На первый взгляд это выглядит как проблема NAT из-за сбоя помощника протокола FTP из-за шифрования TLS, и я ожидал, что это также станет проблемой брандмауэра.
Некоторый фон Вот в более старом моем ответе.
Решение, вероятно, состоит в том, чтобы исправить диапазон пассивных портов TCP, который может использовать FTP через SSL, чтобы FTP-сервер объявлял внешний IP-адрес, а не фактический IP-адрес ( pasv_address директиве VSFTPD) и создать статические правила NAT для этих портов.