2. 接入流程拆解：从请求到业务流量的完整路径

零信任接入，说白了就是「不信设备、不信位置、只信身份和策略」。但很多运维兄弟在排查故障时，往往卡在「不知道当前走到哪一步了」。我见过太多人一上来就抓包看隧道，结果发现是策略评估阶段就拒绝了——白白浪费半天时间。

所以这一章，咱们把接入流程拆成四个阶段。你只要记住每个阶段的特征，排查时就能快速定位问题。

2.1 第一阶段：用户发起接入请求

用户双击客户端，或者浏览器访问某个受保护的应用。这时候客户端会做三件事：

1. 设备环境检测：检查操作系统版本、补丁状态、是否安装杀毒软件、是否有可疑进程。
2. 身份凭证收集：可能是用户名密码、证书、或者 SSO 令牌。
3. 构造接入请求：把设备信息和身份凭证打包，发送到控制平面。

这个阶段的请求格式通常是 JSON 或 Protobuf，通过 HTTPS 发送。我建议你在控制平面入口抓个包，看看请求是否真的到达了。很多故障其实是网络不通，跟零信任本身没关系。

2.2 第二阶段：控制平面策略评估

控制平面收到请求后，开始「审问」这个用户和设备。评估过程大致如下：

评估维度	检查内容	常见失败原因
身份认证	用户名/密码、MFA、证书	密码过期、MFA 超时、证书吊销
设备信任	设备指纹、合规状态、补丁等级	设备未注册、系统版本过低、越狱/root
权限策略	用户角色、访问时间、目标应用	无权限、非工作时间、应用已下线
风险评分	异常行为、地理位置、历史记录	异地登录、频繁失败、黑名单 IP

评估通过后，控制平面会生成一个临时令牌，里面包含了用户身份、允许访问的资源列表、以及策略约束（比如只能访问 80 端口）。

2.3 第三阶段：数据平面隧道建立

拿到令牌后，客户端开始跟数据平面的网关建立隧道。这一步是技术含量最高的，也是故障高发区。

隧道建立的过程：

1. 网关发现：客户端通过 DNS 或内置列表找到最近的网关。
2. DTLS 握手：建立加密通道，交换密钥。
3. 令牌验证：网关拿着令牌去控制平面验证（或者本地缓存验证）。
4. 隧道建立：双方协商好加密参数，隧道正式通车。

隧道建立成功后，客户端会获得一个虚拟 IP 地址。这个 IP 是网关分配的，用于后续的业务流量转发。

2.4 第四阶段：业务流量转发

隧道建好了，用户终于可以访问业务了。但别高兴太早——流量转发阶段照样会出幺蛾子。

转发流程：

• 客户端把业务数据包封装在隧道里，发送到网关。
• 网关解封装，根据策略做应用层过滤（比如只允许 HTTP GET，不允许 POST）。
• 网关把数据包转发给后端业务服务器。
• 业务服务器的回包原路返回。

这个阶段常见的故障：

• 路由问题：网关不知道业务服务器在哪，或者业务服务器回包路由不对。
• 策略过于严格：比如只允许 GET 请求，但业务系统用了 POST。
• MTU 问题：隧道封装增加了包头，导致数据包超过链路 MTU，被分片或丢弃。

2.5 整体流程可视化

下面这张图把四个阶段串起来了。你可以把它贴在工位上，排查时对着看。

2.6 各阶段日志特征

排查时，日志是最好的朋友。不同阶段的日志有不同特征，我整理了一个速查表：

阶段	日志关键词	常见错误码
① 请求	CLIENT_HELLO, DEVICE_CHECK	4001 设备不合规
② 评估	POLICY_EVAL, TOKEN_ISSUE	4010 认证失败, 4030 无权限
③ 隧道	DTLS_HANDSHAKE, TUNNEL_UP	5001 握手超时, 5003 令牌无效
④ 转发	PROXY_SESSION, FORWARD	6001 路由不可达, 6002 策略拒绝