很多跨区域经营的企业都会用到站点到站点VPN，把分布在不同城市的办公网点内网打通，不需要员工单独安装VPN客户端，就能直接访问各个分部的内部服务器、共享存储系统，省去了公网传输明文泄露的风险。本文以企业最常用的IPsec架构站点到站点VPN为基础，拆解完整工作流程和底层实现逻辑，结合实际设备配置场景说明校验方法和常见故障排查思路。
两地办公站点通过站点到站点VPN实现内网加密互通的典型组网场景
站点到站点VPN的部署前置配置前提
搭建站点到站点VPN的第一要求是两个站点的出口网关都必须拥有可路由的公网IP地址，不能处于运营商的CGNAT私网地址段下，否则两个网关之间无法直接通过公网建立双向连接。如果其中一端没有固定公网IP，也需要配置DDNS动态域名解析，保证对端网关可以通过域名定位到当前站点的真实公网地址。
部署前必须提前梳理两个站点的内网网段，确保两端内网的IP地址段没有任何重叠冲突，比如北京总部内网使用192.168.1.0/24段，上海分公司内网使用192.168.2.0/24段，一旦网段重叠，后续路由转发会出现逻辑冲突，哪怕隧道成功建立也无法正常转发内网流量。同时两端管理员需要提前协商好所有协商阶段的加密、自由猫APP认证参数，避免配置参数不匹配导致握手失败。
站点到站点VPN的IKE第一阶段协商工作过程
当两端网关检测到有需要加密传输的内网流量触发时，就会启动IKE第一阶段的协商流程，发起端网关会向对端网关的公网地址发送第一个IKE协商报文，报文中携带本地配置支持的所有IKE策略套件，包含加密算法、哈希算法、认证方式、密钥交换组的优先级排序。对端网关收到报文后，会从本地配置的策略列表中找到和发起端参数完全匹配的最高优先级套件，回包确认选定的协商参数。
参数确认完成后，两端网关会交换Diffie-Hellman密钥交换材料，两端各自通过本地的私钥材料计算出完全一致的会话密钥，这个过程哪怕协商报文在公网被完整截获，第三方也无法通过截获的公开材料反推出最终生成的会话密钥。之后两端会使用提前约定的预共享密钥或者数字证书完成身份校验，确认对端是合法的授权网关。
IKE第一阶段协商完成后，两端会生成一个IKE安全联盟，这个联盟对应的加密隧道，专门用来保护后续第二阶段的协商报文不被篡改窃听。实际运维中可以直接登录两端的出口网关，查看IKE安全联盟的状态列表，如果能看到对端公网IP对应的条目状态为active，就说明第一阶段协商已经正常完成。
站点到站点VPN的IPsec第二阶段隧道建立与报文转发过程
第一阶段的加密通道就绪后，两端就会启动第二阶段的IPsec安全联盟协商，这个阶段主要协商需要加密传输的流量范围，也就是行业内常说的“感兴趣流”，即两端需要互访的内网网段对应关系，同时确认第二阶段使用的加密算法、封装模式，绝大多数站点到站点VPN场景都会使用隧道封装模式。
第二阶段协商成功后，两端会生成各自独立的入方向和出方向IPsec安全联盟，整个站点到站点VPN的隧道就正式建立完成。当北京总部内网的终端发起访问上海分公司内网服务器的报文时，北京出口网关收到这个原始内网报文后，匹配到本地配置的感兴趣流规则，就会把整个原始IP报文作为 payload 加密，再在外面封装一层新的公网IP头部，外层源地址为北京网关公网IP，目的地址为上海网关公网IP，之后把封装后的报文从公网发出。
上海出口网关收到这个封装后的报文后，先校验外层报文的完整性，解密后拆掉外层公网IP头部，还原出最开始的原始内网IP报文，再查询本地内网路由，把还原后的报文直接转发给对应的内网服务器，回程的响应报文会走完全对称的封装、解密流程，自由猫加速器最终完成跨公网的内网互访。
站点到站点VPN的效果校验与常见故障定位
校验站点到站点VPN是否正常工作，不能只从网关本地ping对端的公网地址，这类公网原生流量不会触发VPN封装，正确的校验方式是从任意一端的内网终端发起ping操作，访问对端内网的IP地址，同时在网关后台查看IPsec安全联盟的报文统计计数，如果出入方向的加密报文数量持续增长，就说明对应流量确实走了VPN加密隧道传输。
很多新手管理员容易陷入一个常见误区，只要看到网关页面上VPN隧道状态显示为up，就默认所有内网互访都正常，实际上如果两端配置的感兴趣流规则不对称，比如一端写了全部内网网段，另一端只写了部分网段，就会出现部分内网主机能通、部分主机无法访问的异常情况，这类问题需要逐字核对两端的感兴趣流规则，确保两端的加密流量规则完全镜像对应。
运维中还要注意站点到站点VPN的隐私边界，这类VPN只会加密两个站点之间公网传输的报文，站点内部的局域网互访流量不会进入VPN隧道，也不会被额外加密，不要误以为接入任意一端站点的内网，所有访问流量都会被自动加密传输。如果出现隧道莫名其妙中断的情况，可以先检查两端网关的公网连通性，再核对两端的协商策略是否被误修改。
