OpenZiti 入门（9）：用策略限制谁能访问服务

OpenZiti 入门（8），我们让 Windows 客户端通过 Ziti 访问了 local-web。这一篇继续完善访问控制：只授权指定身份使用服务，并确认提供服务的一端也有相应权限。

OpenZiti 的策略把身份、服务和 Edge Router 之间的关系分开管理。配置时要区分三类策略：

因此，客户端获准 Dial 服务还不够：客户端身份和服务还必须至少有一个共同的在线 Edge Router。官方 Policies 概览 和 创建第一个服务 对这些关系有详细说明。

一、准备角色属性

本篇沿用前文的示例名称：

text
客户端身份：windows-laptop
客户端角色属性：windows-client
服务名称：local-web
服务端身份：ubuntu-host

其中 ubuntu-host 是占位名称，请换成实际提供服务的身份。如果是由开启了 tunneler 的 Router 承载服务，Bind 策略应指向该 Router 对应的身份。

角色属性用于把多个身份或服务归为一组。设置属性时，属性名本身不带 #；在策略中引用角色属性时才加 #。例如，身份属性写作 windows-client，策略中引用为 #windows-client。

二、创建 Dial 策略，授权客户端访问

在 ZAC 中打开 Policies / Ziti Policies → Service Policies，新建一条 Service Policy：

text
名称：local-web-dial
类型：Dial
Service Attributes：@local-web
Identity Attributes：#windows-client

@local-web 指定一个具体服务，#windows-client 则匹配带有 windows-client 角色属性的身份。这样，windows-laptop 可以通过该角色属性获得访问权限；其他没有匹配此策略的身份不会因此获得 Dial 权限。

官方 Service Policy 创建指南 也提供了通过 ZAC 或 CLI 配置策略的步骤。

三、确认 Bind 策略，授权服务端提供服务

服务还需要一个 Bind 策略，让承载服务的身份可以向 Ziti 网络提供它。在 Service Policies 中确认存在类似以下配置：

text
名称：local-web-bind
类型：Bind
Service Attributes：@local-web
Identity Attributes：@ubuntu-host

如果前文已经创建了正确的 Bind 策略，不要重复创建；检查服务端身份是否匹配即可。如果承载服务的是 Router tunneler，就把 @ubuntu-host 替换为实际的 Router 身份。

Dial 和 Bind 是不同的权限：前者允许身份使用服务，后者允许身份提供服务。常见配置是为客户端身份授予 Dial，为服务端身份授予 Bind。

四、检查 Router 策略

再确认两条 Router 关系都成立：

1. Edge Router Policy 允许 windows-laptop 连接至少一个在线 Edge Router。
2. Service Edge Router Policy 允许 local-web 使用至少一个在线 Edge Router。

如果沿用第 7 篇的 Quickstart 公网网络，先检查 Quickstart 创建的默认 Router 策略是否仍在，并且目标 Router 在线。身份和服务必须有共同的在线 Router 才能建立连接；两者各自有 Router 权限，但没有交集时，服务仍不可达。

五、验证授权结果

如果已登录控制器的 ziti CLI，可以用 Policy Advisor 检查指定身份和服务：

bash
ziti edge policy-advisor services local-web windows-laptop -q

预期结果应显示客户端对 local-web 的 Dial 为 Y，且 Common Routers 至少有一个。再检查服务端身份：

bash
ziti edge policy-advisor services local-web ubuntu-host -q

服务端应显示 Bind 为 Y，并且有至少一个共同 Router。Policy Advisor 也可帮助发现服务策略缺失、没有共同 Router 等问题；用法见官方 Policies 概览。

最后回到 Windows 客户端，确认 Ziti Desktop Edge 已连接，再测试：

powershell
curl.exe -v http://hello.ziti/

服务域名仍由前文的 intercept.v1 配置决定；如果实际配置的域名不同，请相应替换 hello.ziti。

常见问题

服务没有出现在客户端中

检查 Dial 策略中的身份和服务是否匹配，以及 Windows 身份是否带有 windows-client 属性。

客户端能连接 Router，但服务不可达

检查 Dial 和 Bind 是否都已授权，并确认服务与身份有共同的在线 Router。若服务端无法提供服务，再检查 Bind 身份在线状态和 Host 配置。

修改策略后访问结果没变化

确认修改的是客户端实际使用的网络和身份；还要检查是否存在另一条覆盖范围更广的策略。测试用的 #all 规则可能让权限范围超出预期，生产环境应尽量使用具体身份或经过规划的角色属性。

通过这套策略，客户端身份只获得访问指定服务的权限，服务端身份只负责提供该服务。下一篇可以在此基础上加入设备状态检查，让策略根据客户端的安全状态决定是否允许访问。