Как работает traceroute -T -p?

Моя цель - проверить, может ли порт назначения (MySQL 3306) подключиться.

Сначала я попробовал с помощью telnet, но он показал No route to host

$ telnet dest.com 3306
Trying <dest_ip>...
telnet: Unable to connect to remote host: No route to host

Тем не менее, это может быть связано с портом 80.

$ telnet dest.com 80
Trying <dest_ip>...
Connected to dest.com.
Escape character is '^]'.

Итак, я попытался с обычным traceroute и пункт назначения не достижим.

$ traceroute dest.com
traceroute to dest.com (<dest_ip>), 30 hops max, 60 byte packets
1 172.16.101.1 (172.16.101.1) 0.283 ms 0.553 ms 0.345 ms
2 * * *
3 * * *
...

Однако, когда я попытался с помощью traceroute -T -p, пункт назначения оказался достижимым.

$ traceroute -T -p 3306 dest.com
traceroute to dest.com (<dest_ip>), 30 hops max, 60 byte packets
1 172.16.101.1 (172.16.101.1) 0.270 ms 0.374 ms 0.468 ms
2 <public_ip> (<public_ip>) ....
3 <public_ip2> (<pubice_ip2>) ...
4 ...
5 <dest_ip> (dest_ip) 4.144 ms !X 4.217 ms !X 3.996 !X

И, когда я попробовал с другим портом, маршрут другой (только один переход).

$ traceroute -T -p 80 dest.com
traceroute to dest.com (<dest_ip>), 30 hops max, 60 byte packets
1 172.16.101.1 (172.16.101.1) 0.327 ms 0.438 ms 0.568 ms
2 <dest_ip> (dest_ip) 0.711 ms 0.865 ms 0.974 ms

Итак, мне интересно, как traceroute -T -p работа и каковы причины результатов на каждом этапе?

Источник

3 ответа

Решение

Ваши результаты указывают на изменение маршрутизации. Это не имеет ничего общего с тем, как traceroute работает. Пожалуйста, перезапустите свои тесты и повторите их еще раз, если маршрутизация выглядит иначе. Нет маршрута к хосту, это может быть порт 3306 блокировки брандмауэра.

traceroute -T пытается открыть TCP-соединение, используя увеличение TTL. В большинстве случаев это должно обходить брандмауэры, если вы подключаетесь к разрешенному порту. Механизм описан в man traceoute выход.

Ваш первый вывод является нормальным выводом, когда ваш брандмауэр находится в основном в закрытой конфигурации. Если нет правила, разрешающего это, нормальная трассировка UDP завершится ошибкой.

Ваш второй запрос показывает более длинный путь. В зависимости от конфигурации брандмауэра это может быть обычная маршрутизация. Или может быть, что более короткий путь еще не был обнаружен. Маршрутизация не имеет ничего общего с traceroute, !X аннотация после каждого времени указывает, что связь adminstratively prohibited, Примечания также включены в справочную страницу для traceroute.

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

Несколько заметок:

  • telnet является эффективным инструментом для теста, который вы запускаете. Я часто префикс команды с echo | так что соединение закрывается сразу.
  • Первоначальный сбой означает, что у вас нет маршрута к серверу. В этом случае тест не скажет вам ничего полезного о подключении к серверу.
  • При выполнении подобных тестов может быть полезно повторить попытку, если вы получите противоречивые результаты. В этом случае у вас была другая маршрутизация. Обычно путь должен был быть известен или обнаружен при первом запросе.
  • netstat -ant | grep 3306 на сервере скажет, прослушивает ли MySQL доступный порт. ни 127.0.0.1 ни ::1 доступны снаружи сервера.
Источник

Ваш вывод из traceroute dest.com показывает 100% потерю пакета от второго перехода вперед. Наиболее вероятным объяснением этого может быть плохо настроенный брандмауэр на вашем конце соединения. Это может быть отбрасывание исходящих пакетов UDP.

Ваш вывод из telnet dest.com 3306 а также traceroute -T -p 3306 dest.com согласуются. !X от traceroute означает отсутствие маршрута к хосту, как telnet я же говорил. Однако сообщения об отсутствии маршрута к хосту приходят с IP-адреса, который вы пытаетесь достичь. Это означает, что либо IP обманывает вас, либо на другом конце происходит некий NAT, в результате чего реальный IP-адрес скрыт от вас.

Выход из traceroute -T -p 80 dest.com показывает гораздо более короткий маршрут. Похоже, что на вашем конце соединения происходит перехват трафика, предназначенного для порта 80.

Поскольку симптомы указывают на что-то подозрительное на каждом конце соединения, потенциально есть две отдельные проблемы, и вы должны отладить их отдельно. Чтобы помочь в отладке проблем по отдельности, вам будет полезно иметь доступ к третьему хосту с подключением к Интернету без каких-либо смешных дел. Это означает, что нет ни NAT, ни межсетевого экрана на третьем хосте, используемом для отладки.

Источник

Это не ответ на ваш вопрос, но может решить вашу актуальную проблему.

Вам нужно убедиться, что MySQL слушает фактический интерфейс, обращенный к Интернету, в дополнение к интерфейсу localhost?

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