Как работает traceroute -T -p?
Моя цель - проверить, может ли порт назначения (MySQL 3306) подключиться.
Сначала я попытался использовать telnet, но он показал Нет маршрута к хосту
$ 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 и каковы причины результатов на каждом шаге?
Ваши результаты указывают на изменение маршрутизации. Это не имеет ничего общего с тем, как работает traceroute . Повторите тесты и запустите их еще раз, если маршрутизация будет отличаться. Нет маршрута к хосту, может быть брандмауэр, блокирующий порт 3306.
traceroute -T пытается открыть TCP-соединение, используя увеличивающиеся TTL.В большинстве случаев это должно обходить брандмауэры, если вы подключаетесь к разрешенному порту. Механизм описан в выходных данных man traceoute .
Ваш первый вывод - это нормальный вывод, когда ваш брандмауэр находится в почти закрытой конфигурации. Если это не разрешено правилом, обычная трассировка UDP завершится ошибкой.
Ваш второй запрос показывает более длинный путь. В зависимости от конфигурации вашего брандмауэра это может быть обычная маршрутизация. А может быть, более короткий путь еще не был обнаружен. Маршрутизация не имеет ничего общего с traceroute . Аннотация ! X после каждого момента времени указывает, что связь административно запрещена . Обозначения также включены в справочную страницу по traceroute.
Третий запрос использует сокращенный путь. Это может быть нестандартная конфигурация NAT на брандмауэре. А может быть, был обнаружен более короткий путь. Кажется, что TCP-сервер отвечает.
Несколько примечаний:
telnet- эффективный инструмент для выполняемого вами теста. Я часто ставлю перед командой префиксecho |, чтобы соединение было немедленно закрыто.- Первоначальный сбой указывает на то, что у вас нет маршрута к серверу. В этом случае тест не скажет вам ничего полезного о подключении на сервере.
- При выполнении таких тестов может быть полезно повторить попытку, если вы получите противоречивые результаты. В этом случае у вас была другая маршрутизация. Обычно путь должен быть известен или обнаружен по первому запросу.
netstat -ant | grep 3306на сервере сообщит, прослушивает ли MySQL доступный порт. Ни127.0.0.1, ни:: 1недоступны извне сервера.
Это не ответ на ваш вопрос, но может решить вашу настоящую проблему.
Вам нужно убедиться, что MySQL слушает фактический интерфейс, выходящий в Интернет, в дополнение к интерфейсу localhost?
Ваш вывод с 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 и брандмауэра на третьем хосте, используемом для отладки.