Превышено время ожидания соединение потока комманд копирование файлов на сервер не удалось
когда подключаюсь к хостингу через smart ftp всё работает, но через filezilla пишет:
Статус: Определение IP-адреса для ftp.buildic2craft.hol.es
Статус: Соединяюсь с 31.170.164.119:21.
Статус: Соединение установлено, ожидание приглашения.
Ответ: 220----------Welcome to Pure-FTPd [privsep] [TLS] ----------
Ответ: 220-You are user number 9 of 500 allowed.
Ответ: 220-Local time is now 08:53. Server port: 21.
Ответ: 220-This is a private system - No anonymous login
Ответ: 220 You will be disconnected after 3 minutes of inactivity.
Команда: AUTH TLS
Ошибка: Соединение прервано пользователем
Статус: Отключен от сервера
Статус: Определение IP-адреса для ftp.buildic2craft.hol.es
Статус: Соединяюсь с 31.170.164.119:21.
Статус: Соединение установлено, ожидание приглашения.
Ответ: 220----------Welcome to Pure-FTPd [privsep] [TLS] ----------
Ответ: 220-You are user number 9 of 500 allowed.
Ответ: 220-Local time is now 08:54. Server port: 21.
Ответ: 220-This is a private system - No anonymous login
Ответ: 220 You will be disconnected after 3 minutes of inactivity.
Команда: AUTH TLS
Ошибка: Соединение прервано после 20 секунд неактивности
Ошибка: Невозможно подключиться к серверу
Статус: Ожидание повтора.
Статус: Определение IP-адреса для ftp.buildic2craft.hol.es
Статус: Соединяюсь с 31.170.164.119:21.
Статус: Соединение установлено, ожидание приглашения.
Ответ: 220----------Welcome to Pure-FTPd [privsep] [TLS] ----------
Ответ: 220-You are user number 8 of 500 allowed.
Ответ: 220-Local time is now 08:54. Server port: 21.
Ответ: 220-This is a private system - No anonymous login
Ответ: 220 You will be disconnected after 3 minutes of inactivity.
Команда: AUTH TLS
---------------------------------------------------------
smart ftp медленный, а filezilla быстрый. он раньше работал!
Проблема решена. Я зашел в менеджер сайтов и там поставил использовать обычный FTP (небезопасно) потом запросить пароль и пассивный режим!
При работе с GUI и терминальными приложениями нередко случается, что пользователь, работая в режиме удаленного доступа (как правило, через Интернет), покинув компьютер минут на 15, по возвращении обнаруживает, что программа зависла. На любое действие она отвечает ошибкой, содержащей примерно такие фразы: «Потеряна связь с сервером», "[WINSOCK] virtual circuit reset by host" и т.п. Наблюдается такое и при выполнении «долгоиграющих» методов (запросов к серверу), в которых не предусмотрен вывод прогресс-бара или какая-либо интерактивность.
Ниже о том, как можно решать эту проблему без программирования.
Источник проблемы
Экспериментально установлено, что интервал очистки у многих маршутизаторов (по крайней мере, с прошитым Linux 2.4/iptables) составляет около 10 минут. Постараемся заставить наш TCP-сеанс автоматически поддерживать себя в активном состоянии, даже когда не передается никаких пакетов с данными.
Предлагаемое решение
На уровне ОС обнаружением разорванных TCP-соединений управляют следующие параметры ядра, управляющие работой механизма tcp_keepalive [1]:
• tcp_keepalive_time — интервал времени с момента отправки последнего пакета с данными; по истечении этого срока соединение помечается как требующее проверки; после начала проверки параметр не используется;
• tcp_keepalive_intvl — интервал между проверочными пакетами (отправка которых начинается по истечении tcp_keepalive_time);
• tcp_keepalive_probes — количество неподтвержденных проверочных пакетов; по исчерпании этого счетчика соединение считается разорванным.
Надо сказать, что механизм tcp_keepalive имеет двойное назначение: он может использоваться как для искусственного поддержания активности соединения, так и для выявления разорванных (так называемых «полуоткрытых») соединений. В данной статье обсуждается в основном первое применение, о втором применении, возможно, речь пойдёт в следующей статье на эту тему.
Для того чтобы механизм tcp_keepalive был задействован для TCP-соединений, необходимы два условия:
• поддержка на уровне ОС; к счастью, и в Windows, и в Linux она имеется;
• на одном из концов соединения сокет должен быть открыт с параметром SO_KEEPALIVE. Как оказалось, сервисы Caché открывают сокеты с этим параметром, а сервис OpenSSH несложно заставить поступать аналогично.
Наибольший интерес для нас представляет первый параметр (tcp_keepalive_time), так как именно от него зависит, насколько часто будет выполняться проверка неактивных (с точки зрения отсутствия трафика) соединений. Его значение по умолчанию — и в Windows, и в Linux — равно двум часам (7200 с). Типичное же время бездействия, после которого наступает разрыв, составляет около 10 минут. Поэтому предлагается установить значение параметра в 5 минут, что позволит искусственно поддерживать активность TCP-сеансов, не перегружая сеть избыточным трафиком (5 минут — это не 5 секунд).
Установка параметров tcp_keepalive на сервере Windows
Вы должны обладать правами Администратора к серверу. В разделе реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
создайте параметр DWORD с именем KeepAliveTime и значением 300000 (десятичным). Параметр задаётся в миллисекундах, поэтому предлагаемое значение — это 5 минут. После чего остановите Caché и перезагрузите сервер.
Что касается двух других параметров tcp_keepalive, то их умолчания в Windows таковы:
KeepAliveInterval
Key: Tcpip\Parameters
Value Type: REG_DWORD—time in milliseconds
Valid Range: 0–0xFFFFFFFE
Default: 1000 (1 секунда)
KeepAliveProbes
Такого параметра (устанавливающего количество неподтвержденных проверочных пакетов), в реестре не существует. Согласно [2], в Windows 2000 / XP / 2003 в этом качестве используется значение параметра TcpMaxDataRetransmission (умолчание — 5), а в более поздних версиях [3] — фиксированное значение, равное 10. Поэтому, если менять только значение первого параметра (с 7200 на 300), сохраняя умолчание для второго, сервер Windows 2008 будет узнавать о разрыве TCP-соединения через 1*10 + 300 = 310 секунд.
Установка параметров tcp_keepalive на сервере Linux
Изменить значения параметров можно «на ходу», не перезагружая сервер. Зайдите как root и выполните:
Чтобы сделать изменение долговечным по отношению к возможным перезагрузкам сервера, проще всего отредактировать файл параметров ядра /etc/sysctl.conf, добавив в него строку (лучше две):
Обратите внимание, что в отличие от Windows, значение параметра задается в секундах.
Что касается остальных двух параметров tcp_keepalive, то их умолчания в Linux таковы:
Если менять только значение первого параметра (с 7200 на 300), сохраняя умолчания для остальных двух, сервер Linux будет узнавать о разрыве соединения только через 75*9 + 300 = 975 секунд.
Установка параметра TCPKeepAlive в конфигурации СУБД Caché
Начиная с версии 2008.2, в Caché для платформ Windows и Linux появилась возможность задавать tcp_keepalive_time на уровне сокета, что удобно, так как позволяет избежать изменения настроек операционной системы. Однако «в чистом виде» эта возможность, в основном, представляет интерес лишь для независимых разработчиков сокет-серверов. К счастью, она была дополнена параметром конфигурации TCPKeepAlive=n в секции [SQL], доступным для редактирования со страницы Портала управления системой: Конфигурация > Общие Настройки SQL. Значение по умолчанию — 300 секунд (то, что доктор прописал). Действие параметра распространяется не только на SQL, но и, как нетрудно догадаться, на любые соединения с Caché, обслуживаемые сервисом %Service_Bindings. К ним относится, в частности, и объектный доступ через CacheActiveX.Factory, поэтому если ваше приложение может использовать этот протокол в качестве транспорта, не стоит упускать такую возможность.
Установка параметров KeepAlive в конфигурации сервера OpenSSH
Если вы используете SSH [4] (для работы в режиме командной оболочки или как транспорт для вашего GUI-приложения), то… скорее всего, проделанной настройки ядра будет достаточно, поскольку сервис OpenSSH (по крайней мере, в версии 5.x) по-умолчанию открывает сокет с параметром SO_KEEPALIVE.
На всякий случай стоит проверить конфигурационный файл /etc/ssh/sshd_config. Найдите в нем строку
Если нашли, то делать ничего не надо, так как значения параметров по умолчанию предоставляются в закомментированном виде.
Протокол SSH v.2 имеет альтернативные средства контроля активности сеансов, например, с помощью настройки параметров сервиса OpenSSH ClientAliveInterval и ClientAliveCountMax.
При использовании этих параметров, в отличие от TCPKeepAlive, запросы KeepAlive отправляются через защищённый SSH канал и не могут быть подменены. Приходится признать, что альтернативные средства являются более безопасными, нежели традиционный механизм TCPKeepAlive, для которого существует опасность анализа KeepAlive-пакетов и организации DoS-атак [5].
Устанавливает время ожидания в секундах, по истечении которого, если не поступает информация со стороны клиента, sshd отправляет ему запрос отклика через защищённый канал. По умолчанию используется 0, что означает, что клиенту не будет направлен такой запрос.
Устанавливает количество запросов клиенту, которые могут быть отправлены sshd без получения на них отклика. Если предел достигнут, sshd разъединяется с клиентом и завершает сеанс. Значение по умолчанию: 3. Если вы установите значение параметра ClientAliveInterval равным 60, оставив ClientAliveCountMax без изменений, то не отвечающие ssh-клиенты будут отключены примерно через 180 секунд. При этом следует отключить механизм TCP KeepAlive, установив
Всегда ли это работает?
Существуют категории сетевых проблем, в которых описанный подход может быть малоэффективен.
Одна из них имеет место, когда из-за низкого качества сетевого обслуживания связь может физически пропадать в течение коротких промежутков времени. Если сеанс бездействует, а связь временно пропадает и восстанавливается до того, как клиент или сервер попытаются что-то друг другу послать, то никто из них ничего «не замечает», и TCP-сеанс сохраняется. В случае периодических проверок TCPKeepAlive возрастает вероятность обращения сервера к клиенту в моменты временного исчезновения связи, что может вести к принудительным разрывам TCP-соединения. В такой ситуации можно попробовать увеличить на сервере KeepAliveInterval до 60-75 секунд (вспомнив, что в Windows умолчание — 1 секунда) при максимальном количестве повторов равным 10, в надежде, что за 10 минут любая временная сетевая проблема самоустранится. Правда, если повторные передачи будут длиться слишком долго, и окажется, что
KeepAliveTime + (KeepAliveInterval * кол-во_повторов) > 10 минут
то TCP-сеанс, несмотря на все предпринятые усилия, может быть принят за «мёртвый» и вычищен из NAT-таблицы.
Другая категория проблем связана с недостаточной пропускной способности используемых маршрутизаторов и/или каналов связи, когда при перегрузке могут теряться любые пакеты, в том числе и KeepAlive. В случае маршрутизаторов такие проблемы иногда решаются сменой прошивки (мне, например, это помогло победить Acorp ADSL XXXX), или, в худшем случае, заменой его на более производительную модель. В случае «слишком узких» каналов связи не остаётся ничего другого, кроме как их расширять.
Заключение
Предложенный подход позволяет искусственно поддерживать активность сеансов TCP/IP, по которым в текущий момент не передается никаких данных, исключительно на системном уровне, не внося каких-либо изменений в прикладной код. На сегодня он проверен и успешно используется в Caché for UNIX (Red Hat Enterprise Linux 5 for x86-64) 2010.1.4 (Build 803), Caché for Windows (x86-64) 2010.1.4 (Build 803), а также в более поздних версиях.
Следует признать, что он эффективно работает, если сетевое соединение физически устойчиво, и кроме разрыва неактивных сеансов других сетевых проблем у вас нет.
При развёртывании приложения в агрессивной среде (удалённый доступ, распределённые системы и т.д.), подумайте о реализации KeepAlive не на уровне TCP, а на уровне защищённого протокола более высокого уровня; хорошим кандидатом здесь оказывается SSH.
Литература
[1] Fabio Bussato. TCP Keepalive HOWTO
[2] How to harden the TCP/IP stack against denial of service attacks in Windows Server 2003
[3] TCP/IP Registry Values for Microsoft Windows Vista and Windows Server 2008
[4] Интерактивная система просмотра системных руководств (man-ов)
[5] OpenSSH: установка и конфигурирование sshd
Итак, всё тот же сервер на Gentoo 3.7.10-r1 x86_64. FTP-сервер работает как надо, но довольно часто без объяснения причин при передаче уходит в таймаут и отваливается.
Лог FileZilla обычно такой:
Причём, подобная ошибка была и у proftpd, но после замены на pure-ftpd она никуда не делась. Сейчас стоит последний.
Конфиг у него самый стандартный:
В какую сторону рыть?
Коннект отваливается по таймауту. Смотри роутеры-файрволлы и т.п. ФТП сервер тут не причем я думаю.
Любопытно, что схожую проблему я припоминаю ещё когда у меня была другая комплектуха и стоял Archlinux. Значит, дело действительно может быть в роутере. Но, вот незадача, почему по SFTP копируются десятки тысяч файлов без проблем?
это другой протокол, если не можешь разобраться как работает FTP, запусти tcpdump и посмотри что куда ходит, вероятно у тебя часть пассивных портов закрыта, нужно задать диапазон в конфиге ftp севера или найти дефолтные параметры, и открыть их на роутере/фаерволе/etc
да и еще попробуй диапазон пассивных портов повыше подвинуть, выше 1024 хотя бы
dGhost ★★★ ( 12.05.13 12:01:15 )
Последнее исправление: dGhost 12.05.13 12:06:24 (всего исправлений: 1)
При этом по SFTP (OpenSSH) всё работает безупречно.
А при чем здесь это? Ты бы еще удивился тому, что на той же машине успешно работает, например, вебсервер.
Посмотри настройки keep-alive на клиенте, если не поможет, тогда, видимо, действительно глюки.
ЗЫ. Возможно, ты таки путаешь SFTP (SSH) и FTPS (FTP+TLS|SSL)
thesis ★★★★★ ( 12.05.13 12:02:08 )
Последнее исправление: thesis 12.05.13 12:03:46 (всего исправлений: 1)
Да, любопытно. Дело, похоже, действительно не в сервере. Ибо когда подключаюсь по 192.168.1.хх, всё работает как надо. Как только через внешний IP — отвалы.
Роутер как только сейчас ни настраивал: и полностью защиту отрубал, и брендмауэр отключал — бесполезно.
Посмотрел с помощью tcpdump'a, дисконнекту по таймауту предшествуют такие пакеты:
thesis , нет, я написал всё верно — по 22 порту у меня идёт OpenSSH с возможностью подключения по нему SFTP\PuTTY.
Если у тебя роутер снаружи пробрасывает порты, то возможно для пассивных соединений он это делает криво. Что за роутер?
Ну тогда я тоже написал то, что хотел: непонятно, какую ценность представляет информация о работающем демоне SSH в контексте рассматриваемой проблемы о неработающем FTP.
Ну да неважно.
Я предполагал у тебя такой сценарий: сервер оценивает активность клиента по движаниям на управляющем порту, поэтому, пока идет пересылка данных, сервер успевает решить, что клиент отвалился. Раньше такое встречалось. Если у тебя мелкие файлы и / или высокая скорость передачи / настрены частые keep-aliv'ы, то это не твой случай, но я бы перепроверил, перед тем, как окончательно обвинить роутер.
Роутер — NetGear WNR3500L (v1), прошивка стандартная, версия ПО V1.2.2.44_35.0.53.
Всем привет! Вопрос больше не линуксовый, а сетевой. Поменял интернет-провайдера. После чего netbeans и filezilla перестали закачивать файлы на удаленый сервак по sftp. Причем по ssh подключаюсь, могу ходить по директориям, работать себе спокойно. Могу даже подмонтировать удаленый раздел sshfs'ом. Но загрузить уже в него ничего не могу. Трассировка в сторону сервака:
Трассировка с сервака назад, домой до 178.66.89.221 не идет, а вот до 178.66.0.1 идет. Я вот только в трассировках и не разбираюсь-то. Подскажите пожалуйста, что делать?
Командой scp тоже не загружаются файлы. В общем беда. Буду очень благодарен. Провайдера менять не лучший вариант =(
А брось-ка лог соединения файлзиллы.
Статус: local:/home/user/Рабочий стол/onz375c186.jpg => ?>remote:/var/www/onz375c186.jpg
Ошибка: Превышено время ожидания соединения
А если попробовать заливать файло по обычному FTP? Какие ошибки сыпятся? Судя по всему, провайдер не правильно НАТит ftp data соединения.
Сейчас установлю ftp сервер. Попробую.
Установил proftpd Лог:
Вот теперь хоть гадай. Не так настроил proftpd или провайдер режет. В понедельник с работы смогу проверить только.
Ответ: 530 Некорректные данные аутентификации.
После чего netbeans и filezilla перестали закачивать файлы на удаленый сервак по sftp.
Ты случайно не путаешь SFTP ( копирование файлов внутри SSH сессии, через расширение протокола SSH ) и FTPS ( FTP + SSL )?
Для SFTP, насколько я знаю, не создаётся дополнительных соединений на передачу файла и провайдер при всём желании ничего не сможет заблокировать при работающем SSH
FTPS работает по тем же принципам, что и обычный FTP. В active mode порт для передачи данных открывает клиент, сервер к нему подключается. В passive mode порт открывает сервер, клиент подключается.
Командой scp тоже не загружаются файлы.
Какую ошибку выдаёт клиент? Включай подробные логи на стороне сервера. scp на сервере вообще установлен?
Ты случайно не путаешь SFTP и FTPS ?
НЕТ, точно не путаю.
Для SFTP, насколько я знаю, не создаётся дополнительных соединений на передачу файла и провайдер при всём желании ничего не сможет заблокировать при работающем SSH
Я говорю ведь, что по ssh подключаюсь и могу настраивать сервак, ходить по нему. Открываю через filezilla и вижу все директории, хожу там. А вот закачать файл не могу. И я не знаю природу этого явления =( Для меня это тоже очень странно. Речь о ftp пошла с того момента, как меня попросили попробовать подключиться по ftp.
Если речь о scp, то к черту его. Вот SFTP заработал бы.
Получилось настроить proftpd. У юзера под которым конектился не было дефолтной директории. Создал, подконектился, и закачал спокойно через ftp файл.
Судя по всему, провайдер не правильно НАТит ftp data соединения.
Где про это почитать. Провайдер утверждает, что у него открыты все порты и нет абсолютно ни в чем никаких ограничений.
В общем полный пипец! Если авторизоваться по ftp через filezilla и закачать файл, то sftp некоторое время работает. Потом опять обрывается. Снова авторизовываешься по ftp и sftp опять работает. «Это чудо!» скажите Вы, на что отвечу я: «да! =)» PS Что за фигня? )))
При попытке закинуть файлы на сервер хостинга зависает передача.
Статус: Начинаю закачивать C:\Users\Антон\Desktop\SourceMod DJ перевод от ☆★☆БАТЯ☆★☆™\SMDJ_Web_Interface\SMDJ_Web_Interface\batya.css
Статус: ftpcontrolsocket.cpp(1871): Waiting for replies to skip before sending next command. caller=04B87648
Статус: Начинаю закачивать C:\Users\Антон\Desktop\SourceMod DJ перевод от ☆★☆БАТЯ☆★☆™\SMDJ_Web_Interface\SMDJ_Web_Interface\black.css
Статус: ftpcontrolsocket.cpp(1871): Waiting for replies to skip before sending next command. caller=04B944D8
Ошибка: Превышено время ожидания соединения
Ошибка: Передача файла потерпела неудачу
Статус: Соединяюсь с 31.220.16.242:21.
Ошибка: Превышено время ожидания соединения
Ошибка: Передача файла потерпела неудачу
Статус: Соединяюсь с 31.220.16.242:21.
Статус: Соединение установлено, ожидание приглашения.. .
Статус: Соединение установлено, ожидание приглашения.. .
Ответ: 220----------Welcome to Pure-FTPd [privsep] [TLS] ----------
Ответ: 220-You are user number 51 of 500 allowed.
Ответ: 220-Local time is now 14:19. Server port: 21.
Ответ: 220-This is a private system - No anonymous login
Ответ: 220 You will be disconnected after 3 minutes of inactivity.
Команда: USER u165634335
Ответ: 220----------Welcome to Pure-FTPd [privsep] [TLS] ----------
Ответ: 220-You are user number 50 of 500 allowed.
Ответ: 220-Local time is now 14:19. Server port: 21.
Ответ: 220-This is a private system - No anonymous login
Ответ: 220 You will be disconnected after 3 minutes of inactivity.
Команда: USER u165634335
Ответ: 331 User u165634335 OK. Password required
Команда: PASS ********
Ответ: 331 User u165634335 OK. Password required
Команда: PASS ********
Ответ: 230 OK. Current directory is /public_html
Команда: OPTS UTF8 ON
Ответ: 230 OK. Current directory is /public_html
Команда: OPTS UTF8 ON
Ответ: 200 OK, UTF-8 enabled
Статус: Соединение установлено
Статус: Начинаю закачивать C:\Users\Антон\Desktop\SourceMod DJ перевод от ☆★☆БАТЯ☆★☆™\SMDJ_Web_Interface\SMDJ_Web_Interface\batya.css
Команда: CWD /public_html
Ответ: 200 OK, UTF-8 enabled
Статус: Соединение установлено
Статус: Начинаю закачивать C:\Users\Антон\Desktop\SourceMod DJ перевод от ☆★☆БАТЯ☆★☆™\SMDJ_Web_Interface\SMDJ_Web_Interface\black.css
Ответ: 250 OK. Current directory is /public_html
Команда: TYPE A
Команда: CWD /public_html
Ответ: 200 TYPE is now ASCII
Команда: PASV
Ответ: 250 OK. Current directory is /public_html
Ответ: 227 Entering Passive Mode (31,220,16,242,174,222)
Команда: STOR batya.css
Ответ: 150 Accepted data connection
Команда: TYPE A
Ответ: 200 TYPE is now ASCII
Команда: PASV
Ответ: 227 Entering Passive Mode (31,220,16,242,196,227)
Команда: STOR black.css
Ответ: 150 Accepted data connection
Такая ошибка на моей стороне, потому что подключаюсь к многим хостингам, не пашет. В чем может быть проблема?
Читайте также: