Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
по FTPS переслать файлы на сервер клиента. При условии, что роутер клиента в качестве ответа при подключении по FTPS выдаёт внутренний IP.
Это что, и клиент, и сервер - оба за NAT'ом?.. И сервер не поддерживает подстановку публичного IP для passive mode?
Они, чтобы решить проблему, смотрели видео, а не запустили вайршарк и за секунду все поняли. Зачем вы такие сложные вопросы задаете :)
ну вайршарк тут вряд ли поможет, скорее фиддлер (хотя не уверен, умеет он вкрывать что-то, кроме http(s)). Но вообще всё видно в логе самого ftp-клиента - это сервер отдаёт неправильный ip для пассив моды, или наоборот - клиент неправильный ip для активной. Для особо "одарённых" случаев после аутентификации можно включать шифрование на управляющем соединении (ну по крайней мере в стандарте это есть), и тогда "вумные" файрволы сами всё поправят в потоке управляющего соединения.
Чисто теоретически даже curl должен уметь соединяться по FTPS и по ключам -vvv выводить все что знает в дебаг-режиме.
Ждём следующую статью про пользу WireShark в решении относительно простых повседневных задач.
Зря вы так язвите - иногда получается долго тупить и при "решении простых повседневных задач" и проще реально снять дамп и посмотреть что там пересылается по факту.
Ну если каждый новичок будет публиковать на хабр статью о том, что его программа падала раз в неделю, но он добавил в код оператор delete, и всё заработало, то тут будет русскоязычный аналог Reddit.
Было бы интересно почитать про то, как автор изучил исходные коды всех предлагаемых в Python библиотек, не нашел там решение, внёс изменения, чтобы добиться решения, или написал полностью свою библиотеку. Но нет, посмотрели видео, отключили верификацию сертификатов, нашли утилиту, которая работает из коробки, дали рекламу на свой канал в Телеге.
Это честная работа, но на статью на хабре не тянет, КМК.
Проблема была ясна — нужно было лишь найти FTP-клиент, который эту задачу решал бы также, как это получалось через FileZilla. Через FileZilla мы как раз и узнали про неверный IP в ответе сервера. Вайршарк был бы излишеством.
Посыл статьи в том, что не все FTP-клиенты для Python могут решать задачи с некоторыми трудными серверами
Посыл статьи в том, что не все FTP-клиенты для Python могут решать задачи с некоторыми трудными серверами
Вайршарк был бы излишеством.
Действительно, можно и в tcpdump посмотреть было.
вот только вряд ли бы он что-то показал в случае ftpS :) Потому что control connection зашифрован.
Но вот есть вместо PASV дать серверу EPSV (оч странно было бы, если бы сервер умел TLS, но не умел EPSV/EPRT), то в ответе с хорошей вероятностью IP-адреса бы не было, только порт, что решило бы проблему.
Насколько мы поняли — FileZilla умеет поправлять IP, который используется в подключении, а у заказчика стоял FTP-сервер, который этого не делал. Может быть, что у них там какая-то защита стояла, может быть Файрволл, может быть что-то ещё. По их регламенту — они нам этого не говорили, исходные данные были только такие: «Вот ваш логин, пароль, а вот наш айпи и порт».
А был он за NAT'ом или нет — не ясно. Главное то, что LFTP умеет решать эту проблему и мы смогли это автоматизировать хотя бы на уровне Bash
А был он за NAT'ом или нет — не ясно. Главное то, что LFTP умеет решать эту проблему и мы смогли это автоматизировать хотя бы на уровне Bash
Так библиотеки тоже умеют. Другой вопрос, пыталися ли вы включить нужные режимы?
а EPSV сервер поддерживает, или только PASV?
Скорее всего не поддерживает EPSV, отдельно протестил использование EPSV: от сервера нет отклика. Использовал ftplib.
Несмотря на то, что «проблема известная» (как пишут в комментариях), решения никто не предложил (в тех статьях, да ещё которые работали бы, я имею в виду). А статья рассказывает про LFTP-утилиту для Linux — вот она работает.
Подробности настроек FTP-сервера нам не сообщали.
Несмотря на то, что «проблема известная» (как пишут в комментариях), решения никто не предложил (в тех статьях, да ещё которые работали бы, я имею в виду). А статья рассказывает про LFTP-утилиту для Linux — вот она работает.
Подробности настроек FTP-сервера нам не сообщали.
Нет, сервер не даёт отклика при использовании passive mode. Статья именно потому и написана, потому что всё давалось очень тяжело.
А проблема была в том, что SSL-сертификат не проходил верификацию. Наверное, он просто самоподписанный.
Эту проверку можно отключить везде, включая питоновский ftplib.
Задача: по FTPS переслать файлы на сервер клиента. При условии, что роутер клиента в качестве ответа при подключении по FTPS выдаёт внутренний IP.
Да, это частая проблема при запуске FTP-сервера с параметрами по-умолчанию. Древнючий FTP-протокол был разработан задолго до NAT. Проблема известная.
Вот это не решает вашу проблему?
Мы бы не смогли дойти до такого описания проблемы, потому что:
Все ftp-клиенты для Пайтона при подключении просто зависали. Там ни ответа, ни привета.
Было прочитано с сотню статей, куча документации и огромный стейк видео был пересмотрен.
Вы, конечно, простите за прямоту. Но у меня поиск в гугл по простому запросу "python ftps" выводит уже вторым результатом (первым - ссылка на офсайт ftplib) ссылку на описание именно этой проблемы (если это была единственная проблема). Сложно поверить что в "сотне статей" не было хотя бы намека на это.
Опять же - это действительно широко известная проблема, которая, в общем-то, изначально сводится к неправильному углу искривления рук админов того сервера. При запуске с дефолтными параметрами ftp-сервер берет единственный известный ему ip-адрес и начинает его отдавать в ответе на PASV команду. Достаточно прописать в конфиге правильный внешний адрес - и все должно заработать, но я вас понимаю в этом - у меня тоже был такой FTP сервер, который никто для меня не стал менять и мне пришлось чинить таким костылем. Это, действительно, костыль - сервер работает четко по спецификации (протоколу 50 лет), клиенты (Python) тоже обязаны по-умолчанию работать по спецификации.
Проверил всё то, что обсуждалось в комментариях:
1. PASV мы пробовали, и я протестил ещё раз — нет, это не решает проблему, от сервера нет отклика.
2. EPSV — тоже никакого толка, протестил — никакого отклика.
Как настроен сервер и с чем мы столкнулись — в принципе сейчас не важно, потому что статья предлагает работающее решение — LFTP-утилита для Linux
1. PASV мы пробовали, и я протестил ещё раз — нет, это не решает проблему, от сервера нет отклика.
2. EPSV — тоже никакого толка, протестил — никакого отклика.
Как настроен сервер и с чем мы столкнулись — в принципе сейчас не важно, потому что статья предлагает работающее решение — LFTP-утилита для Linux
PASV мы пробовали, и я протестил ещё раз — нет, это не решает проблему, от сервера нет отклика.
Нет отклика до PASV, нет ответа на PASV или после? Сложно что-то советовать поскольку вы не описываете проблему совсем.
Смотрите: сервер отвечает на PASV своим адресом/портом. У вас был этот ответ? Там был адрес тот же что вы использовали при коннекте?
У lftp есть режим "verbose", в котором он вам покажет что он посылает на сервер и что получает. Если сравнить этот вывод с тем что отправлял ваш скрипт на питоне - можно понять что идет не так. Вы сравнивали?
В принципе, из статьи непонятно какую проблему вы решали, поэтому можно выкинуть из нее все и оставить только "у нас не заработало, мы взяли lftp и заработало".
Ваша статья очень похожа на многие другие из серии "я долго ковырялся, ничего не понял, приделал костыль, напишу на хабр". Для себя вы решили - ок. Другим показывать такое решение - ну не очень оно красивое для этого.
1. PASV мы пробовали, и я протестил ещё раз — нет, это не решает проблему, от сервера нет отклика. 2. EPSV — тоже никакого толка, протестил — никакого отклика.
Оч интересно. Если не работают ни PASV, ни EPSV, то работают только PORT/EPRT и, самое интересное - сервер устанавливает data connection в сторону клиента. Как следствие - сервер в приниципе не передаёт клиенту "неправильный" IP-адрес, роутер/файрвол на стороне сервера не причём, неправильный IP-адрес передаёт серверу сам ftp-клиент. Причём это проблема в случае, если ftp-клиент находится за NAT'ом (и не только потому, что серверу уходит неправильный IP-адрес клиента, а потому что роутер на стороне ftp-клиента должен догадаться, куда пробросить соединение с 20-го порта сервера - в обычной ситуации он может это сделать анализируя control connection, но в случае FTPS это ему обломали)
Что вступает в диссонанс с "по FTPS переслать файлы на сервер клиента. При условии, что роутер клиента в качестве ответа при подключении по FTPS выдаёт внутренний IP."
Т.е. совершенно не понятно, в чём заключается у вас проблема и за счёт чего её решили? Просто "магия: пробовали всё подряд, и вот это заработало непонятно почему"
Да ну, скорее всего PASV возвращает какой-то внутренний адрес, клиент на него лезет и долго пытается открыть соединение что и выглядит как "просто зависали. Там ни ответа, ни привета". Сделайте `telnet 192.168.34.56 20` (случайный адрес) и будет то же самое - "Trying ..." долго висит и если повезет - вернет таймаут.
Я не автор, но для меня ответ очевиден - потому что такой сервер был предоставлен вендором. Обычно приходится работать с тем что дают.
Мне по работе тоже приходится собирать данные с нескольких серверов от разных поставщиков. Каждый раз это лотерея - FTP/SFTP/FTPS/SSH - и каждый раз что-то новое: то древнючие шифры на сервере при установке соединения, то нестандартные порты или левые сертификаты, то кривая конфигурация сервера. То 40к файлов лежит в папке, прав на удаление нет и при каждой попытке найти новые файлы все падает по таймауту..
Например, поставщик данных - национальный оператор электроэнергии. Никто не собирается под запросы какого-то мелкого клиента менять настройки уже установленного 5 лет назад сервера. Крутись как хочешь.
Заказчик использовал FTPS-сервер, потому что это их внутренний регламент. А такие правила не меняются для кого-то или под кого-то.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы автоматизировали FTP(S) с уникальными симптомами проблемы?