采用 Cloudflare 零信任的团队之间经常存在一个困惑：将 Access 和 Tunnel 视为同一系统的可互换部分，而实际上它们是具有完全不同职责的产品。配置隧道并假设身份验证已解决的工程师正在发布没有任何身份门的私有服务。了解每个部分的作用以及何时值得单独使用其中一个部分，将架构良好的实现与等待被利用的漏洞区分开来。
Cloudflare Access 的作用
Access 是一个身份代理。它位于主机名前面（例如 0），并在每个请求到达源之前拦截该请求。当用户没有有效会话时，Access 会重定向到配置的身份提供程序。身份验证成功后，Access 会评估与该应用程序关联的策略：用户是否属于允许的组？身份验证是否使用了 MFA？设备是否合规？如果满足所有条件，Access 会发出会话 JWT，并且请求将发送到源。
源可以是任何东西——具有公共 IP 的服务器、内部服务、隧道。访问并不关心源在哪里；他关心任何试图到达那里的人。这种区别很重要，因为这意味着 Access 在已经拥有公共 IP 的应用程序前面运行，而不需要隧道。如果您有一个具有公共 IP 的应用程序需要基于企业身份的访问控制，Access 可以解决此问题，而无需移动该应用程序或安装 1。
Cloudflare Tunnel 的作用
隧道解决了另一个问题：如何在不打开防火墙中的网关的情况下通过互联网访问专用服务器。安装在服务器上或同一网络上的容器中的 2 守护程序会建立与 Cloudflare 边缘的加密出站连接。从那里，Cloudflare 充当中介 - 入站流量到达边缘并沿着已建立的隧道传输到内部服务。
结果是内部服务器没有公共IP，没有向互联网开放的80或443端口，并且不需要安全组或防火墙中的条目规则。唯一进入的流量是来自本地运行的 3? 进程本身的流量。现在，授权用户可以通过 Cloudflare 边缘访问与直接外部访问完全隔离的服务器。
4 可以配置为 systemd 服务、Docker 容器或 Kubernetes 部署。现代设置使用 Cloudflare 仪表板来管理隧道 - 没有本地 YAML 文件，配置通过 API 传播。单个进程 5 可以在不同主机名上公开多个服务：6 转到本地端口 3000，7 转到端口 4000，8 转到端口 5050 上的 pgAdmin。
何时使用无访问通道
无访问权限的隧道是一种有效且常见的场景：您希望通过 Cloudflare 边缘路由来自公共应用程序的流量，以实现 DDoS 和 CDN 保护，而无需额外的身份验证。该服务可公开访问，但流量仅通过 Cloudflare 到达服务器，而不会直接暴露原始 IP。 Cloudflare 可防止容量攻击，并且服务器是隐藏的。
其他用途：共享本地开发。开发人员想要向网络外的人展示本地运行的原型。 9 创建一个可公开访问的临时 URL，无需 DNS 或防火墙配置。没有访问权限，没有身份验证 - 但对于特定情况很有用。
风险在于假设隧道意味着保护。这并不意味着。隧道就是连通性。如果前面没有 Access，任何到达 Cloudflare 中配置的主机名的请求都会到达您的内部服务。
何时使用不带隧道的 Access
当源已经拥有公共 IP 时（具有弹性 IP 的 EC2 上的服务器、PaaS 上的应用程序、具有公共地址的 API 端点），无需隧道的访问就有意义。 Access 充当此公共地址前面的身份代理，无需 10°。
此场景中的关键操作细节：源端需要仅接受来自 Cloudflare 边缘的流量。如果服务器持续接受任意IP的请求，只需直接访问该IP就可以绕过Access。正确的做法是将服务器配置为仅接受来自 Cloudflare IP 范围的流量，或使用 Access 注入并由应用程序验证的经过身份验证的标头。
真正实现零信任的组合
两者的结合实现了完整的零信任模型：隧道使私有服务器可以通过 Cloudflare 访问；在允许任何请求通过隧道之前，访问需要进行身份验证和策略评估。内部服务器永远不会直接暴露于互联网，也永远不会接收未经身份验证的请求。
流程：用户访问主机名→Access检查会话，必要时重定向到IdP→经过身份验证和策略检查，Access将请求转发到边缘→边缘沿着隧道→11将其传递到本地进程。内部服务器只能看到已由 Access 授权的流量。
对于机器到机器的访问 - CI/CD 管道、监控代理、集成 - 访问问题服务令牌：客户端 ID 和替代人工 SSO 流程的机密。自动化服务在请求标头中包含这些令牌，Access 将它们识别为受信任的服务身份，并应用关联的策略。通过服务令牌的每次访问也会生成一个审核事件。
系统架构者的愿景
在设计阶段忽略的一点是：Tunnel 在 Cloudflare 中没有出口成本。通过 12 的流量不收取团队计划中的带宽费用。与按传输 GB 收费的替代方案相比，这具有实际的成本影响，并影响使用 Cloudflare Tunnel 与类似隧道解决方案的决策。
采用这两个组件时的核心架构决策是：访问策略在哪里？访问权限允许您为每个应用程序创建精细的策略 - 一组可以访问管理面板，另一组可以只读访问监控，外部协作者只能访问文档门户。传统 VPN 中不存在这种粒度。维持这种粒度的成本是随着团队的变化和应用程序的发展而持续管理策略。通过 Terraform 或 Cloudflare 的 API 自动执行此操作，是将访问管理从手动任务转变为受控流程的步骤。
另请阅读
- [Cloudflare 零信任：无需 VPN 即可访问内部应用程序13
- [WARP：Cloudflare 的零信任客户端及其真正用途14
- [使用 SSO 的 Cloudflare Access：与 Okta 和 Azure AD 集成15
- [零信任 vs VPN：变革的真正成本16