Traceroute не возвращает результат, тогда как ssh работает нормально

Может быть, это глупый вопрос, поэтому, пожалуйста, потерпите меня, поскольку я новичок в сети. При попытке отладить проблему подключения к серверу сегодня я заметил следующие две вещи:

Я могу успешно использовать ssh (порт 22) на целевом сервере. Однако, когда я запускаю tracert, я получаю результат "истекло время ожидания запроса". Имеет ли это смысл? Я имею в виду, что если я могу использовать SSH с использованием полного доменного имени, я также должен быть в состоянии отследить (версия трассировки маршрута для Windows), правильно? Что мне здесь не хватает?

Пожалуйста, дайте мне знать, если мне нужно дать более подробную информацию.

Источник

3 ответа

Решение

Я могу успешно использовать ssh (порт 22) на целевом сервере. Однако, когда я запускаю tracert, я получаю результат "истекло время ожидания запроса". Имеет ли это смысл? Я имею в виду, что если я могу использовать SSH с использованием полного доменного имени, я также должен быть в состоянии отследить (версия трассировки маршрута для Windows), правильно? Что мне здесь не хватает?

Это имеет смысл. Если сервер (и любые брандмауэры перед сервером) разрешают входящий SSH-трафик к серверу, но запрещают ICMP-трафик, поступающий на сервер, тогда ваши результаты будут именно такими, как я ожидаю. Я не говорю, что это определенно так, но это звучит так.

Источник

traceroute или же tracert в Windows почти всегда не тот инструмент, который нужно использовать для отладки приложений любого типа, особенно самых известных, например, основанных на TCP, с настройками по умолчанию.

Это связано с тем, что по умолчанию они используют пакеты UDP и / или ICMP для отслеживания пути, постепенно увеличивая TTL пакета и ожидая, что каждый промежуточный узел, пораженный пакетом, достигшим TTL 0, ответит пакетом ICMP со своим собственным IP-адресом. как источник, чтобы он был обнаружен, и, наконец, для всего пути, который будет обнаружен.

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

Потому что большинство сетей фильтруют пакеты ICMP (и часто ошибочно, основываясь на некоторых старых атаках, которые сейчас являются мифами) и обычно маршрутизируют UDP не так, как TCP, и с другими приоритетами.

Таким образом, путь, видимый по умолчанию, может совершенно отличаться от того, как будет выглядеть реальный трафик приложения.

Следовательно, я рекомендую никогда не использовать этот инструмент таким образом (и по той же причине, не ping или). Наоборот, любой современный может быть передан такие параметры, как -T --port=22 (иногда просто tcptraceroute $host 22), чтобы заставить его использовать TCP-пакеты, на конкретном нужном порту, 22 для ssh. Таким образом, вы будете точно наблюдать, что происходит, когда вы открываете свое ssh-соединение (в некоторых сетях может даже применяться некоторая фильтрация для этого случая, "обнаруживая" трафик traceroute, который немного отличается от обычного, особенно если вы также используете DPI, но это происходит реже, чем фильтрация ICMP или другие пути / приоритеты для UDP и TCP).

Источник

Просто добавьте к комментарию современные инструменты, вы можете посмотреть на конкретные инструменты, которые используют TCP вместо ICMP:

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