站点到站点 VPN 详解：架构与应用场景

一家有总部和两个分店的公司会遇到一个简单的问题：会计系统在一栋楼，库存数据库在另一栋楼，而需要同时用到两者的人在第三栋楼。在每两个站点之间租用专线很贵，把每个系统都开放给整个互联网又不明智。站点到站点 VPN 通过加密隧道，经公共互联网把这些网络连起来，让三栋楼就像同一个私有网络的各个部分。

本文用通俗的语言讲解其架构：网关做什么，隧道和路由如何工作，常见的布局有哪些，如何规划地址，链路故障时会怎样，这种方式适合用在哪里、不适合用在哪里。读者对象是正在评估这一方案的企业主、办公室管理人员和初级 IT 人员。如果你想了解把家庭网络和另一个网络连起来的版本，请看姊妹篇 家用站点到站点 VPN。本文关注的是企业和组织的使用场景。

站点到站点 VPN 是什么，不是什么

在站点到站点的设计里，每个地点都有一台网关，通常就是已经把该站点接入互联网的防火墙或路由器。两台网关就密钥达成一致，建立加密隧道，并让整个网络的流量通过它。各站点的电脑、打印机和服务器甚至不知道有 VPN 存在。它们把流量发往对端的某个地址，其余交给网关处理。

这是它与大多数人熟悉的 VPN 的关键区别。个人 VPN 或远程访问 VPN 在单台设备上运行软件，把该设备连到服务器；站点到站点 VPN 运行在基础设施上，连接的是网络。分支机构的员工不需要登录 VPN，因为他们的网络本来就在里面。企业 VPN 与个人 VPN 一文把这两类放在一起对比。

它不是什么：

• 它不是用于浏览网页的隐私工具。它不像个人 VPN 那样，用于对你自己的公司或网络服务商隐藏你的活动。
• 它不能替代各站点内部的安全措施。除非规则另有规定，从一个网络到达另一个网络的一切都被视为可信。
• 它不会自动变快。隧道的速度受限于两端站点的网络连接，以及网关加密流量的能力。

隧道是如何建立的

大多数站点到站点 VPN 使用 IPsec，这是 RFC 4301 中描述的一组标准。网关先协商出一条安全关系，再用它保护实际的流量。协商的标准方法是 IKEv2，见 RFC 7296。IKEv2 与 IPsec 一文用更日常的语言作了说明。

大体上，过程分为两个阶段。

1. **身份验证与密钥协商。**每台网关向对方证明自己的身份，使用预共享密钥或数字证书，并就加密所用的密钥达成一致。这一阶段有时被称为控制隧道。
2. **流量保护。**网关利用这些密钥建立承载真实数据的子连接。每个连接都是针对特定的网络对设置的。

密钥每隔一段时间会自动更换，使被截获的密钥只在很短时间内有用。好的做法是使用符合当前指南（如 NIST 的 IPsec VPN 指南）的强算法，并且在较大的部署中，优先使用证书而不是单一的共享密码，因为证书可以逐个吊销。

设备手册里会出现两种设计风格。

风格	如何决定保护什么	最适合	注意事项
基于策略	一份匹配源网络和目的网络的规则列表	地址段固定、简单的双站点部署	增加网络时规则成倍增长，两端规则不匹配会导致无声的失败
基于路由	虚拟隧道接口，由路由表决定哪些流量使用它	多站点、动态路由、故障切换	需要路由知识，错误的路由可能把流量送错方向

基于路由的设计通常更容易扩展，所以当企业的站点超过两三个时，它占据主导地位。

布局：点对点、星型与网状

隧道如何布局，与单条隧道如何建立同样重要。

• **点对点。**两个站点，一条隧道。简单，容易排查。适合只有一个分支的总部，或者有独立仓库的公司。
• **星型（hub-and-spoke）。**一个中心站点作为 hub，向每个分支（spoke）各有一条隧道。分支之间的流量经由 hub 转发。隧道数量少，也有一个统一施加规则的地方，但 hub 会成为单点故障和瓶颈。
• **全网状（full mesh）。**每个站点与其他每个站点都有隧道。分支之间的流量直接传输，速度快。隧道数量增长很快：五个站点需要十条隧道，十个站点需要四十五条，除非设备能自动化，否则管理会成为负担。
• **部分网状。**大部分流量采用星型，仅在经常互通的站点之间建立直连隧道。
• **连接云。**从办公室到云服务商的虚拟网络建立一条或多条隧道，使托管在那里的服务器看起来像是私有网络的一部分。

一个有用的原则是：从最能匹配人们实际数据流向的最简单布局开始。如果分支只与总部通信，星型就足够了。

先规划地址，再做其他事

隧道“已连上但什么都不通”的最常见原因是地址问题。每个站点都需要自己的私有地址段，且地址段不得重叠。RFC 1918 定义了大多数网络内部使用的私有地址范围。

举个例子。两个办公室都使用 192.168.1.0/24。办公室 A 的一台电脑要访问 192.168.1.20。那是自己办公室里的打印机，还是办公室 B 的服务器？它无从分辨，于是假定是本地的，隧道根本不会被用到。

实用的规划规则：

1. **给每个站点分配不同的地址段，**例如总部用 10.10.0.0/24，第一个分支用 10.20.0.0/24，第二个分支用 10.30.0.0/24。
2. **为增长留出空间。**将来用完的小地址段会迫使你痛苦地重新编号。
3. **在文档里维护一张简单的地址段表，**有变动就更新。
4. **避开家用路由器默认使用的地址段，**因为员工可能在家里使用远程访问 VPN，从而与之冲突。
5. **如果已经存在重叠，**可以在网关上使用地址转换，把一个站点的地址段映射到另一个，但会增加复杂度。如果承担得起，给其中一个站点重新编号通常是更干净的办法。

出现故障时会怎样

承载会计系统的隧道属于关键基础设施，所以要为它的故障做好打算。

• **某个站点的互联网中断。**隧道断开，该站点的员工无法访问远程系统。第二条互联网线路，即使不快，也能让它恢复。支持双上行的网关会自动切换。
• **网关故障。**备用设备，或一对工作在高可用模式的网关，可以让隧道保持在线。
• **失效对端检测。**网关检查对端是否存活，不存活时重建隧道。务必确认该功能已开启。
• **密钥或证书过期。**隧道可能仅仅因为证书到期，就在午夜停止工作。把到期日期写进日历。
• **MTU 问题。**加密后的数据包会稍大一些。如果超过路径能承载的大小，有些流量正常，有些则莫名其妙地卡住。VPN 的 MTU 问题 一文描述了这种症状，RFC 1191 解释了背后的路径机制。
• **监控。**一个每分钟 ping 一次隧道对面某系统、并通知相关人员的简单检查，就能给你提前预警。

典型应用场景

场景	隧道的作用	为什么适合站点到站点 VPN
总部与分支机构	让分支访问共享文件、财务和电话系统	一套集中的系统，不暴露在互联网上
仓库或工厂	把机器和库存系统接入总部	不能运行 VPN 软件的设备也能接入
门店与收银系统	把收银机连到中央数据库或支付网关	许多相同的小站点，流量可预测
上云迁移	把办公室连到云服务中的虚拟网络	云上的服务器看起来像本地网络
合并与合作伙伴	给两个组织一条通往特定系统的窄链路	可以把访问限制在所需的系统上
备份与复制	每晚把数据传到第二个站点	加密的副本存放到另一个地点

对于合作伙伴的情形，窄规则很重要。通往另一家公司的隧道，应只允许必需的系统和端口，而不是整个网络。

三个场景

**诊所集团。**一家医疗机构有一家主诊所和两家分诊所。病历存放在主诊所的服务器上。每家分诊所的防火墙以星型结构向主诊所建立隧道。分诊所的员工打开病历系统，就像它在本地一样。网关还限制哪些设备可以访问病历服务器，所以候诊区的访客笔记本无法访问。当一家分诊所的光纤线路中断时，防火墙切换到备用的移动数据连接，隧道在一分钟内恢复。

**网络零售商。**一家小型零售商把网店跑在云上，但仓库系统放在办公室后面的房间里。从办公室到云网络的隧道让网店能以私有方式向仓库系统发送订单。团队仔细规划了地址段，发现云网络的默认地址段与办公室重叠。他们在部署任何东西之前就为云网络选了新的地址段，省去了日后数周的麻烦。

**租了第二间作坊的工匠。**一位工匠在城市另一端租了第二间作坊。他需要原来那间的库存清单和共享打印机。一对小型路由器加上点对点隧道就能完成。由于第二个地点的网络服务商使用共享地址，其中一台路由器无法接受入站连接，所以把这一对设备配置为始终由第二个地点发起隧道。VPN 与 CGNAT 一文解释了为什么会这样。

应当避免的错误

• 在两个站点使用相同的私有地址段。
• 所有隧道都使用同一个薄弱的共享密码。
• 只需要一两个系统时，却把整个网络都开放给隧道。
• 忘记隧道内部的防火墙规则。除非你进行过滤，否则隧道里的流量就是可信的。
• 跳过监控，结果隧道坏了的第一个信号是员工打来的电话。
• 运行过时的网关固件。网关面向互联网，是常见的攻击目标。
• 为六个站点构建全网状，却没有管理隧道的计划。
• 把隧道当作按用户访问控制的替代品。站点到站点 VPN 信任的是网络，因此应考虑增加更严格的控制，相关内容见 零信任与 VPN 的区别。

总结

站点到站点 VPN 通过网关之间建立的加密隧道连接整个网络，通常使用 IPsec 和 IKEv2。员工和设备无需运行 VPN 软件。成功取决于规划：互不重叠的地址段、与实际流量相匹配的布局、便于增长的基于路由的设计、范围收窄的规则、为关键站点配备第二条互联网线路，以及能在隧道中断时告警的监控。它保护的是站点之间的链路，而不是每个网络内部发生的事，因此其余的安全措施仍要保留。

如果你出行时还想为自己的设备准备一个个人工具，价格页面 列出了面向个人的简单预付选项。