DC NTP 不同步和本地 CMOS 时钟问题

DC NTP 不同步和本地 CMOS 时钟问题

我已经按照说明配置了我的 DC(域控制器;Windows 2016)这里从我的 Sophos-UTM 获取他的时间。所以我按照那里的描述配置了 GPO。但之后我重新启动了服务器,我注意到当我运行命令时,w32tm /query /status在源下列出了本地 CMOS 时钟,但这里应该列出我的 Sophos-UTM 的 IP 还是我错了?在上面我链接的屏幕截图中,当它的作者运行相同的命令时,列出了他配置中的正确 IP。那么这里出了什么问题?

所有需要的端口 (UDP 123) 都是开放的并且可以访问。我已经测试过它并查看了我的防火墙配置。为了测试目的,我在 DC 上运行了此命令:w32tm /stripchart /computer:IP-OF-SOPHOS-UTM /dataonly /samples:5

使用该命令,我从 Sophos-UTM 获得了 5 个时间戳样本,因此我的防火墙规则正在运行,并且那里的配置是正确的。我也在日志中看到了这一点。

此 DC 是虚拟机,运行在 vSphere ESXi(免费版本 7.0.1)中。ESXi 主机和客户机之间的时间同步已禁用,如中所述官方 vmWare 文档

以下是命令的输出w32tm /query /status

Jump indicator: 0 (no warning)
stratum: 1 (primary reference - synchron. via radio clock)
Precision: -6 (15.625ms per tick)
stem delay: 0.0000000s
stem deviation: 10.0000000s
Reference ID: 0x4C4F434C (source name: "LOCL")
Last successful synchronization time: 07.12.2020 15:04:23
Source: Local CMOS Clock
Polling interval: 6 (64s)

命令的输出w32tm /query /configuration

[Configuration]

EventLogFlags: 2 (Lokal)
AnnounceFlags: 10 (Lokal)
TimeJumpAuditOffset: 28800 (Lokal)
MinPollInterval: 6 (Lokal)
MaxPollInterval: 10 (Lokal)
MaxNegPhaseCorrection: 172800 (Lokal)
MaxPosPhaseCorrection: 172800 (Lokal)
MaxAllowedPhaseOffset: 300 (Lokal)

FrequencyCorrectRate: 4 (Lokal)
PollAdjustFactor: 5 (Lokal)
LargePhaseOffset: 50000000 (Lokal)
SpikeWatchPeriod: 900 (Lokal)
LocalClockDispersion: 10 (Lokal)
HoldPeriod: 5 (Lokal)
PhaseCorrectRate: 7 (Lokal)
UpdateInterval: 100 (Lokal)
 
[Time-Provider]

NtpClient (Lokal)
DllName: C:\Windows\SYSTEM32\w32time.DLL (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)
ResolvePeerBackoffMinutes: 15 (Richtlinie)
ResolvePeerBackoffMaxTimes: 7 (Richtlinie)
CompatibilityFlags: 2147483648 (Lokal)
EventLogFlags: 0 (Richtlinie)
LargeSampleSkew: 3 (Lokal)
SpecialPollInterval: 900 (Richtlinie)
Type: NTP (Richtlinie)
NtpServer: MY-SOPHOS-UTM-IP,0x5 (Richtlinie)

NtpServer (Lokal)
DllName: C:\Windows\SYSTEM32\w32time.DLL (Lokal)
Enabled: 1 (Lokal)
InputProvider: 0 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)

VMICTimeProvider (Lokal)
DllName: C:\Windows\System32\vmictimeprovider.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)

命令的输出w32tm /query /peers

Number Peers: 1

Peer: MY-SOPHOS-UTM-IP,0x5
Status: Active
Time remaining: 495.5965885s
Mode: 1 (Symmetrically active)
Stratum: 0 (not specified)
Peer Retrieval Interval: 0 (not specified)
Host polling interval: 4 (16s)

命令输出w32tm /resync /rediscover

Resynchronize command is sent to the local computer.
The computer was not synchronized because no time data was available.

非常奇怪的行为。有谁能解决这个问题吗?

答案1

成立解决方案经过大量的研究,这个问题终于解决了。在我的案例中,是惠普交换机 HPE OfficeConnect 1820

较新的 HP Procurve 型号(18xx 系列,例如 1810G 等)有一项功能称为“自动 DoS”。您可以在“安全”部分的“高级安全”部分找到它。

如果启用自动 DoS 功能,则会根据以下条件之一阻止流量:

源端口 (TCP/UDP) 与目标端口 (NTP、SYSLOG 等) 相同

源端口(TCP/UDP)是“特权端口”,因此范围是 1-1023。

这会导致各种问题,但首先要问的是:“第 2 层设备为什么要在第 3 层进行过滤?”这简直是疯了。

NTP 不再起作用。Syslog 流量将不会到达。VPN 流量可能不会到达。

这个问题花了我很多时间才解决。我首先责怪我们的防火墙,但实际流量到达受影响交换机上的标记中继端口。流量不知何故没有发送到目标设备所连接的交换机端口。

受影响的产品:

HP ProCurve 1810G - J9449A(8 个端口)和 J9450A(24 个端口)

因此,禁用自动 DoS 保护功能后,它按预期工作。由于 Windows 中的源现在列出的是正确的 IP,而不是本地 CMOS 时钟,现在我在 tcpdump 中看到了流量。因此,如果其他人使用 HP 交换机,这可能是解决方案。

经过进一步研究,似乎只有该选项Prevent UDP Blat Attack必须禁用。如上所述这里Prevent UDP Blat Attack – UDP Source and Destination Port match。因此,在查看 tcpdump 后,我发现我的 UTM 和 Windows Server 都使用端口 123,所以毫不奇怪,为什么此选项会阻止流量......

这是最终配置的屏幕截图。 在此处输入图片描述

相关内容