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