银河麒麟 V10 内网配置事件复盘

背景

这次事件发生在一台新领到的银河麒麟桌面操作系统 V10 电脑上。电脑由单位预先配置了有线内网，主要用于访问单位业务系统。

表面看，单位已经配置好了 IP 地址、网关等信息，但第一次重启后，部分业务系统无法访问，尤其是：

http://ips.sx.hsip.gov.cn/#/home

而与此同时，内网网关可以 ping 通，另一个内网资源也可以进入。这导致一开始很容易误判为“内网整体是通的，只有某个网站异常”。

后续排查证明，这不是单纯的网站问题，也不是物理线路问题，而是一次典型的内网 DNS 与跨网段路由没有完整恢复的问题。

当时的内网基础配置

根据后续排查记录，当时有线内网的关键配置如下：

项目	值
操作系统	银河麒麟桌面操作系统 V10 SP1
网络管理工具	NetworkManager
有线接口	enaphyt4i0
连接名称	有线连接 1
IPv4 地址	10.32.98.120/24
内网网关	10.32.98.254
内网 DNS	10.30.255.1
目标业务域名	ips.sx.hsip.gov.cn
目标业务地址	10.30.20.107

其中最容易被忽略的是：本机地址在 10.32.98.0/24 网段，而目标业务系统解析后的地址在 10.30.20.107。二者不是同一个网段。

也就是说，本机能直接到达的只是：

10.32.98.0/24

目标业务系统所在的是：

10.30.0.0/16

要访问目标业务系统，必须满足两个条件：

1. 域名 ips.sx.hsip.gov.cn 能被内网 DNS 正确解析。
2. 到 10.30.0.0/16 这段地址的流量能通过 10.32.98.254 转发。

首次重启后的现象

首次重启后出现的现象大致是：

1. 内网网关可以 ping 通。
2. 部分内网资源可以访问。
3. ips.sx.hsip.gov.cn 无法访问。

这个现象的迷惑性很强。因为网关能 ping 通，容易让人认为“内网已经通了”。但从网络路径上看，ping 通网关只能证明第一跳是通的：

本机 10.32.98.120 -> 网关 10.32.98.254

它不能证明下面这条完整路径也通：

本机 10.32.98.120 -> 网关 10.32.98.254 -> 目标 10.30.20.107

另一个内网资源能访问，也只能证明那一个资源所在路径可达，并不能证明 ips.sx.hsip.gov.cn 所依赖的 DNS 和跨网段路由都是正常的。

重启后发生问题的直接原因

这次事件中，第一次重启后的直接原因可以概括为：

NetworkManager 连接配置恢复不完整。

这里的“不完整”不是说有线连接完全没有恢复，而是它只恢复了基础链路，未完整恢复业务系统访问所需的附加配置。

从现象看，系统重启后至少恢复了这些内容：

物理连接可用
本机地址可用
内网网关可达
部分内网资源可访问

但访问 ips.sx.hsip.gov.cn 还需要额外两项配置：

内网 DNS：10.30.255.1
目标网段路由：10.30.0.0/16 via 10.32.98.254

这两项要么没有被 NetworkManager 正确带起来，要么原本就是临时配置，重启后没有持久化。因此重启后出现了“基础内网看起来还在，但指定业务系统打不开”的状态。

换句话说，这次不是网线断了，也不是网关坏了，而是 NetworkManager 重启后只恢复到了“能到第一跳”的程度，没有恢复到“能访问完整业务路径”的程度。

为什么重启会暴露这个问题

Linux 系统重启后，运行时网络状态会被清空。NetworkManager 重新启动时，只会根据已经持久化保存的连接配置重新建立网络。

因此，重启本身不是导致网络损坏的根因。真正的问题是：首次配置时让业务系统可用的某些配置，可能只是临时生效，或者没有完整写入 NetworkManager 的连接 profile。第一次重启后，这些临时状态消失，系统只按已保存的基础配置恢复。

常见情况有以下几种。

第一，配置人员可能临时加过路由：

sudo ip route add 10.30.0.0/16 via 10.32.98.254

这种命令执行后会立即生效，但它属于运行时状态。只要没有写入 NetworkManager 连接配置，重启后就会丢失。正确的持久化方式应该类似：

sudo nmcli connection modify "有线连接 1" +ipv4.routes "10.30.0.0/16 10.32.98.254"

第二，DNS 配置可能没有完整保存。银河麒麟 V10 使用 NetworkManager 和 systemd-resolved 管理域名解析，/etc/resolv.conf 往往不是手工维护的静态文件，而是由系统服务动态生成。重启后，DNS 配置会重新生成。如果 10.30.255.1 没有正确写入连接配置，系统就可能不再使用内网 DNS 解析业务域名。

第三，同一个有线接口可能存在多个连接 profile。图形界面显示“已连接”，并不等于当前激活的一定是单位配置好的完整连接。NetworkManager 有时会激活一个自动生成的基础连接，结果就是本机有地址、网关可达，但缺少业务系统需要的 DNS 和静态路由。

第四，NetworkManager 判断连接成功的标准偏底层。只要接口能起来、IP 配置完成、网关可达，它就可能认为连接已经成功。它不会自动验证某个具体业务域名是否能解析，也不会验证 HTTP 页面是否能打开。

所以第一次重启后的实际状态更准确地说是：

基础网络恢复了
业务系统所需的 DNS / 静态路由没有完整恢复

这正好解释了为什么会同时出现：

网关能 ping 通
部分资源能进入
ips.sx.hsip.gov.cn 不能访问

问题的关键点

1. 域名依赖内网 DNS

ips.sx.hsip.gov.cn 不是随便一个公开域名。后续排查时发现，普通 DNS 无法解析它，必须使用单位内网 DNS。

直接指定内网 DNS 后，可以得到目标地址：

nslookup ips.sx.hsip.gov.cn 10.30.255.1

结果中可以看到：

Name:    ips.sx.hsip.gov.cn
Address: 10.30.20.107

这说明访问这个系统的第一步不是 HTTP 请求，而是先依赖内网 DNS 把域名解析到 10.30.20.107。

如果系统重启后 DNS 没有正确恢复，就会表现为浏览器无法打开该地址。

2. 目标地址不在本机直连网段

本机地址是：

10.32.98.120/24

这表示本机直连网段是：

10.32.98.0 - 10.32.98.255

但目标地址是：

10.30.20.107

它不在 10.32.98.0/24 里。要访问它，必须由网关 10.32.98.254 转发。

因此，仅有 IP 地址和能 ping 通网关还不够。系统还需要知道：

10.30.0.0/16 这段地址应该交给 10.32.98.254

如果这条路由在首次配置时只是临时加上的，重启后就会丢失。

3. NetworkManager 只恢复了基础连接

从后续排查结果推断，第一次重启后，NetworkManager 很可能只恢复了基础连接：

本机地址可用
网关可达
部分资源可达

但没有完整恢复访问 ips.sx.hsip.gov.cn 所需的配置：

内网 DNS
10.30.0.0/16 的跨网段路由

这就是为什么看起来“内网没有全断”，但核心业务系统仍然无法访问。

排查过程

查看接口地址

ip addr show enaphyt4i0

关注是否存在类似输出：

inet 10.32.98.120/24

如果没有 inet 地址，说明静态地址没有真正应用到接口上。

查看 NetworkManager 连接配置

nmcli connection show "有线连接 1"

重点看这些字段：

ipv4.method
ipv4.addresses
ipv4.gateway
ipv4.dns
ipv4.routes

当时需要确认的核心配置是：

ipv4.method:    manual
ipv4.addresses: 10.32.98.120/24
ipv4.dns:       10.30.255.1

查看路由表

ip route

关键是检查是否有到 10.30.0.0/16 的路由。

期望看到类似：

10.30.0.0/16 via 10.32.98.254 dev enaphyt4i0
10.32.98.0/24 dev enaphyt4i0 src 10.32.98.120

如果只有 10.32.98.0/24，说明本机只能确认直连网段，访问 10.30.20.107 还缺少明确路径。

测试网关

ping -c 3 10.32.98.254

这个命令只能验证本机到第一跳是否可达。它是必要检查，但不能作为完整业务系统可达的证明。

测试内网 DNS

nslookup ips.sx.hsip.gov.cn 10.30.255.1

如果能解析出：

10.30.20.107

说明 DNS 服务器本身知道这个业务域名。

测试目标地址路径

ip route get 10.30.20.107

理想结果应该类似：

10.30.20.107 via 10.32.98.254 dev enaphyt4i0 src 10.32.98.120

这说明系统会把访问目标业务系统的流量交给正确的内网网关。

测试业务站点

curl -v --connect-timeout 10 --noproxy '*' "http://ips.sx.hsip.gov.cn/"

后续修复成功时，返回过：

HTTP/1.1 200

这说明业务系统已经能够正常响应。

最终修复方式

1. 固定内网 DNS

sudo nmcli connection modify "有线连接 1" ipv4.dns "10.30.255.1"
sudo nmcli connection modify "有线连接 1" ipv4.dns-search "hsip.gov.cn"

这一步的目的，是让系统知道内网域名应该由单位内网 DNS 解析。

2. 固定到目标网段的路由

sudo nmcli connection modify "有线连接 1" +ipv4.routes "10.30.0.0/16 10.32.98.254"

这一步是本次事件的关键修复项。

它的含义是：

访问 10.30.0.0/16 时，走 10.32.98.254 这个内网网关

这样即使系统重启，也能恢复到目标业务网段的访问路径。

3. 固定业务域名解析

由于系统的 DNS 管理组件在域名解析上表现不稳定，最后采用了更直接的兜底方式，把业务域名写入 /etc/hosts：

10.30.20.107 ips.sx.hsip.gov.cn

操作方式：

sudo cp /etc/hosts /etc/hosts.bak
sudo sh -c 'echo "" >> /etc/hosts'
sudo sh -c 'echo "# 内网业务系统" >> /etc/hosts'
sudo sh -c 'echo "10.30.20.107 ips.sx.hsip.gov.cn" >> /etc/hosts'

这一步绕过了域名解析不稳定的问题。只要目标地址没有变化，系统就能直接把域名映射到正确地址。

4. 重新激活连接

sudo nmcli connection down "有线连接 1"
sudo nmcli connection up "有线连接 1"

重新激活后，再检查：

ip addr show enaphyt4i0
ip route
curl -s --connect-timeout 5 --noproxy '*' "http://ips.sx.hsip.gov.cn/" -o /dev/null -w "%{http_code}\n"

期望结果：

200

事件复盘

这次问题的根本点在于：我最初把“内网能不能用”理解成一个整体判断，但实际网络访问是分层的。

网关能 ping 通，只能说明本机到第一跳可达。

另一个资源能访问，只能说明那条路径可达。

ips.sx.hsip.gov.cn 能不能访问，则取决于：

域名是否能解析
解析出来的目标地址是否有路由
目标服务是否响应 HTTP 请求

这三个条件缺一不可。

首次重启后，系统并不是完全没有内网，而是没有完整恢复访问该业务系统所需的配置。后续通过固定内网 DNS、添加 10.30.0.0/16 路由、写入 hosts 记录，才把隐含依赖变成了明确配置。

后续维护建议

1. 保存当前连接配置

nmcli connection show "有线连接 1" > ~/wired-connection-1.txt
ip route > ~/route-table.txt
cat /etc/hosts > ~/hosts-backup.txt

这些文件可以作为以后重装系统或更换电脑时的参考。

2. 每次重启后做三项检查

ip addr show enaphyt4i0 | grep "10.32.98.120"
ip route | grep "10.30.0.0/16"
grep "ips.sx.hsip.gov.cn" /etc/hosts

三项都存在，再测试业务页面。

3. 不要只看图形界面的连接状态

图形界面显示“已连接”只能说明连接配置处于激活状态，不代表 DNS、路由和业务系统都正常。

更可靠的判断方式是：

ip addr
ip route
nslookup
curl

4. 修改配置前先备份

sudo cp /etc/hosts /etc/hosts.bak.$(date +%Y%m%d)
nmcli connection show "有线连接 1" > ~/wired-connection-before-change.txt

这样即使改错，也能快速回退。

总结

这次事件可以概括为一句话：

银河麒麟 V10 首次重启后，内网基础链路仍然存在，但访问 ips.sx.hsip.gov.cn 所需的 DNS 和跨网段路由没有完整恢复。

真正的修复不是简单“重新连接”，而是把关键依赖固化：

10.30.255.1 负责解析内网域名
10.30.0.0/16 通过 10.32.98.254 转发
ips.sx.hsip.gov.cn 固定到 10.30.20.107

这也是这次事件最大的收获：排查网络问题时，不能只看某一个资源是否能访问，而要分别确认地址、DNS、路由和应用层响应。