NTP ACL не работает

[the-lebowski]

Может ли кто-нибудь помочь мне понять, почему NTP не разрешается, когда этот ACL применяется к входящему трафику на интерфейсе, обращенном к Интернету? Все остальное работает, но NTP не работает, и я не знаю, почему. interface GigabitEthernet0/0/0 ip address 1.2.3.4 6.7.8.9 ip nat outside ip access-group NTP-ACL in negotiation auto
..... 209 permit udp any any eq ntp log (1 match) 210 permit udp any eq ntp any eq ntp log (2 matches)
.........
show ntp associations address ref clock st when poll reach delay offset disp
*~128.199.169.185 199.101.96.52 3 48 64 7 2.951 -69.055 189.17 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured show ntp status
Clock is unsynchronized, stratum 4, reference is 128.199.169.185
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
ntp uptime is 95500 (1/100 of seconds), resolution is 4000
reference time is ECAA2739.824DD458 (01:15:37.509 SGT Tue Oct 28 2025)
clock offset is -75.3579 msec, root delay is 251.09 msec
root dispersion is 145.57 msec, peer dispersion is 1.90 msec
loopfilter state is 'FREQ' (Drift being measured), drift is 0.000000000 s/s
system poll interval is 64, last update was 62 sec ago.

[M02@rt37]

Здравствуйте
[, @the-lebowski] Добавьте правило над этими двумя, чтобы явно разрешить ответы
от
серверов NTP: access-list NTP-ACL permit udp any eq ntp any С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.

[the-lebowski]

Добавлено и, похоже, теперь работает, но не ясно, зачем мне понадобилось это утверждение? show ntp status
Clock is synchronized, stratum 5, reference is 128.199.169.185
nominal freq is 250.0000 Hz, actual freq is 250.0113 Hz, precision is 2**10 209 permit udp any eq ntp any (122 matches) 210 permit udp any any eq ntp log 211 permit udp any eq ntp any eq ntp log

[M02@rt37]

@the-lebowski Ваш маршрутизатор отправляет пакеты на порт 123__, который уже разрешен. Ответ NTP-сервера с порта 123__ был заблокирован до добавления этого заявления. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.

[balaji.bandi]

Этот запрос NTP отправляется или поступает из Интернета? Вы пробовали поступить наоборот? interface GigabitEthernet0/0/0 IP access-group NTP-ACL
out Еще одно действие, которое вы выполняете, — NAT. Можете ли вы опубликовать полную конфигурацию? Находится ли конфигурация NTP на том же устройстве, на котором вы выполняете NAT? Вот пример исправления permit udp
10.10
.
10.10
any eq
123
permit udp any eq
123
10.10
.
10.10 BB
=====Preenayamo Vasudevam=====
***** Оценить все полезные ответы *****
Как обратиться за помощью к сообществу Cisco

[Joseph W. Doherty]

Возможно разрешить udp любой eq ntp любой log Редактировать: я вижу, что
[M02@rt37]
уже это сделал. Два других ACE не должны быть необходимы для возврата. Вы можете еще больше ужесточить вышеуказанный ACE, используя IP-адреса серверов NTP. Вы также можете рассмотреть возможность использования рефлексивных ACL.

[the-lebowski]

@Joseph W. Doherty
Можете привести пример? Странно то, что ничего не изменилось и ACL используется во всей нашей среде, где используется та или иная форма NTP, но сбой произошел только здесь, что странно. Я не хочу ограничиваться конкретным сервером, потому что это потребует обновления этих ACL при каждом изменении, а я не хочу этого. В основном я хочу разрешить исходящий NTP, а затем разрешить только ответы на эти исходящие запросы.

[Joseph W. Doherty]

@the-lebowski
написал:
@Joseph W. Doherty
Можете привести пример? Пример чего? Рефлексивных ACL? Если да, то, скорее всего, лучше обратиться к документации Cisco... https://www.cisco.com/c/en/us/support/docs/security/ios-firewall/23602-confaccesslists.html#toc-hId--466955766 https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-10/configuration_guide/sec/b_1710_sec_9500_cg/m9-1710-sec-reflexive-access-lists-.html https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_acl/configuration/15-mt/sec-data-acl-15-mt-book/sec-cfg-ip-filter.html Кстати, в кратком описании моего браузера говорится: Рефлексивные списки контроля доступа (ACL) на устройствах Cisco
предназначены для повышения безопасности сети за счет динамической фильтрации трафика на основе состояния сеанса
, что делает их особенно эффективными в сочетании с преобразованием сетевых адресов (NAT).
Они функционируют как форма проверки состояния, отслеживая исходящие соединения и автоматически разрешая обратный трафик, что упрощает настройку правил доступа по сравнению со статическими ACL. Эта возможность особенно полезна в средах NAT, где внутренние IP-адреса скрыты от внешних сетей, поскольку рефлексивные ACL могут поддерживать состояние сеанса через границы NAT. Для реализации рефлексивных ACL с NAT
используется расширенный именованный ACL для определения исходящего трафика
,
который должен отслеживаться
. Например, ACL можно настроить для разрешения трафика TCP и UDP с помощью ключевого слова reflect, которое создает динамическую рефлексивную запись для обратного трафика. Затем эта рефлексивная запись оценивается входящим ACL с помощью команды evaluate, что гарантирует, что только легитимные ответы на инициированные сессии будут разрешены обратно в сеть. Этот подход позволяет маршрутизатору динамически создавать временные записи в рефлексивном ACL на основе исходящего трафика, которые позже используются для проверки входящих пакетов. Рефлексивные ACL совместимы с NAT
и лучше всего подходят для сред, требующих динамической фильтрации на основе состояния сеанса, например, для сред, использующих NAT для скрытия внутренних IP-адресов или применения строгих политик безопасности. Они могут использоваться вместе с другими статическими ACL и настраиваются с помощью расширенных именованных IP ACL; их нельзя определять с помощью пронумерованных или стандартных именованных ACL.
Конфигурация включает в себя создание исходящего ACL с операторами permit, которые включают ключевое слово reflect для генерации рефлексивных записей, и входящего ACL, который использует команду evaluate для ссылки на эти записи для проверки обратного трафика.

[Joseph W. Doherty]

@Джозеф У. Доэрти
написал:
Два других ACE не должны быть необходимы для возврата. Если вас интересует вышеуказанное: 209 permit udp any any eq ntp log (1 match)
210 permit udp any eq ntp any eq ntp log (2 matches) Поскольку ACL применяется «внутри», ACE 209 сопоставляет порт NTP как пункт назначения. ACE 210 соответствует порту NTP как для сервера, так и для запрашивающего хоста. Из того, что я прочитал, хост может использовать номер порта, отличный от 123. Таким образом, оба этих ACE могут не сработать, если хост, т. е. номер порта назначения, не использует порт 123. Однако обычно ожидается, что серверная сторона всегда будет использовать порт 123. Именно поэтому permit udp any eq ntp any (122 matches) , похоже, работает. Т. е. порт сервера NTP, источник для возврата, — 123, а порт хоста — любой. Кстати, рефлексивный ACL будет более безопасным, потому что обратный пакет NTP должен «зеркалировать» то, что было отправлено на сервер NTP. Т. е. обратные пакеты должны соответствовать ожидаемым IP-адресам и портам.