仅主机 node 能 ping 通 jumper,却同步不上 NTP?删掉一行公网 pool 就好了——chrony 选源逻辑排错全过程

目录 0. 先看答案(赶时间的人只看这一节) 1. 实验环境 2. 现象复现(问题长什么样) 2.1 node1_copy 上:ping 通 2.2 node1_copy 上:NTP 同步失败 2.3 对照:WSL 里同样混配公网源,却正常 3. 排错总思路:把链路分层,一层层排除 4. 排查过程(每一步:命令 + 输出 + 解读) 4.1 第 1 层:先排除客户端 4.2 第 2 层:确认 jumper 的 NTP 服务到底通不通(关键一步) 4.2.1 宿主机上,用 w32tm 对 jumper 三个 IP 发 NTP 探测 4.2.2 再从 WSL 里发一个「手工构造」的原始 NTP 请求 4.3 第 3 层:模拟「仅主机网段」的源 IP 去访问,排除防火墙 / allow 在拦 4.4 第 4 层:收窄到源头——node1_copy 自己的 chrony 配置 4.5 验证:删掉公网 pool 那一行,立刻恢复 5. 为什么删掉一行就好了?(核心原理,三个原因叠加) 5.1 原因一:仅主机节点没有公网出口,公网源「永远不可达」 5.2 原因二(重点中的重点):chrony 是「平滑优先」,不是「故障切换」 5.3 原因三:pool 是动态源,会不断「换人」,让选择过程更不稳定 5.4 为什么删掉那行就立刻 OK? 5.5 为什么 WSL 可以?(对照实验的真正价值) 6. 怎么彻底修好 & 加固 6.1 仅主机节点:只留内网源(本次修复) 6.2 以后 node2_copy 怎么做? 6.3 如果非要保留公网源做冗余,按推荐程度排序 7. 常用命令速查表(以后直接抄) 7.1 chrony 状态查看 7.2 chronyc sources 输出列含义(这次排错靠它) 7.3 服务管理 7.4 排查网络路径 8. 如果现象不一样:对照表(按你的现象找答案) 9. 复习要点(避坑清单) 前言 ...

August 26, 2026 · 8 分钟 · 1630 字

仅主机 node 能 ping 通 jumper,却同步不上 NTP?删掉一行公网 pool 就好了——chrony 选源逻辑排错全过程

目录 1. 实验环境与拓扑 2. 现象:ping 通,NTP 不通 3. 排查过程:一层一层剥开 3.1 第一层:是不是 MobaXterm / 客户端的问题? 3.2 第二层:jumper 的 NTP 服务到底通不通? 3.3 第三层:模拟「仅主机网段的源 IP」去访问,是不是防火墙 / allow 在拦? 3.4 收窄:问题只剩 node1_copy 自己 3.5 验证:删掉公网 pool 那一行 4. 为什么删掉一行就好了?(核心原理) 4.1 原因一:仅主机节点没有公网出口,公网源永远不可达 4.2 原因二:chrony 不是「故障切换」逻辑,而是「平滑优先」逻辑(重点) 4.3 原因三:pool 是动态源,会不断「换人」,让选择过程更不稳定 4.4 为什么删掉那行就立刻 OK? 4.5 为什么 WSL 可以?(对照组的价值) 5. 正确姿势与加固建议 6. 避坑清单(复习用) 前言 跟着黑马课程做到「时间同步」这一节,我的环境是上一篇文章里的那套拓扑:一台 jumper 双网卡/三网卡当网关,node1_copy、node2_copy 是仅主机模式的节点。 现象非常诡异:node1_copy 能 ping 通 jumper,但 chrony 就是同步不上 NTP;而同一台宿主机里的 WSL(AlmaLinux)里跑 chrony 却好好的,公网源都能用。 ...

August 26, 2026 · 5 分钟 · 874 字

VMware 仅主机 + NAT 模式下 iptables 转发失败的排错全过程(MASQUERADE 挂错网卡)

目录 1. 实验环境 2. 故障现象 3. 排查过程 3.1 检查默认网关 3.2 确认 node1 到 jumper 的内网连通性 3.3 确认 jumper 自己能上外网 3.4 确认内核转发已开启 3.5 确认 FORWARD 链放行 3.6 抓包定位(关键转折点) 3.7 查看 NAT 规则(真相浮出水面) 3.8 核对真实的外网网卡名 4. 根因分析 5. 正确配置(最终生效) 6. 避坑清单(收藏备用) 7. 写在最后 前言 今天上午做 VMware 内网流量转外网的实验,照着教程一行一行敲命令,结果 node 能 ping 通网关,却死活 ping 不通百度。 我查了路由表、翻了 iptables 规则、确认了内核转发、关了 firewalld……几乎把 Linux 网络栈翻了个底朝天,几度想直接跳过这个实验。直到最后敲下 ip route get 8.8.8.8,盯着输出沉默了三秒——教程里写的是 ens160,而我的外网网卡,叫 ens33。更讽刺的是,之前加过的重复规则把真正的问题掩盖了整整一上午。 一个网卡名的错位,一次规则的冗余,让我怀疑人生了大半天。如果你也在做 NAT 转发实验,遇到"node 能 ping 通网关却上不了外网",希望这篇排坑记录能帮你省下这几个小时——因为"低级错误"从来不低级,它只是隐蔽得恰到好处。 ...

August 18, 2026 · 5 分钟 · 1005 字
本站访客 · 访问量