У меня есть сервер CentOS, на котором я хочу настроить клиент NTP, чтобы получать точное время для сервера. Сервер находится в локальной подсети с NAT за межсетевым экраном ASA 5505, который действует как маршрутизатор NAT и который, в свою очередь, напрямую подключается к интернет-модему DSL, а не к другому маршрутизатору.
Проблема в том, что клиенту NTP на сервере CentOS просто никогда не удается синхронизироваться с любым выбранным мной сервером NTP. Однако установка ASA 5505 в качестве клиента NTP работает полностью нормально. Использование одних и тех же IP-адресов на сервере CentOS по-прежнему не дает мне возможности синхронизации, даже если я жду несколько часов.
ntp.conf:
restrict 127.0.0.1 restrict -6 ::1 server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift keys /etc/ntp/keys server 89.109.251.21 server 176.9.47.150 server 63.15.238.180
Использование ntpq говорит мне, что ни один из этих серверов не доступен (хотя по крайней мере два из них ДОСТУПНЫ в любое время из ASA, поэтому с ними все в порядке):
peers
remote refid st t when poll reach delay offset jitter
*LOCAL(0) .LOCL. 10 l 25 64 377 0.000 0.000 0.001
89.109.251.21 .INIT. 16 u - 1024 0 0.000 0.000 0.000
odin.tuxli.ch .INIT. 16 u - 1024 0 0.000 0.000 0.000
63.15.238.180 .INIT. 16 u - 1024 0 0.000 0.000 0.000
На данный момент это показывает .INIT. при рефиде требуется около часа, прежде чем это изменится на что-то другое, но счетчик «охвата» продолжает оставаться на 0.
команда "as" дает следующее:
ind assID status conf reach auth condition last_event cnt
1 40263 9614 yes yes none sys.peer reachable 1 2 40264 8000 yes yes none reject 3 40265 8000 yes yes none reject 4 40266 8000 yes yes none reject
Это не меняется даже через 24 часа, это всегда "отклонение".
Запросы с помощью «rv» всегда получают ответ «peer_unfit» и «peer_stratum», что естественно, так как страта все время остается на уровне 16.
Похоже на проблему с сетью, но я не нашел ее.
У меня нет никаких правил в ASA, ограничивающих или разрешающих порт 123 для NTP. Но теоретически мне это не нужно - для UDP брандмауэр ДОЛЖЕН знать, что ответный пакет связан / установлен, поэтому он должен пропустить его, или я здесь ошибаюсь?
Или проблема связана с какой-то конфигурацией аутентификации - имеет ли к этому какое-то отношение строка ключа ntp в конфигурации?
РЕДАКТИРОВАТЬ: FIREWALL ASA 5505 CONFIG (сокращенно):
ASA Version 8.2(5) ! names ! interface Ethernet0/0 switchport access vlan 2 ! interface Ethernet0/1 ! interface Ethernet0/2 ! interface Ethernet0/3 ! interface Ethernet0/4 ! interface Ethernet0/5 switchport access vlan 3 ! interface Ethernet0/6 switchport access vlan 3 ! interface Ethernet0/7 switchport access vlan 3 ! interface Vlan1 nameif inside security-level 100 ip address 10.111.11.251 255.255.255.0 ! interface Vlan2 nameif outside security-level 0 ip address 192.168.1.2 255.255.255.252 ! interface Vlan3 no forward interface Vlan1 nameif dmz security-level 50 ip address 192.168.240.254 255.255.255.0 ! ! ftp mode passive clock timezone CEST 1 clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 2:00 object-group network XenServer network-object host 192.168.240.240 network-object host 192.168.240.241 network-object host 192.168.240.242 access-list MAILSERVER extended permit tcp any any eq www access-list MAILSERVER extended permit tcp any any eq https access-list MAILSERVER extended permit tcp any any eq smtp access-list MAILSERVER extended permit tcp any any eq ftp access-list MAILSERVER extended permit tcp any any eq ftp-data access-list MAILSERVER extended permit icmp any any echo-reply access-list MAILSERVER extended deny ip any any log access-list NEPLAN extended permit tcp any host 192.168.240.231 eq 10000 access-list NEPLAN extended permit tcp any host 192.168.240.231 eq https access-list NEPLAN extended permit tcp any host 192.168.240.253 eq 10000 access-list NEPLAN extended permit tcp any host 192.168.240.253 eq https access-list NEPLAN extended permit tcp any object-group XenServer eq https access-list NEPLAN extended permit tcp any object-group XenServer eq ssh access-list NEPLAN extended permit tcp any host 192.168.240.231 eq www access-list NEPLAN extended permit tcp any host 192.168.240.238 eq www access-list INTERNET extended permit ip 192.168.240.0 255.255.255.128 any access-list INTERNET extended permit ip host 192.168.240.136 any access-list INTERNET extended permit ip host 192.168.240.230 any access-list INTERNET extended permit ip host 192.168.240.220 any access-list INTERNET extended permit ip host 192.168.240.221 any access-list INTERNET extended permit ip host 192.168.240.222 any access-list INTERNET extended permit ip host 192.168.240.210 any access-list INTERNET extended permit ip host 192.168.240.211 any access-list INTERNET extended permit icmp any any echo-reply access-list INTERNET extended permit ip object-group XenServer any access-list INTERNET extended deny ip any any log mtu inside 1500 mtu outside 1500 mtu dmz 1500 icmp unreachable rate-limit 1 burst-size 1 arp timeout 14400 global (outside) 91 interface global (dmz) 92 interface nat (inside) 92 10.111.11.0 255.255.255.0 nat (dmz) 91 192.168.240.0 255.255.255.0 static (dmz,outside) tcp interface https 192.168.240.136 https netmask 255.255.255.255 static (dmz,outside) tcp interface smtp 192.168.240.136 smtp netmask 255.255.255.255 static (dmz,outside) tcp interface ftp 192.168.240.136 ftp netmask 255.255.255.255 static (dmz,outside) tcp interface ftp-data 192.168.240.136 ftp-data netmask 255.255.255.255 static (dmz,outside) tcp interface www 192.168.240.136 www netmask 255.255.255.255 access-group NEPLAN in interface inside access-group MAILSERVER in interface outside access-group INTERNET in interface dmz route outside 0.0.0.0 0.0.0.0 192.168.1.1 1 ntp server 89.109.251.21 ntp server 176.9.47.150 ntp server 63.15.238.180 webvpn ! class-map inspection_default match default-inspection-traffic ! ! policy-map type inspect dns preset_dns_map parameters message-length maximum client auto message-length maximum 512 policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 inspect h323 ras inspect ip-options inspect netbios inspect rsh inspect rtsp inspect skinny inspect esmtp inspect sqlnet inspect sunrpc inspect tftp inspect sip inspect xdmcp ! service-policy global_policy global prompt hostname context no call-home reporting anonymous call-home profile CiscoTAC-1 no active destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService destination address email callhome@cisco.com destination transport-method http subscribe-to-alert-group diagnostic subscribe-to-alert-group environment subscribe-to-alert-group inventory periodic monthly subscribe-to-alert-group configuration periodic monthly subscribe-to-alert-group telemetry periodic daily Cryptochecksum:590d5cd7306d6a21eb875098d3b33661 : end NEP-ASA-SL20-1#
Серверы, у которых есть проблемы с NTP: 192.168.240.240 и 192.168.240.241 (группа сетевых объектов XenServers - это XenServer DomU. Пробовал уже с другим автономным сервером - та же проблема, поэтому похоже, что это не связано с Xen).
У вас нет ASA, настроенного для разрешения исходящего трафика NTP, поэтому это не так. «Связанный / установленный» трафик относится к незавершенному трафику, например к входящим ответам от серверов NTP, а не к вновь инициированному трафику, поэтому здесь он не применяется.
Чтобы решить эту проблему, добавьте правила для соответствующих групп, чтобы разрешить исходящий трафик NTP. Например:
access-list NEPLAN extended permit udp any any eq 123
Решением для этого является добавление статической записи NAT для UDP-пакетов с целевым портом 123 (плюс открытие этого входящего порта специально):
static (dmz,outside) udp interface ntp 192.168.240.240 ntp netmask 255.255.255.255
Да, я знаю, в этом НЕ ДОЛЖНО быть необходимости. Открытие входящего порта 123 специально не обрабатывает его - для этого требуется статическая запись NAT. Это также показывает, что UDP-пакеты, отправленные моим сервером CentOS, имеют как порт назначения, так и исходный порт, равный 123 для NTP.
Может ли кто-нибудь пролить свет на то, почему межсетевой экран отказывается классифицировать этот трафик как связанный трафик? Это потому, что исходный порт является «привилегированным» портом, то есть <1023? Я не могу найти никакой документации или ссылок на это.