本篇教程为基于上篇文章做出的延申：通过 Cloudflare Tunnels + WARP 安全暴漏整个家庭内网
需要依次配置好上篇文章中的：
- 配置允许注册到Teams中的Warp设备
- 开启 Gateway Proxy
- 配置 WARP Device Profile
本篇教程基于WARP客户端，实现登录到相同Teams的WARP设备自动跳过应用认证，直接访问内网服务。
在上一篇文章中介绍了如何使用了 Zero Trust 的 Application 保护内网隐私服务，只有通过 Policy (策略) 验证的用户才可以访问被保护的服务，而在这篇文章中将实现连接到自己 Team 的warp客户端免认证，而其他包括公网用户则需验证邮箱身份
注意事项：错误的配置可能会导致非常严重的后果，在实际应用前请确保经过测试。
配置Device Posture (设备姿态)
登录到Cloudflare Zero Trust管理页面，在 Settings → WARP Client → Device Posture中的第一个 WARP Client Check 中添加 Gateway
Device Posture（设备姿态），WARP Client Check （WARP 客户端检查），通过配置 WARP客户端检查，可以在以后的策略中添加额外判断的设备条件，比如上图的 Gateway 和 WARP，Gateway 用于检查该设备是否被注册在当前 Team 中，并且需要 WARP 连接；而 WARP 则表示当前设备必须连接到 WARP 网络中，并不经过身份认证，即 免费用户/付费用户/Teams用户 都满足此条件
举个栗子，通过添加这两个新条件，我们可以在 Application 中这样设置访问策略：1. 仅当该用户使用WARP 连接，2. 并且登陆邮箱是 abc@gmail.com 的用户才可以访问该应用
对于这样的策略，所有公网用户访问被该策略保护的应用都会直接被阻止访问，仅当使用了 WARP 访问的用户，才会进入到邮箱验证的界面。
关于Gateway和WARP的区别，在Cloudflare官网文档中这样解释：
使用Require Gateway，您可以仅允许在组织的网关实例中注册的设备访问您的应用程序。与 Require WARP 不同，Require WARP 将检查任何 WARP 实例（包括消费者版本），而 Require Gateway 将仅允许来自其流量被您组织的 Cloudflare Gateway 配置过滤的设备发出的请求。如果要通过仅允许员工访问来保护公司拥有的资产，则最好使用此策略。
修改 Application 中的保护策略
进入 Zero Trust → Access → Application 中，修改上篇文章创建的 qBittorrent 保护应用，新建一个Policy (策略) ，在当前示例中该策略命名为 Gateway，在 Action 中修改 Allow 为 Service Auth
Service Auth 的意思为：当经过某些特殊的验证程序（比如当前的Gateway，或者指定特定的访问IP）后，不需要再进行 如邮件、Gith(๐•ᴗ•๐)等的身份验证。释义来自Cloudflare文档。 效果近似于 Bypass （跳过验证）
如果 Action 配置为 Allow，则代表的意思是通过 Gateway 验证的用户才被允许进行 如邮件、Gith(๐•ᴗ•๐)等的 身份验证，这与我们的初衷（当前Gateway跳过验证不符）
在往下滑的 Rules 中找到 Gateway 选项，默认为当前 Gateway 无法改变：
保存该 Policy 后在 Application 中应该可以看见两个策略，一个为 Gateway (当前 Team 的用户免认证)，一个为 Email (如果不在当前 Team 则进行邮箱验证)，默认顺序如下
顺序无需调整，在官方文章中，Bypass 和 Service Auth 的策略总是会被优先进行。
在本地Warp客户端中登录Team
在1.1.1.1官网下载对应版本的warp客户端，这里以 Windows 客户端举例，打开设置中的账户选项，右下角选择登录到 Cloudflare Zero Trust Teams，输入自己的 Teams 名称后进行登陆验证。登陆完成后在 Zero Trust 网页端的 My Teams → Devices 即可看到登陆的设备
测试访问策略：首先关闭 WARP，尝试在的浏览器访问被保护应用的内网服务，会跳转到验证页面；打开 WARP，重新打开该服务，则会发现会直接跳过身份验证。
