国产化终端能上办公网，却登录不了 OA：一次网络准入故障排查
最近处理了一起比较有代表性的终端故障。
一台国产化办公电脑，基础网络正常，内部办公网可以正常访问，但某办公 OA 等部分业务系统始终无法登录。乍一看像是网络问题，实际排查下来，却牵扯到了国产操作系统、Windows 虚拟化、安全桌面、网络准入以及 IP 地址识别等多个环节。
整个过程还是比较有意思的，简单记录一下。
如果你遇到的是类似问题，只想直接看解决办法，可以直接跳到本文第六部分「调整网络结构」。
一、故障现象
设备操作系统为银河麒麟。用户反馈：
办公网可以正常访问，但某办公 OA 系统无法正常登录，部分新增安全准入要求的业务系统也存在类似情况。
首先做了几个基础判断。
在其他电脑上使用同一账号登录某办公 OA，可以正常使用，因此基本可以排除用户账号权限异常。
办公网访问正常，也说明终端到内部网络的基础链路整体没有问题。
问题范围逐渐缩小到了这台国产化终端自身。
二、先说一下这台电脑的特殊之处
银河麒麟属于国产 Linux 操作系统。
为了兼容大量 Windows 专用办公软件，部分国产化终端会通过虚拟化技术，在 Linux 系统底层运行一套 Windows 环境，同时借助“融合桌面”技术，把 Windows 软件直接展示在国产系统桌面中。
从普通用户的角度看，Word、浏览器以及其他 Windows 软件似乎只是麒麟系统中的普通应用。
但从技术角度来看，并不是这么回事。
底层实际上仍然存在两套彼此独立的操作系统：
- 一套是银河麒麟 Linux；
- 另一套是运行在虚拟化环境中的 Windows。
两套系统的内核不同、网络栈不同、虚拟网卡不同，IP 地址通常也不同。
因此，在排查网络问题时，完全可以把虚拟化 Windows 理解成局域网里的“另外一台电脑”。
这一点，后来成为了解决问题的关键。
三、问题开始指向“安全准入”
近期，相关单位正在统一部署新版终端安全桌面及网络准入系统。
而该安全软件主要面向 Windows 环境，无法直接安装在银河麒麟 Linux 系统中。
于是现场尝试将安全桌面安装到虚拟化 Windows 环境中。
安装虽然能够完成，但随即出现了新的问题：
安全客户端始终无法正常认证，并提示无法正确识别办公地点。
与此同时，浏览器访问某办公 OA 时，也会弹出准入检测页面，提示终端未满足相关安全要求。
到这里，基本可以判断：
问题并不是单纯的“某办公 OA 打不开”，而是终端没有顺利通过新部署的网络准入认证。
四、现场排查
到现场后，首先重新访问某办公 OA 系统。
页面随即弹出准入检查提示，一方面提示缺少相关准入组件，另一方面还检测到当前用户密码安全等级不足。
先按照要求修改了用户密码，将原密码调整为符合复杂度要求的强密码。
重启电脑后再次测试。
问题依旧。
随后重新安装安全桌面客户端。
客户端启动后要求进行用户认证，但始终认证失败，其中一个比较关键的提示是：
无法识别当前办公地点。
看到这个提示后，开始把排查重点转向 IP 地址。
五、找到关键原因：IP 不对
重新检查虚拟化 Windows 的网络配置后发现：
虚拟 Windows 当时通过虚拟网卡获取网络地址，使用的并不是单位正常分配的办公网 IP。
也就是说：
- 银河麒麟宿主系统拥有正规的办公 IP；
- 而真正运行安全桌面和浏览器的 Windows 虚拟环境，使用的却是另外一个虚拟网络地址。
这在普通网络访问场景下未必有问题。
但安全准入系统往往不仅判断“网络通不通”，还可能综合判断：
- 终端 IP 所属地址段；
- 办公区域；
- 终端身份；
- 安全客户端状态；
- 账号认证信息。
这样一来问题就比较清楚了。
安全桌面虽然安装在 Windows 中，但安全系统看到的 Windows IP 并不属于预期的办公地址范围，于是无法正确判断办公地点，最终导致认证失败。
六、调整网络结构
确认思路后，对网络配置进行了调整。
首先，将银河麒麟宿主系统原先占用的办公 IP 调整出去。
随后把 Windows 虚拟机的网络模式由原来的虚拟网络方式调整为桥接模式。
桥接之后，Windows 虚拟机不再只是通过宿主机间接访问网络，而是可以像局域网中的一台独立物理电脑一样直接接入办公网络。
最后，将原本分配给银河麒麟宿主机的正规办公 IP，手动配置到了 Windows 虚拟环境中。
重新加载网络。
再次打开安全桌面。
认证通过。
办公地点识别正常。
随后重新访问某办公 OA 系统，准入检测恢复正常，业务系统也随之可以正常使用。
至此，故障解决。
调整静态 IP 前，应先确认地址分配、交换机端口策略和准入平台的绑定关系，避免产生 IP 冲突或绕过既有安全策略。
七、问题到底出在哪里？
回头来看，这次问题其实并不复杂。
核心原因可以概括成一句话：
安全桌面运行在虚拟 Windows 中，但虚拟 Windows 使用的 IP 地址不符合网络准入系统的办公地址识别规则。
原来的网络关系大致可以理解为：
调整后变成：
真正解决问题的，并不是重新安装多少遍软件，而是搞清楚：
安全客户端究竟运行在哪个操作系统里，它看到的又究竟是哪一个 IP。
八、还留下了一个“小问题”
Windows 虚拟环境使用了原来的正规办公 IP 后，银河麒麟宿主系统自然也就不能继续同时占用这个地址。
那么，银河麒麟本身怎么办？
和用户沟通以后发现，实际日常办公过程中，大部分 Windows 专用业务软件、浏览器和办公软件本来就主要运行在虚拟 Windows 环境中，用户很少直接使用银河麒麟宿主系统访问相关业务。
所以在当前场景下，这种调整基本能够满足实际使用需求。
当然，从长期来看，这并不是最理想的最终方案。
国产操作系统、Windows 兼容环境以及统一安全准入系统之间，仍然需要在产品层面进一步解决兼容和适配问题。
九、一个容易被误判的问题
近期类似现象并非个例。
部分国产化终端都出现过：
基础内部网络可以访问，但接入新版安全准入体系后，部分业务系统无法使用。
由于普通用户看不到底层的虚拟化网络结构，很容易把这种现象简单理解为：
“国产系统不好用。”
但实际上，这次故障恰恰说明，问题未必出在国产操作系统本身。
它更像是一个典型的系统集成问题：
操作系统本身正常，虚拟化环境也正常，安全客户端也能安装，但三个系统对“终端身份”和“网络身份”的理解没有完全对齐。
单独看每一部分都没有明显故障，组合到一起却出现了问题。
这也是国产化终端运维过程中比较值得关注的一类场景。
十、排障的一点体会
这次排查最有价值的地方，并不是记住“把虚拟机改成桥接”这个操作。
因为换一个单位、换一种准入系统，解决办法可能完全不同。
更重要的是建立一个思路：
当国产化终端中同时存在 Linux、Windows 虚拟环境、安全客户端以及网络准入系统时，不要只盯着桌面上看到的那个“软件”。
应该继续往下追：
- 程序实际运行在哪个系统？
- 这个系统实际使用哪块网卡？
- 安全系统看到的源 IP 是什么？
- 准入平台到底根据什么判断终端身份和办公地点？
把这几层关系理清楚，很多看起来莫名其妙的“国产系统兼容问题”，往往就能找到真正原因。
目前，该问题也已经反馈给相关技术人员。
据反馈，后续版本将进一步优化国产化终端与安全桌面之间的兼容适配。
有时候，所谓复杂故障，不过是多个“都正常”的系统，彼此没有完全理解对方。