Моя цель - проверить, может ли порт назначения (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 работают и каковы причины результатов на каждом этапе?
Ваши результаты указывают на изменение маршрутизации. Это не имеет ничего общего с тем, как 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?