使用 Cloudflare 访问受严格防火墙保护的服务器

Source: Dev.to

使用 Cloudflare Tunnel 的注意事项

我在几种不同的场景中使用 Cloudflare Tunnel。

一种使用场景是远程开发。我在本机上运行 cloudflared 并通过隧道暴露 SSH。服务器会向 Cloudflare 发起出站连接。访问通过 Cloudflare Access 并使用一次性密码（OTP）进行控制。

Cloudflare 还提供基于浏览器的 SSH。使用手机（包括 iPhone）时，我可以打开 Safari，进行身份验证，然后直接在浏览器中获得终端会话。在这种情况下不需要单独的 SSH 客户端。

SSH 流程

flowchart LR
    A[Local Machine] --> B[cloudflared]
    B --> C[Cloudflare Edge]
    C --> D["Access Policy (OTP)"]
    D --> E[Browser SSH Session]

本机保持出站隧道。身份验证在边缘完成，然后才建立会话。

暴露 Web 服务

我也使用 Cloudflare Tunnel 将小型 Web 服务暴露出来，适用于我无法控制公共 IP 配置的网络。机器向 Cloudflare 发起出站连接，流量再通过该连接返回。

这使得静态站点或内部工具能够在不管理 NAT 规则或动态 DNS 的情况下被访问。

flowchart LR
    U[User] --> DNS[Cloudflare DNS]
    DNS --> Edge[Cloudflare Edge]
    Edge --> Tunnel[Cloudflare Tunnel]
    Tunnel --> Service[Local Web Service]

在某些情况下取代 Tailscale

对个人使用而言，这在只需要安全访问单台机器或单个服务的情况下已经取代了 Tailscale。无需维护私有网状网络，访问通过 Cloudflare 的身份层来强制执行。

这并不是对私有网络的通用替代方案，但对单个服务来说，它简化了部署。

潜在的 Kubernetes 组合

Cloudflare Tunnel 也可以与 Kubernetes 结合使用。集群可以位于隧道之后，Ingress 通过 Cloudflare 路由，而 Pod 则保持在集群内部私有。Kubernetes API 服务器和内部服务可以放在 Access 策略之后。

我尚未部署此配置，但其模式遵循相同的出站隧道模型。

总结

Cloudflare Tunnel 提供：

• 仅出站连接
• 基于身份的访问（OTP / Access 策略）
• SSH
• 边缘的 DNS 与 TLS 集成
• 在受限网络中暴露服务的实用方式

对于远程访问和轻量级托管，它简化了基础设施，无需直接暴露底层系统。