search

vernesong / OpenClash

A Clash Client For OpenWrt
MIT License
16.46k stars 3.04k forks source link

[Bug] Fake IP模式下的NTP问题 #3766

Closed WFANG12719 closed 5 months ago

WFANG12719 commented 6 months ago

Verify Steps

OpenClash Version

v0.46.001-beta

Bug on Environment

Lean

OpenWrt Version

OpenWrt R23.2.14 by lean & lienol

Bug on Platform

Linux-arm64

Describe the Bug

仔细看过https://github.com/vernesong/OpenClash/issues/1133 的描述和解决问题方法了，但在我的配置上就是不生效，把常用的ntp 服务器都加入了fake-ip-filter里还是不起作用。网络里的Windows电脑，苹果手机，安卓手机，苹果笔记本电脑，Linux服务器的时间都不正确，慢60-90秒。在客户端运行ntpd 或ntpclient命令都失败，提示ntp服务器不存在或不可到达。 和IPv6的设置无关，试过了把IPv6相关设置都禁止，结果也一样。

To Reproduce

旁路由，fake-ip增强模式，各种客户端本地时间不正确，无法和因特网NTP 服务器例如 ntp.tencent.com, ntp.aliyun.com, time.apple.com, time.windows.com等同步时间。

OpenClash Log

见附件

OpenClash Config

No response

Expected Behavior

还请哪位告知在fake ip下如何配置，使客户端可以正确接受ntp服务器调整时间。

Additional Context

openclash_cfg.txt

ghost commented 6 months ago

你好，你UDP通吗？

WFANG12719 commented 6 months ago

UDP 通的，软路由机器自身也可以正常 NTP 出去，就是所有客户端不可以。客户端的 DNS 和网关都指向软路由机器

William Fang

From: sangyishuje1123 @.> Sent: Sunday, February 18, 2024 10:15:08 AM To: vernesong/OpenClash @.> Cc: WFANG12719 @.>; Author @.> Subject: Re: [vernesong/OpenClash] [Bug] Fake IP模式下的NTP问题 (Issue #3766)

你好，你UDP通吗？

― Reply to this email directly, view it on GitHubhttps://github.com/vernesong/OpenClash/issues/3766#issuecomment-1950789752, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AU4RK3YRRIEKZ55K4RL7ULLYUFP2ZAVCNFSM6AAAAABDNMDMBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJQG44DSNZVGI. You are receiving this because you authored the thread.Message ID: @.***>

ghost commented 6 months ago

自身可以，客户端不行，那udp还是有问题吧 要不把udp代理上试试？或者换个模式？ tun被人说有bug的，试下这位的方法https://github.com/vernesong/OpenClash/issues/3762

openwrt系统的时间同步里有一个将自身作为ntp服务器，在找问题或解决方法的时候暂且打开应个急？

WFANG12719 commented 6 months ago

UDP 流量代理打开了，还是不行。救急的方法是把软路由机器的 NTP server 打开，能配置多个 NTP server 的机器就配一个内网的 NTP server，再配置一个因特网的 NTP server。苹果手机，iPad，安卓手机还不知道怎样搞🥴？

William Fang

From: sangyishuje1123 @.> Sent: Sunday, February 18, 2024 3:07:50 PM To: vernesong/OpenClash @.> Cc: WFANG12719 @.>; Author @.> Subject: Re: [vernesong/OpenClash] [Bug] Fake IP模式下的NTP问题 (Issue #3766)

自身可以，客户端不行，那udp还是有问题吧 要不把udp代理上试试？或者换个模式？ tun被人说有bug的，试下这位的方法https://github.com/vernesong/OpenClash/issues/3762

openwrt系统的时间同步里有一个将自身作为ntp服务器，在找问题或解决方法的时候暂且打开应个急？

— Reply to this email directly, view it on GitHubhttps://github.com/vernesong/OpenClash/issues/3766#issuecomment-1950985110, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AU4RK35XPUBVV2XU3AOWGS3YUGSENAVCNFSM6AAAAABDNMDMBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJQHE4DKMJRGA. You are receiving this because you authored the thread.Message ID: @.***>

vernesong commented 6 months ago

image

WFANG12719 commented 6 months ago

感谢vernesong本尊亲自出马，在上面防火墙配置里勾上了“IP动态伪装”，把软路由重新启动了，还是不起作用。

Tsingwen commented 6 months ago

我也遇到这问题，以下是我的解决办法，供参考： 1、勾选Fake-IP 持久化 2、勾选Fake-IP-Filter 3、勾选主机，如下图，将你需要的ntp 域名和对应的ip写进去，作用类似/etc/hosts

image
WFANG12719 commented 6 months ago

谢谢兄台。可惜，结果还是不行。我都不知道哪里有问题了。 下面前面两个NTP服务器是两台局域网的机器用做NTP服务器就可以，其它互联网上的都不行。

Checking current status of NTP service with ntpq -p remote refid st t when poll reach delay offset jitter

+R-N1-1 17.253.84.125 2 u 105 128 377 3.415 -26.221 21.029 *R-N1-2 17.253.116.253 2 u 109 128 377 3.660 +16.784 4.907 106.55.184.199 .XFAC. 16 u - 128 0 0.000 +0.000 0.000 203.107.6.88 .XFAC. 16 u - 128 0 0.000 +0.000 0.000 17.253.84.253 .XFAC. 16 u - 128 0 0.000 +0.000 0.000 114.118.7.161 .XFAC. 16 u - 128 0 0.000 +0.000 0.000 139.199.215.251 .XFAC. 16 u - 128 0 0.000 +0.000 0.000 223.113.103.191 .XFAC. 16 u - 128 0 0.000 +0.000 0.000 20.189.79.72 .XFAC. 16 u - 128 0 0.000 +0.000 0.000 132.163.96.1 .XFAC. 16 u - 128 0 0.000 +0.000 0.000 (Auto-Refresh every 10s --- CTRL+C to Cancel)

WFANG12719 commented 6 months ago

正常的ntpq 查询应该如下列输出：

Checking current status of NTP service with ntpq -p remote refid st t when poll reach delay offset jitter

R-N1-1 17.253.84.125 2 u 35 64 1 5.132 +6.882 2.472 R-N1-2 17.253.116.253 2 u 36 64 1 4.533 -0.247 1.046 106.55.184.199 100.122.36.196 2 u 14 64 1 12.028 +35.091 0.460 203.107.6.88 100.107.25.114 2 u 28 128 1 50.518 +38.996 0.403 hkhkg1-ntp-002. .XFAC. 16 u - 128 0 0.000 +0.000 0.000 114.118.7.161 .XFAC. 16 u - 128 0 0.000 +0.000 0.000 *139.199.215.251 100.122.36.196 2 u 57 128 1 12.756 +36.684 12.643 +223.113.103.191 10.137.53.7 3 u 37 64 1 38.046 +35.298 4.185 -20.189.79.72 25.66.230.4 3 u 30 64 1 102.960 +39.448 35.703 -time-a-b.nist.g .NIST. 1 u 39 128 1 222.514 +22.897 20.951 (Auto-Refresh every 10s --- CTRL+C to Cancel)

yellowsavant commented 6 months ago

感谢vernesong本尊亲自出马，在上面防火墙配置里勾上了“IP动态伪装”，把软路由重新启动了，还是不起作用。

我的办法很简单，打开软路由上的ntp server，在防火墙上劫持udp port 123的流量到软路由本身，前端不管哪一种客户端都能同步，这样就不需要客户端一个个更改设置

WFANG12719 commented 5 months ago

下了两条命令在软路由上，看看： iptables -t nat -A PREROUTING -i br-lan -p udp --dport 123 -j DNAT --to-destination 192.168.192.129:123 iptables -t nat -A POSTROUTING -o br-lan -j MASQUERADE

yellowsavant commented 5 months ago

下了两条命令在软路由上，看看： iptables -t nat -A PREROUTING -i br-lan -p udp --dport 123 -j DNAT --to-destination 192.168.192.129:123 iptables -t nat -A POSTROUTING -o br-lan -j MASQUERADE

主要是上面那条起作用 iptables -t nat -I PREROUTING -i $lan -p udp --dport 123 -j REDIRECT --to-ports 123 （$lan是我定义的本机IP变量） 直接跳转本机123端口就行了，不需要DNAT（这个当然也可以的，作用相同） 如果你的防火墙挡了udp协议，记得在相关的chain里加上Accept的命令

WFANG12719 commented 5 months ago

感谢。这个nat所有 UDP123流量的起作用。 以下是在Windows上运行 ntpq的结果： C:>ntpq -pw remote refid st t when poll reach delay offset jitter

+203.107.6.88 100.107.25.114 2 u 17 64 377 76.233 +3.414 10.224 -hkhkg1-ntp-002.aaplimg.com 63.123.5.208 2 u 193 64 374 45.402 -2.598 24.519 +114.118.7.161 .OLEG. 1 u 69 64 16 74.547 +0.469 38.596 -162.159.200.123 (time.cloudflare.com) 10.209.8.8 3 u 2 64 377 183.657 -5.760 32.151 *2001:da8:9000::130 .PTP. 1 u 63 64 377 83.443 +0.192 4.808 +20.189.79.72 25.66.230.5 3 u 23 64 377 123.951 +4.897 34.943 time-e-b.nist.gov .STEP. 16 u - 128 0 0.000 +0.000 0.000 +106.55.184.199 100.122.36.196 2 u 2 64 377 44.535 -2.834 2.365

WFANG12719 commented 5 months ago

另外在DHCP里加上option 42 为所有客户端分发本地NTP服务器（openwrt机器可以做NTP服务器）

WFANG12719 commented 5 months ago

临时解决方法（workaroud)：估计得临时很久。。。 1）将openwrt设置为NTP服务端，openwrt机器定时与互联网知名NTP服务器同步时间。openwrt机器对自己内网的机器提供NTP服务。 2）在openwrt机器上添加iptables （具体见上）将本地子网内的NTP流量指向openwrt服务器。在本地DHCP服务器里添加option 42为所有客户端提供本地NTP服务器IP地址（大部分Linux和安卓的设备DHCP请求包中会包含请求NTP服务器地址）

vernesong commented 4 months ago

看下控制面板日志，这些ntp服务流量是怎么走的

WFANG12719 commented 3 months ago

看下控制面板日志，这些ntp服务流量是怎么走的

在路由器上运行下面这条命令 root@openwrt:~#tcpdump -i br-lan udp port 123 可以看到确实UDP123流量在流动：

root@openwrt:~#tcpdump -i br-lan udp port 123 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes 23:04:05.333568 IP 192.168.192.138.49155 > 52.148.114.188.123: NTPv4, Client, length 48 23:04:05.333600 IP 192.168.192.138.49155 > 52.148.114.188.123: NTPv4, Client, length 48 23:04:06.368844 IP 192.168.192.141.123 > 192.168.192.6.123: NTPv4, Client, length 48 23:04:06.369005 IP 192.168.192.6.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:08.729186 IP 192.168.192.138.58575 > time.cloudflare.com.123: NTPv4, Client, length 48 23:04:08.729250 IP 192.168.192.138.58575 > time.cloudflare.com.123: NTPv4, Client, length 48 23:04:08.973504 IP 192.168.192.138.56901 > 061239100017.ctinets.com.123: NTPv4, Client, length 48 23:04:08.973579 IP 192.168.192.138.56901 > 061239100017.ctinets.com.123: NTPv4, Client, length 48 23:04:11.368242 IP 192.168.192.141.123 > 106.55.184.199.123: NTPv4, Client, length 48 23:04:11.368478 IP 192.168.192.6.123 > 106.55.184.199.123: NTPv4, Client, length 48 23:04:11.380450 IP 106.55.184.199.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:11.380517 IP 106.55.184.199.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:11.746747 IP 192.168.192.138.62941 > ussjc2-ntp-001.aaplimg.com.123: NTPv4, Client, length 48 23:04:11.747172 IP 192.168.192.6.62941 > ussjc2-ntp-001.aaplimg.com.123: NTPv4, Client, length 48 23:04:11.913180 IP ussjc2-ntp-001.aaplimg.com.123 > 192.168.192.138.62941: NTPv4, Server, length 48 23:04:11.913218 IP ussjc2-ntp-001.aaplimg.com.123 > 192.168.192.138.62941: NTPv4, Server, length 48 23:04:12.782992 IP 192.168.192.138.59994 > 28.128.4.92.123: NTPv4, Client, length 48 23:04:13.367894 IP 192.168.192.141.123 > 106.55.184.199.123: NTPv4, Client, length 48 23:04:13.368016 IP 192.168.192.6.123 > 106.55.184.199.123: NTPv4, Client, length 48 23:04:13.379640 IP 106.55.184.199.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:13.379685 IP 106.55.184.199.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:14.526563 IP 192.168.192.138.62475 > stratum2-1.ntp.mow01.ru.misaka.io.123: NTPv4, Client, length 48 23:04:14.526870 IP 192.168.192.138.62475 > stratum2-1.ntp.mow01.ru.misaka.io.123: NTPv4, Client, length 48 23:04:15.367581 IP 192.168.192.141.123 > 106.55.184.199.123: NTPv4, Client, length 48 23:04:15.367866 IP 192.168.192.6.123 > 106.55.184.199.123: NTPv4, Client, length 48 23:04:15.379595 IP 106.55.184.199.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:15.379715 IP 106.55.184.199.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:17.367833 IP 192.168.192.141.123 > 106.55.184.199.123: NTPv4, Client, length 48 23:04:17.367847 IP 192.168.192.141.123 > ussjc2-ntp-001.aaplimg.com.123: NTPv4, Client, length 48 23:04:17.368138 IP 192.168.192.6.123 > 106.55.184.199.123: NTPv4, Client, length 48 23:04:17.368156 IP 192.168.192.6.123 > ussjc2-ntp-001.aaplimg.com.123: NTPv4, Client, length 48 23:04:17.380202 IP 106.55.184.199.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:17.380453 IP 106.55.184.199.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:17.527808 IP ussjc2-ntp-001.aaplimg.com.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:17.527835 IP ussjc2-ntp-001.aaplimg.com.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:18.130419 IP 192.168.192.138.59536 > ec2-51-16-235-6.il-central-1.compute.amazonaws.com.123: NTPv4, Client, length 48 23:04:18.130473 IP 192.168.192.138.59536 > ec2-51-16-235-6.il-central-1.compute.amazonaws.com.123: NTPv4, Client, length 48 23:04:18.367762 IP 192.168.192.141.123 > 106.75.185.63.123: NTPv4, Client, length 48 23:04:18.367845 IP 192.168.192.6.123 > 106.75.185.63.123: NTPv4, Client, length 48 23:04:18.375427 IP 106.75.185.63.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:18.375464 IP 106.75.185.63.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:19.368098 IP 192.168.192.141.123 > ussjc2-ntp-001.aaplimg.com.123: NTPv4, Client, length 48 23:04:19.368099 IP 192.168.192.141.123 > 106.55.184.199.123: NTPv4, Client, length 48 23:04:19.368405 IP 192.168.192.6.123 > 106.55.184.199.123: NTPv4, Client, length 48 23:04:19.368408 IP 192.168.192.6.123 > ussjc2-ntp-001.aaplimg.com.123: NTPv4, Client, length 48 23:04:19.380278 IP 106.55.184.199.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:19.380395 IP 106.55.184.199.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:19.527970 IP ussjc2-ntp-001.aaplimg.com.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:19.528007 IP ussjc2-ntp-001.aaplimg.com.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:20.162272 IP 192.168.192.138.61368 > 125-229-162-223.hinet-ip.hinet.net.123: NTPv4, Client, length 48 23:04:20.162560 IP 192.168.192.138.61368 > 125-229-162-223.hinet-ip.hinet.net.123: NTPv4, Client, length 48 23:04:20.367205 IP 192.168.192.141.123 > 106.75.185.63.123: NTPv4, Client, length 48 23:04:20.367265 IP 192.168.192.6.123 > 106.75.185.63.123: NTPv4, Client, length 48 23:04:20.374445 IP 106.75.185.63.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:20.374477 IP 106.75.185.63.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:21.368099 IP 192.168.192.141.123 > ussjc2-ntp-001.aaplimg.com.123: NTPv4, Client, length 48 23:04:21.368101 IP 192.168.192.141.123 > 106.55.184.199.123: NTPv4, Client, length 48 23:04:21.368429 IP 192.168.192.6.123 > 106.55.184.199.123: NTPv4, Client, length 48 23:04:21.368433 IP 192.168.192.6.123 > ussjc2-ntp-001.aaplimg.com.123: NTPv4, Client, length 48 23:04:21.380441 IP 106.55.184.199.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:21.380609 IP 106.55.184.199.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:21.482683 IP 192.168.192.138.59448 > time.cloudflare.com.123: NTPv4, Client, length 48 23:04:21.483070 IP 192.168.192.138.59448 > time.cloudflare.com.123: NTPv4, Client, length 48 23:04:21.523925 IP ussjc2-ntp-001.aaplimg.com.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:21.523953 IP ussjc2-ntp-001.aaplimg.com.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:21.842735 IP 192.168.192.138.58575 > time.cloudflare.com.123: NTPv4, Client, length 48 23:04:21.842812 IP 192.168.192.138.58575 > time.cloudflare.com.123: NTPv4, Client, length 48 23:04:22.367618 IP 192.168.192.141.123 > 106.75.185.63.123: NTPv4, Client, length 48 23:04:22.367788 IP 192.168.192.6.123 > 106.75.185.63.123: NTPv4, Client, length 48 23:04:22.374837 IP 106.75.185.63.123 > 192.168.192.141.123: NTPv4, Server, length 48 23:04:22.374858 IP 106.75.185.63.123 > 192.168.192.141.123: NTPv4, Server, length 48 ^C 71 packets captured 71 packets received by filter 0 packets dropped by kernel

WFANG12719 commented 3 months ago

大家的ntp服务是一直不行还是断断续续？我是后者。在win10上同步时间，四次可能只成功一次。 用wireshark捕获ntp流量发现，电脑都成功向ntp服务器的ip发起了请求，但ntp服务器在返回数据的时候，经常是服务器的另一个ip返回数据，和电脑原先发起请求的目标ip不同。两者匹配不上，同步就会失败，正好匹配上了，同步才会成功。 Desktop Screenshot 2024 05 18 - 19 36 01 69 模式是fake-ip增强，time.*.com加入了fake-ip-filter，日志里都能正常dns解析，不论直连、代理，都有这种现象。关闭openclash后，电脑会同时向几个ip发起请求，然后获得其中几个ip的回应，并同步成功，如图。 131

在路由器上确保UDP123的流量确实被放行了：需要有类似下面的iptables规则： iptables -I INPUT -p udp --dport 123 -j ACCEPT 在我的环境里我是劫持了本子网内所有客户机的UDP123流量到路由器上的。 至于ntpq 里显示的其它机器IP，NTP服务器都是配置了互联网上的NTP服务器地址作为同步时间（自建一个也是指向例如ntp.tencent.com)。所以显示的是它背后的具体IP。你运行ntpq -pw可以看到。

WFANG12719 commented 3 months ago

ntpq输出的解读如下：

前4列，remote列详细说明了我们连接到的NTP服务器。refid列表示远程服务器连接的NTP服务器。st列指的是服务器的层级，指的是服务器离我们有多“近”(数字越低，越“近”，通常越好)。t列表示类型，具体来说是服务器使用单播、广播、多播还是多播。

when列指的是距离上次轮询服务器的时间有多长。poll列表明服务器将被轮询的频率，对于示例屏幕截图中的大多数条目，轮询时间为64秒。reach列包含最近8次NTP更新的结果。如果所有8个都成功，这个字段将读取377。这个数字是八进制的，所以8个成功的八进制数将被表示为377。当您第一次在服务器上启动ntp守护进程时，这个数字可能需要一段时间才能达到377。

最后delay、offset和jitter列。delay列表示到达服务器的延迟时间，单位为毫秒。offset指的是本地时钟和服务器时钟之间的差异。jitter列指的是remote和refid服务器之间的网络延迟。

前两列信息比较重要和复杂，以下对前两列详细详细说明：

remote：本列根据配置直接访问的NTP服务器的主机名、非限定域名（FQDN）或者IP地址。而第一个字符为时钟同步状态，不同状态描述如下： x表示超出公差（被交集算法丢弃），不使用； -表示超出容忍（被交集算法丢弃），不使用；

表示良好的远程对等体或服务器，但未被使用（不在按同步距离排序的前六个对等体中，准备作为备份源）；

+表示好的和首选的远程对等体或服务器（包含在组合算法中）； o表示PPS对等体（当首选对等体有效时）。实际的系统同步是由脉冲/秒（PPS）信号派生的，或间接通过PPS参考时钟驱动或直接通过内核接口。 refid：本列显示最终获取时钟的服务器的IP地址，除了直接显示IP地址之外，本列也会通过其他的一些字符来显示远程时钟服务器访问的状态，描述如下： .LOCL. - 这个本地主机（最低层的位置标记，以防没有远程对等体或服务器可用）； .PPS. - “每秒脉冲”来自时间标准； .IRIG. - 量程仪表组时间代码； .ACTS. - 美国NIST时间标准电话调制解调器； .NIST. - 美国NIST时间标准电话调制解调器； .PTB. - 德国PTB时间标准电话调制解调器； .USNO. - 美国USNO时间标准电话调制解调器； .CHU. - CHU (HF，渥太华，ON，加拿大)时间标准无线电接收机； .DCFa. - DCF77 (LF， Mainflingen，德国)时间标准无线电接收机 .HBG. - HBG(瑞士LF Prangins)时间标准无线电接收机； .JJY. - JJY(日本LF福岛)时间标准无线电接收机； .LORC. - 罗兰- c电台(MF)时间标准无线电接收机； .MSF. - MSF (LF，英国安桑)时间标准无线电接收机； .TDF. - TDF (MF，法国阿卢瓦)时间标准无线电接收机； .WWV. - WWV (HF, Ft. Collins, CO, 美国)时间标准无线电接收机； .WWVB. - WWVB (LF, Ft. Collins, CO, 美国)时间标准无线电接收机； .WWVH. - WWVH(高频，考艾岛，HI，美国)时间标准无线电接收机； .GOES. - 美国地球同步轨道环境卫星； .GPS. - 美国的全球定位系统(GPS)； .GAL. - 伽利略欧洲卫星导航系统； .ACST. - manycast服务器； .AUTH. - 验证错误； .AUTO. - 自动键序列错误； .BCST. - 广播服务器； .CRYPT. - 自动键协议错误； .DENY. - 服务器拒绝访问； .INIT. - 初始化错误； .XFAC. - 关联改变（IP地址改变或丢失）； .MCST. - 多播服务器； .RATE. - 轮训频率过高； .TIME. - 超时； .STEP. - 步长时间变化时，偏移量小于恐慌阈值（1000ms）但大于步长阈值（125ms）

chminsc commented 1 week ago

同样问题。

WFANG12719 commented 1 week ago

1) 把软路由机器的ntpd server打开，2) 再把下面的iptables规则加入到软路由的启动运行脚本里临时解决一下：

iptables -I INPUT -p udp --dport 123 -j ACCEPT iptables -t nat -I PREROUTING -s 【你的网段地址例如192.168.1.0/24】 -p udp --dport 123 -j REDIRECT --to-port 123