站点到站点VPN是什么？详细讲解

凌晨两点，我被电话铃声吵醒。电话那头是公司运维主管老周，声音里带着明显的焦躁：“上海办公室连不上总部机房了，财务系统、OA、文件服务器全部超时，明天一早还要出月度报表。”

我打开电脑，远程连上总部的核心交换机，发现上海出口路由器的IPsec隧道状态是down的。再查日志，凌晨一点十七分，运营商线路发生了一次闪断，隧道重协商失败，两端SA（安全联盟）全部失效。问题不复杂，但暴露了一个关键事实：这家公司跨城办公的网络，靠的就是一条站点到站点VPN。它平时安静得像不存在，一旦断掉，整个业务链条立刻停摆。

这篇文章就从这次事故讲起，把站点到站点VPN是什么、怎么工作、怎么部署、怎么排错，尽量讲透。

一、那条“看不见的网线”到底是什么

1.1 从一个具体场景理解它

上海办公室有四十多名员工，总部机房在苏州，里面有ERP、财务、代码仓库和NAS。两地之间没有专线，只有各自的一条宽带。员工在上海打开财务系统时，电脑发出的数据包先到上海出口防火墙，防火墙把整个包“装进”一个新的IP包外壳里，加密后通过公网送到苏州出口设备，苏州设备拆壳、解密、还原原始数据包，再转发给机房里的服务器。回程同理。

对上海员工来说，财务系统的地址看起来就像在本地网络里一样，他们不需要拨号、不需要登录客户端、不需要做任何额外操作。这条“看不见的网线”，就是站点到站点VPN，也叫Site-to-Site VPN、LAN-to-LAN VPN。

1.2 与远程访问VPN的关键区别

很多人第一次听到VPN，想到的是员工在家装个客户端、输入账号密码连公司。那是远程访问VPN（Remote Access VPN），终端是“一台设备一个人”。站点到站点VPN的两端是“两个网络边界设备”——防火墙、路由器或VPN网关。它连接的不是某个人，而是两个网段。

这个区别带来三个直接后果：第一，站点到站点VPN对终端用户完全透明，员工无感知；第二，它的策略配置以“网段到网段”为单位，而不是“用户到资源”；第三，它的可用性要求更高，因为一条隧道断掉，可能意味着几十上百人同时无法工作。老周那通凌晨电话，正是第三点的现实注脚。

1.3 它解决的核心问题

站点到站点VPN本质上解决三件事：一是让地理上分散的局域网通过公网互联，成本远低于租用专线；二是用加密和认证保证数据在公网上传输时不被窃听和篡改；三是让两端内网地址空间可以规划成互不冲突的私有网段，通过路由把流量引导进隧道。

二、它是怎么工作的：隧道、加密与协商

2.1 隧道不是一条物理链路

“隧道”是个形象说法。实际发生的是封装：原始IP包被当作载荷，套上新的外层IP头，外层头里的源和目的地址是两端公网出口地址。数据在公网上走的时候，中间路由器只看到外层头，看不到里面真实的私有地址和内容。到达对端后，外层头被剥离，原始包重见天日。

常见的封装协议有两类：IPsec（工作在网络层）和SSL/TLS VPN（多用于远程接入，也有站点到站点的实现）。企业跨城互联里，IPsec仍是主流，因为它对上层应用完全无感，不挑协议、不挑端口。

2.2 IPsec的两个阶段

IPsec的协商分两步，理解这两步，排错时就不会抓瞎。

第一阶段叫IKE SA，两端先建立一条管理通道，互相验证身份、协商加密算法、生成后续用的密钥。身份验证方式常见的是预共享密钥（PSK）和数字证书。老周那次事故里，隧道down掉后重协商失败，问题就出在第一阶段——运营商闪断导致一端认为SA还有效，另一端已经清空，两边状态不一致，重协商时参数对不上。

第二阶段叫IPsec SA，在管理通道保护下，为实际的数据流协商加密参数。这一阶段会明确“哪些源网段到哪些目的网段”的流量走隧道，也就是感兴趣流（interesting traffic）。配置时如果两端感兴趣流写反了或者网段不匹配，典型现象是隧道显示up但业务不通。

2.3 路由怎么把流量送进隧道

隧道建好后，还得让流量知道往隧道里走。两种常见方式：一是静态路由，把对端网段指向隧道接口或对端网关；二是动态路由协议，比如OSPF、BGP over IPsec，适合站点多、拓扑复杂的场景。上海办公室那次故障恢复后，我建议老周把静态路由改成带BFD检测的动态路由，让隧道故障能被更快感知和切换。

三、典型部署形态与选型考虑

3.1 星型与全网状

星型拓扑是总部为中心，各分支分别与总部建隧道，分支之间不直接互通。配置简单、策略集中，适合大多数中小企业。缺点是分支间通信要绕总部，总部设备成为单点和性能瓶颈。全网状拓扑是任意两个站点之间都建隧道，时延更优、无单点，但隧道数量随站点数平方增长，配置和运维复杂度陡增。折中方案是部分网状，或者用SD-WAN控制器统一编排。

3.2 设备形态

可以是两台防火墙之间的IPsec，可以是路由器上的GRE over IPsec，也可以是云上VPC的VPN网关与本地设备对接。混合云场景里，站点到站点VPN经常承担“本地机房到云上VPC”的私有通道角色。选型时要看三点：吞吐与并发隧道数是否够用、是否支持IKEv2和强加密套件、是否有可观测性（隧道状态、流量统计、日志）。

3.3 一个容易被忽略的细节：MTU

封装会增加包头长度，导致实际可传输的载荷变小。如果两端MTU和MSS处理不当，典型症状是“小包能通、大包卡死”——网页能打开一半、文件传到某个大小就断。上海那次恢复后，我们顺手在两端接口上做了TCP MSS clamping，避免以后再踩这个坑。

四、从故障复盘看运维要点

4.1 那次事故的完整链条

运营商线路闪断约四十秒，两端IPsec SA未同时失效；线路恢复后，一端发起重协商，另一端仍持有旧SA，参数不匹配导致协商失败；由于没有配置DPD（死亡对等体检测）或DPD参数过宽松，故障未被及时感知；静态路由仍然指向隧道，流量被黑洞丢弃。最终表现为业务全面超时。

4.2 可落地的改进项

启用DPD并设置合理间隔，让两端能快速发现对端不可达；把IKEv2作为首选，它的重协商和故障恢复机制比IKEv1更稳健；关键链路配置双运营商加BFD，主备切换不依赖人工；监控上至少采集隧道状态、协商失败次数、加解密丢包数三项指标，并配置告警；变更管理上，两端参数变更必须同步窗口执行，避免“一端改了、一端没改”的经典事故。

4.3 安全边界不能只靠隧道

站点到站点VPN解决的是传输安全，不等于内网安全。隧道两端的内网仍然需要分段、访问控制和主机防护。感兴趣流要尽量收紧，只放行业务需要的网段和端口，不要把整个私有地址空间一股脑塞进隧道。预共享密钥要定期轮换，条件允许时上证书认证。

五、写在最后：它不显眼，但它是骨架

回到那个凌晨。隧道恢复后，老周在电话里说了句：“这玩意儿平时没人提，断了才知道要命。”站点到站点VPN就是这样一种基础设施：它不像某个业务系统那样天天被用户看见，但它是跨地域办公、混合云互联、分支组网的骨架。理解它的封装与协商机制，理解它的拓扑与路由逻辑，理解它的故障模式，比记住某个厂商的配置命令更有价值。毕竟，命令会过时，而那条“看不见的网线”背后的原理，短期内不会变。