Traceroute не возвращает результат, тогда как ssh работает нормально
Может быть, это глупый вопрос, так что, пожалуйста, терпите меня, так как я новичок в сети. для отладки проблемы с подключением к серверу сегодня я заметил следующие две вещи -
Я могу успешно использовать ssh (порт 22) на целевом сервере Однако, когда я запускаю tracert, я получаю результат «Превышено время ожидания запроса». В этом есть смысл? Я имею в виду, что если я могу использовать ssh, используя полное доменное имя, я также смогу tracert (версия трассировки маршрута окон), это правильно? Что мне здесь не хватает?
Пожалуйста, дайте мне знать, если мне нужно будет сообщить более подробную информацию.
Я могу использовать ssh (порт 22) на целевом сервере успешно Однако когда я запускаю tracert, я получаю результат «время ожидания запроса истекло». В этом есть смысл? Я имею в виду, что если я могу использовать ssh, используя полное доменное имя, я должен иметь возможность tracert (версия трассировки маршрута окон), это то, что правильно? Что мне здесь не хватает?
В этом есть смысл. Если сервер (и любые брандмауэры перед сервером) разрешают входящий трафик SSH на сервер, но запрещают входящий трафик ICMP на сервер, тогда ваши результаты будут именно такими, как я ожидал получить. Я не говорю, что здесь это однозначно, но звучит так.
traceroute или tracert в Windows почти всегда является неправильным инструментом для отладки любого типа приложений, особенно наиболее известных, таких как все, основанные на TCP, с их настройками по умолчанию.
Это потому, что они используют по умолчанию пакеты UDP и / или ICMP для отслеживания пути, постепенно увеличивая TTL пакета и ожидая, что каждый промежуточный узел, на который попадает пакет, достигающий TTL, равный 0, ответит пакетом ICMP с собственным IP-адресом в качестве источника, так что он будет обнаружен и, наконец, будет обнаружен весь путь.
В настоящее время это чаще ломается, чем работает, и даже если это сработает, результаты (в частности, время ответа и процент сброса) будут почти бессмысленны и всегда не коррелируют с реальным протоколом, который вы хотите отлаживать, например T CP-порт 22 в вашем случае для ssh.
Потому что большинство сетей фильтруют пакеты ICMP (и часто ошибочно основаны на некоторых старых атаках, которые теперь являются мифами) и обычно маршрутизируют UDP иначе, чем TCP, и с другими применяемыми приоритетами.
Итак путь, видимый по умолчанию, может полностью отличаться, в том числе быть недоступным, от того, как будет выглядеть реальный трафик приложения.
Следовательно, я рекомендую никогда не использовать этот инструмент таким образом (и по той же причине не ] ping либо). Напротив, любому современному серверу можно передать параметры, такие как -T --port = 22 (иногда просто tcptraceroute $ host 22 ), чтобы заставить его использовать TCP-пакеты на конкретный порт, который вам нужен, 22 для ssh. Поступая таким образом, вы будете точно наблюдать, что происходит, когда вы открываете свое ssh-соединение (некоторые сети могут даже применять некоторую фильтрацию для этого случая, «обнаруживая» трафик traceroute, который немного отличается от обычного, особенно если вы также используете DPI, но это реже, чем фильтрация ICMP или разные пути / приоритеты для UDP и TCP).
Просто чтобы добавить к комментарию о современных инструментах, вы можете посмотреть на определенные инструменты, которые используют TCP вместо ICMP:
tcping. ping через TCP-соединение (т.е. номер порта) https://www.elifulkerson.com/projects/tcping.php
или tcproute. traceroute через TCP (требуется установка WinPCAP, если он вам доступен) https://www.elifulkerson.com/projects/tcproute.php