对于拥有多个跨地域办公点的企业来说，站点到站点VPN是替代传统专线的高性价比组网方案，很多刚接触企业组网的运维人员，往往只知道配置完参数就能打通两端内网，却对完整的协商和数据转发流程一知半解，遇到隧道不通的问题很难快速定位根因。本文结合多分支企业的实际组网场景，完整拆解站点到站点VPN的全工作过程，梳理配置前提、验证方法和常见排障思路，帮使用者理清核心运行逻辑。
站点到站点VPN的前置配置前提
最典型的部署场景是北京总部的边界防火墙和上海分公司的边界防火墙作为VPN两端的网关，两端各自的内网私网网段完全不重叠，比如总部内网为192.168.1.0/24，分公司内网为192.168.2.0/24，两个网关都分配有独立的公网固定IP，中间运营商网络没有封禁IPsec协议对应的UDP、ESP报文传输，这是隧道能正常建立的基础条件。
很多新手配置时最容易踩的前置坑，就是没有调整原有边界网关的NAT规则，把两端内网互访的流量也纳入了公网地址池的转换范围，这类流量在匹配VPN感兴趣流之前就被转换成了公网地址，后续自然无法触发VPN协商流程，配置前必须先在两端的NAT策略里，把两个站点私网网段互访的流量排除出公网NAT的转换规则。
多分支企业站点到站点VPN的典型组网部署场景
站点到站点VPN的完整协商工作过程
协商流程的第一步是IKE第一阶段协商，两端网关主动向对端的公网IP发起协商请求，匹配提前配置好的IKE策略里的加密算法、身份认证方式、预共享密钥或者数字证书信息，协商生成一条受保护的IKE安全联盟，这条通道全程加密，专门用来传输后续的协商报文，避免协商过程被中间人篡改。
IKE第一阶段协商完成之后，就进入IKE第二阶段的协商流程，两端基于已经加密的IKE通道，互相交换各自需要保护的感兴趣流网段，也就是提前规划好的两端私网互访网段，同时匹配预配置的IPsec提议里的封装模式、加密套件参数，协商生成两条独立的IPsec安全联盟，分别对应入方向和出方向的加密流量处理。
第二阶段协商完成之后，站点到站点VPN的隧道就正式建立完成，后续两端内网终端发起的互访流量，只要匹配提前配置的感兴趣流规则，就会被出口网关做ESP协议封装，在原始私网报文外层再套上一层公网IP头和加密校验字段，以密文形式在公网传输，到达对端网关之后再执行解封装操作，还原出原始私网报文转发到对应内网终端。
隧道连通性的标准验证步骤
排查连通性问题不要一上来就用内网业务服务器互相ping测试，第一步先登录两端的边界网关设备，查看IKE安全联盟的状态，如果条目里没有显示对端网关的公网IP，说明第一阶段协商就没有成功，大概率是两端预共享密钥不匹配、IKE策略参数不一致，或者中间运营商拦截了协商报文。
确认IKE安全联盟状态正常之后，再查看IPsec安全联盟的条目，如果只有入方向或者只有出方向的SA记录，说明第二阶段协商没有完全完成，这类问题绝大多数原因是两端配置的感兴趣流网段没有做到完全镜像，比如一端配置了总部全量私网网段，另一端漏写了总部下某个业务VLAN的网段。
确认两类安全联盟的条目都完整存在之后，再从内网终端发起跨站点的连通性测试，同时在网关设备上开启IPsec报文的调试日志，能看到封装报文和解封装报文的计数同步增长，就说明跨站点的业务流量已经完全通过VPN隧道加密转发。
运维过程中的常见误区与故障定位思路
很多运维人员误以为站点到站点VPN隧道建立之后就会永久稳定运行，实际上如果两端网关的公网IP发生变动，梯子工具或者中间运营商网络临时中断了协商报文的传输，隧道会自动触发重协商，部分老旧型号的网关设备重协商机制存在缺陷，会出现隧道显示UP但实际流量无法转发的假死状态，这类场景下可以手动重置两端的安全联盟，触发一次完整的重新协商流程即可恢复。
需要注意的是，站点到站点VPN的加密机制只能保证公网传输过程中的数据不会被窃听篡改，它本身不能等同于内网的绝对安全边界，两端站点的内网安全访问策略还是要单独配置，不能因为流量走了加密VPN隧道就完全放开两个站点所有网段的互访权限，梯子避免单个站点被入侵之后直接影响全部分支点的内网业务。
