连接不同站点：VPN、Tailscale、NetBird 还是 Cloudflare Mesh？

我经常参与企业网络互联的工作，也反复遇到类似的问题：连接不同站点，哪种方案最好？需要公网 IP 地址吗？安全吗？以后增加分支、换一条互联网线路或增加员工，原来的方案还能用吗？

我的回答取决于企业的实际需要。两个已有防火墙的固定站点，与多个接入条件不断变化的小型分支，起点完全不同。除了隧道，还要考虑由谁运维、在哪里控制访问，以及企业愿意维护哪些依赖。

因此，我会先理解架构，再选择产品。传统站点到站点 VPN 完全可能适合。Tailscale 或 NetBird 可以简化管理与连接建立。Cloudflare Mesh 则把数据路径放到服务商网络中。这些差别决定了各方案在什么场景下有意义。

本文重点是连接完整的站点网络。员工在家使用单台设备接入，是另一个远程访问场景，后面单独讨论。

示例：连接三个站点网络

总部使用 10.1.0.0/24，分支使用 10.2.0.0/24，家庭实验室使用 10.3.0.0/24。各站点由一个网关提供到远端网络的连接，后面的打印机和 NAS 不必安装 VPN 客户端。所有方案的目标相同：在这三个网络之间建立受控连接。

这样形成的是三层路由网络。各站点不会自动共享广播域，本地发现协议也不会全部自动跨站点工作。DNS 必须正确解析内部名称，本地路由器也必须具备通往远端网络的路由。

选择方案时，我首先想弄清哪个网络需要哪些服务。分支可能需要文件服务器，却不需要实验室的管理权限。备份服务器需要访问备份目标，而不是另一站点的全部设备。无论采用什么方案，这些决定都不能省略。

站点到站点描述连接关系，不限定拓扑

站点到站点意味着网络连接网络，并不要求所有流量都经过一台中央防火墙。以总部为中心的星型拓扑很常见；站点两两直接建立隧道，同样是站点到站点。Tailscale、NetBird 和 Cloudflare Mesh 的站点网关也能承担这个任务。

Tailscale 和 NetBird 尽量让数据直接传输，即使注册与协调采用集中管理。Cloudflare 的网络虽然在地理上分布式部署，站点流量仍然经过 Cloudflare，并不是站点之间的直接点对点连接。承担中转角色的，从自有中央防火墙变成了服务商网络。

公网 IP 与不断变化的要求

公网 IP 的问题往往很早就出现。我会区分两件事：线路能否从外部访问，以及地址是否固定。固定公网地址便于规划一个可达的 VPN 端点，但并非每个站点都必须有。分支可以主动向可达的中央网关建立出站隧道；视设计而定，动态 DNS 也能应对地址变化。

如果两端都在限制严格的运营商级 NAT 后面，又没有可直接访问的端点，情况就更复杂。尤其采用移动互联网时，应确认运营商实际提供的地址及入站连接能力。Tailscale 和 NetBird 尝试穿透 NAT 直接连接，必要时使用中继；Cloudflare Mesh 则建立通往服务商网络的出站连接。

我还希望下一次变更能够被妥善处理。增加站点、更换运营商，或改用没有入站可达性的线路，都可能让小规模配置变成另一类任务。这不意味着要提前替换正在工作的方案，但应在确定拓扑前把这些可能性纳入考虑。

传统站点到站点 VPN：由网关处理

两台防火墙或路由器建立加密隧道，通常采用 IPsec 或手动配置的 WireGuard。本地路由把发往远端网络的流量送进隧道，另一端网关解密后再转发到目标网络。

有三个站点时，总部可以充当中心，分支和实验室分别与它连接。结构更简单，但两者之间的通信要绕经总部。全互联拓扑让每对站点直接连接。n 个站点需要 n × (n − 1) / 2 条连接：三个站点只需三条，十个就要 45 条。控制器与动态机制可以降低管理负担；传统 VPN 不仅限于手动维护的中心网络。

**优点：**适合已有防火墙和清晰的站点边界。隧道端点由自己控制，数据路径中没有额外的 mesh 服务商。规则、路由和日志可以纳入原有管理体系。

**缺点：**随着站点增多，路由、密钥和运维工作量也增加。NAT、动态地址与不同厂商设备会增加排障难度。移动用户通常还需要单独的远程访问配置。

每个站点都拥有固定公网 IP，并不是普遍前提。在许多配置中，一个可达的中心，加上由分支主动建立的出站隧道，已经足够。动态 DNS 与 NAT 穿透也能提供帮助。不过两端都采用严格的 CGNAT 时，没有可达端点或中间节点，直接连接会更加困难。

对于两个稳定且已有合适防火墙的站点，这仍然是合理选择。不能仅因为另一个产品的配置字段更少，就替换正在正常工作的 VPN。

Tailscale：直接连接，集中协调

Tailscale 在 WireGuard 之上增加设备注册、协调和访问策略。控制服务帮助参与者找到彼此，业务流量尽量直接在对等节点之间传输。如果 NAT 或防火墙阻止直连，中继可提供备用路径。即使经过 DERP，流量仍在 Tailscale 对等节点之间保持加密。

子网路由器把整个 LAN 接入 tailnet。Tailscale 文档中的站点到站点方案在两端使用 Linux。后方设备不需要代理，但仍需正确路由。如果禁用源 NAT 来保留原始地址，回程路由的规划尤其重要。

**优点：**现有 LAN 设备可通过子网路由器参与。网关之间直连可避免固定绕行中央站点。也能通过同一平台添加单个用户设备。

**缺点：**不保证总能直连。中继路径的延迟与吞吐量可能不同。托管协调服务仍是运维依赖，订阅与功能也必须符合部署需求。

WireGuard 加密在对等节点终止。如果节点是子网路由器，之后的 LAN 网段就不在该隧道内。因此，即使在私有网络中，HTTPS 或 SSH 仍然有用。

NetBird：类似的 mesh，可自行托管

NetBird 也基于 WireGuard，尝试直连，并在必要时使用中继。路由对等节点连接那些设备不运行客户端的网络。当前站点到站点指南采用 Networks、Resources 以及相应访问策略。

**优点：**这个开源项目提供云服务以外的自托管选择。如果基础设施与管理责任必须由自己掌握，这一点很重要。分组与策略帮助明确限制访问。

**缺点：**自行托管意味着负责更新、备份、监控，以及协调和中继服务的可用性。安装很快并不代表这些工作消失。文档中的 Networks 站点到站点设计保持地址伪装开启，因此目标不会直接看到原始源地址。其他路由方式需要另外规划。

Tailscale 和 NetBird 关系接近，但配置不能直接互换。我会根据所需路由与身份模型评估它们。开源也不代表每项产品功能都可以不受限制地使用，部署前仍需检查许可证与功能范围。

Cloudflare Mesh：服务商网络成为数据路径

参与者主动连接 Cloudflare，站点之间的流量经过其网络。不必把每个站点与其他所有站点逐一连接，也不必维护自有中央 VPN 中心。不过，其信任边界与数据路径仍然不同于直接的 WireGuard mesh。

**优点：**把连接能力与集中 Gateway 策略结合起来。如果环境已采用 Cloudflare One，尤其值得考虑。NAT 后的站点和移动客户端可以通过出站连接接入。

**缺点：**运行与数据路径依赖服务商。对敏感数据的处理必须符合信任和隐私要求，应用层 TLS 或 SSH 仍然有用。特定应用是否受益于这条路径，需要实际测量；全球骨干网并不意味着任何地方都更快。

新部署中，我会采用当前文档规定的客户端方式。Cloudflare 将 Mesh 标为测试版，并要求节点设备配置使用 MASQUE。使用 WireGuard 时，高可用、IPv6 路由及主机名路由存在文档列明的限制。因此，路由器支持 WireGuard，并不足以证明它等同于完整的 Mesh 节点。

还要把 Mesh 与面向特定应用的 cloudflared 隧道区分开。本例关注参与者与路由网络之间双向的私有 IP 连接。

主要区别一览

这些是我优先权衡的差别。具体环境需要什么订阅、实际走哪条路径，仍要核实。

我对安全站点互联的要求

有人问哪种方案最安全时，我首先看允许哪些连接、如何管理访问。加密隧道仍可能放行过多权限。我希望明确网络可以访问哪些服务、管理员如何保护、访问权如何撤回。管理端与个人注册用户采用 MFA、限制权限、持续维护网关，都属于评估内容。

加密边界也不同。传统 VPN 在网关终止，Tailscale 和 NetBird 在对等节点之间使用 WireGuard，这些节点可能就是子网路由器。之后的 LAN 并不会自动加密。Cloudflare 网络中的处理同样必须符合企业要求。应用仍可使用 HTTPS 或 SSH 保护。

出站连接可以简化安装，避免分支开放可被公网访问的 VPN 服务，但它不能取代访问策略。公网 IP 也不会自动让防火墙变得不安全。风险取决于实际暴露的服务、保护措施和持续运维。我不会仅凭产品名称排出安全名次。

验收前我希望检查什么

来回两个方向都必须有正确路径。通往 10.2.0.0/24 的路由应放在负责的路由器或客户端上。如果目标经由另一个默认网关回复，就需要适当的回程路由。SNAT 可简化回复，却会改变日志和规则所见的地址。这应是有意识的设计决定。

高可用不仅是在覆盖网络中部署两个节点。故障之后，LAN 设备仍须能访问下一跳网关，例如使用 Keepalived 与 VRRP 提供虚拟网关地址。远端路由也须选择健康节点。验收时，我希望看到网关或隧道故障对新建和已有 TCP 会话的影响。进程仍在运行、ping 仍成功，只回答了部分问题。

功能测试也应包括故意禁止的连接。如果允许 SSH 而禁止另一应用，就应验证这个行为。ICMP 成功不代表 TCP 规则生效。注册、访问策略与目标主机防火墙必须一致。

还有一些不起眼却决定日常可用性的细节：不冲突的前缀、内部名称解析及合适的 MTU。无论 192.168.x.x 还是 10.x.x.x，都不能保证没有冲突。如果小包 ping 成功、大文件传输却卡住，我不会认为连接已经完成。

有意义的性能比较需要在真实线路上运行相同文件传输与交互式应用，并记录直连或中继路径、CPU 占用，以及更换互联网连接后的行为。我这里评估的是架构与运维差异，并未提供这些产品的实测速度排名。

远程访问：额外接入单台设备

员工从家中把笔记本接入企业网络，属于远程访问或客户端到站点。客户端运行在笔记本上，不会自动把整个家庭网络接到总部。可以使用中央防火墙的远程访问服务，也可以使用这些平台的客户端。个人注册还可以把权限关联到用户或组。

家庭办公室也能成为站点到站点的一端，由网关把获准的网络或 VLAN 接到总部。关键是连接单台设备还是整个网络，而不是人在家里还是分支工作。对个人设备，远程访问的范围往往更合适。没有必要在并非本意时让整个私人家庭网络可达。

各种方案在什么情况下适合我

对于少量固定站点和已有防火墙，我会先考虑传统 VPN，并明确选择中心辐射还是直接隧道。如果站点在 NAT 后面，希望集中管理且尽量直连，我会比较 Tailscale 与 NetBird。若必须自行运行协调服务，NetBird 应尽早评估。已有 Cloudflare One 策略的环境，我会考察 Mesh、测试版状态，以及服务商网络中的处理。额外远程访问是独立的选择标准。

Headscale 也是一个选项：它是 Tailscale 协调服务器的自托管实现，属于独立项目，有自己的功能范围，并非托管服务全部功能的完整替代。手动管理的 WireGuard 已属于传统方案，如果少量隧道足够、无需额外管理层，也很合适。

当别人问最好的方案时，我希望推荐能适应企业及下一次变化的选择。小规模部署已有防火墙，传统 VPN 仍可能最合适。不同接入条件或管理要求，则值得考虑 mesh。我会根据能否安全运维、理解必要连接，并在故障后恢复它们来决定。

下次见，
Joe