Cloudfalre Access应用问题一二 » 老E的博客

type

status

date

summary

1.团队域的手动加入

创建团队并在页面可以登录后，可以在客户端手动使用warp-cli命令加入团队以及进行连接，尤其是对于之前使用过warp或warp+的用户，Cloudflare Access通过统一的warp-cli提供了应用转换的途径。Cloudflare Access之于WARP、WARP+并不是升级，而是产品/服务的切换。产品切换过程中，首先需要对原有残留的公用信息进行清除（重置），包括密钥等，之后再创建并加入私有团队域，以下命令行中，teamdomainname为团队名称，token为成功登录团队域后浏览器页面F12可查阅的令牌。

warp-cli teams-enroll <teamdomainname>.cloudflareaccess.com

warp-cli teams-enroll-token com.cloudflare.warp://<teamdomainname>.cloudflareaccess.com/auth?token=<token>

warp-cli connect

warp-cli status

warp-cli account

2.客户端注册策略与控制

管理员（一般为team创建者）可在服务端进行全局配置，通过Zero Trust配置页，『settings』 -> 『WARP Client』 -> 『Device Setting』，新建或编辑当前配置。

『Device Setting』编辑页面包括了所有的Warp客户端控制，适当配置即可解决大部分网络管理问题。包括了是否允许客户端切换模式、是否允许客户端手动加入或脱离team、是否允许客户端自动连接、模式（包括proxy在内的5种模式）、域名解析回调分流、分割隧道、排除Office 365流量等。

以模式控制为例，管理员要避免客户自行通过warp-cli命令私自修改，就需要关闭客户端模式切换支持。

warp-cli set-mode proxy

warp-cli connect

对端IP的选择控制在这里是无法显式配置的，因其本身不属于官方支持范畴，没有得到任何使用授权，对端IP也不是由WARP Client进行并完成的。额外的，当某个站点打开“小黄云”使用了Cloudflare的CDN服务，那就纳入了Cloudflare CDN基础设施网络范畴，也有可能被选作对端节点，于是就会被进一步滥用。

3.身份验证策略

在Zero Trust配置页，『settings』 -> 『WARP Client』 -> 『Device enrollment』，点击『Manage』后，打开验证规则页面，可对现有验证规则进行编辑或添加新规则。

个别收不到验证邮件的，很有可能是定义了邮箱而非邮箱后缀，或者多条规则产生冲突、以及采用了不支持规则的验证方式或IdP。

验证方式默认只有一项可选即Onetime PIN，可以自定义添加后指定客户端需要采用的IdP。对于小型团队而言，可以考虑替换Onetime为Azure AD、Google Workspace等，尤其是Azure AD的使用，使用方便、国内可用，还可以激活开发者账户的活动。

4.其他

对于很多未绑定支付方式而开通team的，是不可能正常通过浏览器对团队域进行完整管理的，例如通过『settings』 -> 『WARP Client』无法直接进入『Device settings』或『Device enrollment』页面，仍然会出现添加付款方式页面，尽管可以通过url强行进入，但自寻烦恼，毫无必要。

免费、无限期、无流量限制、基于自有CDN网络，所有这些先决条件，有一项不满足就不可能被用于个人跨境访问，而50台设备和完整管理功能支持是小型团队应用的前提，对于企业级应用，偶尔还能自选一下IP以确保连接已经是底线了，额外的或频繁的操作均为滥用。

使用Cloudflare Access，首先需要明确你正在使用的是一款企业级产品/解决方案。Cloudflare Access对个人用户及爱好者算是非常友好了，应用门槛极低，并且策略性地忽视、保留了“漏洞”，免费计划的卡绑定要求也很合理，门槛低不代表无门槛，无门槛的产品必定会被滥用甚至恶意利用。话说回来，很多人除了扶墙，用过Cloudflare吗？如有更为广泛而深入的需求，开一台VPS的综合成本一定是最低的。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可