Основной вопрос traceroute - хороший traceroute, но время соединения истекло?

Основной вопрос: если я получаю приличный пинг между прыжками при чтении трассировки, НО я не могу подключиться к хосту через FTP, что это значит?

Под подключением через FTP я просто имею в виду использование FileZilla, и ошибка "Тайм-аут соединения". Тем не менее, мое чтение трассировки на этот IP не указывает на проблему задержки.

Я удалил IP-адреса ниже, но это выглядит так:

traceroute to 207.xxx.xxx.xx, 30 hops max, 40 byte packets
 1   <server>  0.788 ms  1.135 ms  1.135                                                                              ms
 2  <server>  0.677 ms  0.688 ms  0.679 ms
 3   <server>  4.526 ms  4.500 ms  4.500 m                                                                             s
 4   <server>  1.502 ms  1.507 ms  1.502 ms
 5   <server>  4.771 ms ae1.ar2.ord1.us.nla                                                                             yer.net (69.31.111.146)  4.761 ms  4.734 ms
 6   <server>  1.456 ms !N  1.300 ms

Есть идеи или предложения? Спасибо!

Источник

4 ответа

Есть ли FTP-сервер, прослушивающий 207.xxx? Есть ли межсетевой экран и настроен ли он для подключения к серверу ftp?

Источник

Это означает, что хост доступен в Интернете, но не отвечает на попытки подключения к FTP.

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

Источник

Как говорят Шейн Мэдден и Иэн, попытки подключения по TCP-порту 21 (FTP) не проходят. Вы можете попробовать отследить маршрут с помощью TCP, чтобы узнать, где разрывается соединение, например,

nmap -Pn --traceroute -p 21 207.xxx.xxx.xx

или же

tcptraceroute 207.xxx.xxx.xx 21
Источник

Для начала обсудим тестирование с правильным инструментом.

Инструменты ICMP уже давно являются общепринятым методом тестирования подключения, но они не всегда являются хорошими тестами. Как вы узнали, вы можете с радостью подключиться к вашему серверу по протоколу ICMP, но не используя FTP (работающий поверх TCP/IP). Приведет ли тестирование задержки веб-сайта к отправке ICMP-трафика на сервер, на котором он размещен, значимые и полезные результаты? Возможно нет. Такой инструмент, как httping или mtr, в этом случае был бы намного лучшим выбором.

У ISC есть небольшая статья об этой проблеме здесь: Ping is Bad (иногда)

Так что по многим причинам PING просто плохой тест во многих ситуациях. Либо это показывает, что дела идут плохо, либо когда вы работаете, или если вы используете это как показатель производительности, это не измерение того, что вы думаете, это измерение.

Что должны делать люди? Ну, во-первых, проверьте хосты на состояние вверх / вниз для транспортов, которые они получат и ответят. Поэтому веб-сервер, вероятно, следует тестировать с использованием tcp/80, а не icmp echo и echo reply. Точно так же, производительность RTT (Round Trip Time) сетей должна измеряться с использованием протоколов, которые мы действительно хотим измерить. Протоколы, такие как tcp/80 (http), tcp/443 (https) или tcp/445 (блок сообщений сервера (SMB) через IP (Microsoft-DS)).

Предложение @Gerald Combs превосходно. Попробуйте использовать TCP-метод проверки подключения.

Вы можете проверить, что TCP/21 открыт и принимает соединения, используя telnet:

telnet 207.xxx.xxx.xx 21

Если вы можете успешно подключиться, то вы можете подтвердить, что можете подключиться к FTP-серверу (т. Е. Нет брандмауэров, блокирующих ваше подключение), и FTP-сервер работает. Если это так, то ваша проблема лежит где-то на уровне приложений. Как уже отмечали другие, проблема, скорее всего, в том, что FTP-сервер либо не прослушивает, либо / или брандмауэр блокирует соединение.

Источник
Другие вопросы по тегам