Назад | Перейти на главную страницу

Traceroute для проверки NTP - возможно?

Раньше я в основном использовал tcptraceroute для проверки http и ssh.

Теперь мне нужно проверить, может ли мой хост подключиться к серверу NTP.

Это вообще возможно?

У меня две машины.

На уровне приложения я вижу: Machine qual не может подключиться к серверу ntp, а prod машины может достичь сервера ntp.

Если я запустил эту команду, результат обоих будет одинаковым:

Продукт:

prod:(/root/home/root)(root)#traceroute -U -p ntp 30.252.33.1
traceroute to 30.252.33.1 (30.252.33.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *

Качество:

qual:~ # traceroute -U -p ntp 30.252.33.1
traceroute to 30.252.33.1 (30.252.33.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *

Я предполагаю, что сервер NTP просто отбрасывает пакеты UDP из traceroute, а traceroute не получает ответа.

(для служб на основе TCP это работает нормально, так как есть некоторый ответ «соединение установлено»).

Можно ли проверить ntp на уровне сети с помощью сетевых инструментов, таких как traceroute?

Если нет, как проверить, может ли машина подключиться к серверу ntp?

«Проверить ntp» следует с помощью утилит, поддерживающих протокол NTP. И ntpd, и chrony сообщают об успешном завершении нескольких последних пакетов как регистр «достижения».


«Открыт ли порт на удаленном хосте?» Можно ответить с помощью сканера портов.

$ sudo nmap -6 -sU -p 123 2.pool.ntp.org

Starting Nmap 6.40 ( http://nmap.org ) at 2019-05-03 16:55 UTC
Nmap scan report for 2.pool.ntp.org (2600:3c01::f03c:91ff:fec8:5c8)
Host is up (0.067s latency).
Other addresses for 2.pool.ntp.org (not scanned): 2607:f3c8:3803:1::6 2001:19f0:8001:1de:5400:ff:fe60:f647 2001:4998:c:1028::1001
rDNS record for 2600:3c01::f03c:91ff:fec8:5c8: chl.la
PORT    STATE SERVICE
123/udp open  ntp

Nmap done: 1 IP address (1 host up) scanned in 0.38 seconds

На «Найти путь к хосту» можно ответить с помощью утилит в стиле tracepath или traceroute. Для этого требуются точные ответы ICMP, которые могут быть чрезмерно отфильтрованы в различных сетях.

$ tracepath6 -b  2.pool.ntp.org
 1?: [LOCALHOST]                        0.007ms pmtu 1500
 1:  2600:3c03::8678:acff:fe0d:97c1 (2600:3c03::8678:acff:fe0d:97c1)   1.537ms
 1:  2600:3c03::8678:acff:fe0d:97c1 (2600:3c03::8678:acff:fe0d:97c1)   4.161ms
 2:  2600:3c03:6666:12::1 (2600:3c03:6666:12::1)           3.062ms
 3:  2600:3c03:6666:5::2 (2600:3c03:6666:5::2)             1.075ms asymm  2
 4:  2001:678:34c:56::2 (2001:678:34c:56::2)              26.746ms asymm  3
 5:  2001:678:34c:6a::1 (2001:678:34c:6a::1)              35.811ms asymm  4
 6:  2001:678:34c:52::2 (2001:678:34c:52::2)              67.198ms asymm  3
 7:  2600:3c01:3333:3::2 (2600:3c01:3333:3::2)            67.826ms asymm  5
 8:  chl.la (2600:3c01::f03c:91ff:fec8:5c8)               67.376ms reached
     Resume: pmtu 1500 hops 8 back 5

Двигайтесь вперед и назад по пути, пока не найдете, что случилось с вашими пакетами. Например, проверьте файлы конфигурации сервера NTP, разрешенные вашим хостом, а также проверьте все брандмауэры на пути.