对于有多个异地办公点的企业来说，站点到站点VPN是打通不同站点内网资源的核心方案，很多运维人员刚接触这类组网时，往往只照着教程完成配置，却对站点到站点VPN的工作过程一知半解，遇到隧道断开、业务不通的故障时只能盲目重启设备，很难快速定位根因。本文会从配置前提、运行逻辑、检查方法到常见误区做完整拆解，帮使用者理清全流程的技术细节，减少不必要的排障时间。
站点到站点VPN的配置前置要求
要正常跑通站点到站点VPN，首先两端的出口网关设备都需要支持IPsec等标准站点互联协议，普通家用路由器大多不支持完整的隧道协商规则，很难承载稳定的站点互联需求。同时两端的公网地址需要保证基础可达，中间运营商网络不能完全拦截VPN协商用到的相关端口，否则初始协商报文根本无法送达对端。
还有一个非常容易被忽略的前置条件，就是两端的内网网段不能出现重叠冲突，比如总部内网使用192.168.1.0/24网段，分支站点的内网就不能配置完全相同的网段，否则加密流量转发到对端网关之后，路由规则无法判断该把数据包送到哪个内网接口，直接就会出现丢包问题。
站点到站点VPN的完整协商工作过程
站点到站点VPN的工作过程第一步，是由任意一端的VPN网关作为发起方，先校验对端公网地址的基础连通性，确认没有网络阻断之后，主动向对端的协商端口发送第一阶段协商报文。两端会比对提前配置好的预共享密钥或者数字证书完成身份校验，同时协商出第一阶段的加密算法、哈希算法、密钥存活时间等公共参数。
第一阶段协商成功之后，两端会生成一个临时的安全加密通道，后续所有第二阶段的协商报文都会通过这个通道加密传输，避免协商过程中的配置信息在公网上裸奔，被中间网络设备篡改或者窃取。
接下来进入第二阶段的协商流程，两端会把各自需要加密保护的内网网段规则发送给对方，匹配出需要走VPN隧道传输的流量条目，再协商出第二阶段的加密策略，生成专门用于加密业务流量的独立密钥，这个阶段全部完成之后，两端的站点到站点VPN隧道就正式建立完成。
后续两端内网的终端设备互相发起访问时，流量会先送到本地的VPN网关，网关匹配到属于受保护范围的内网流量条目之后，会给原始的内网数据包加上加密外层头，通过公网的隧道传输到对端网关，对端网关解密掉外层封装之后，再把还原后的原始内网数据包转发到对应的目标内网主机。
隧道运行状态的常规检查步骤
日常运维排查站点到站点VPN故障时，不要一发现业务不通就直接删除原有配置重新搭建，首先要登录两端的VPN网关设备，查看第一阶段的安全联盟状态，如果第一阶段都没有正常生成，说明身份校验或者基础网络连通性出了问题，协商流程根本没有走到业务配置匹配的步骤。
如果第一阶段状态显示正常，但第二阶段的安全联盟条目不存在，那就要检查两端配置的受保护内网网段的匹配规则是不是对称，有没有一端漏写了某个需要互联的内网网段，或者两端配置的加密算法组合不一致，导致协商流程无法达成共识。
如果两个阶段的安全联盟都显示状态正常，但内网业务还是无法互相访问，那就要检查两端网关的路由配置，有没有把对端内网网段的转发下一跳指向VPN隧道接口，很多新手完成VPN协商配置之后忘了添加回程路由，流量发出去之后回程的路径不对，自然无法完成正常的数据交互。
站点到站点VPN的常见认知误区
很多刚接触这类组网的运维以为站点到站点VPN配置完成之后，所有设备的上网流量都会自动走隧道传输，实际上只有提前配置好的受保护网段的流量才会被加密封装进入隧道，其他普通的公网访问流量还是会直接走本地的宽带出口，不会占用隧道的传输资源。
还有不少用户觉得站点到站点VPN的隧道建立之后就会永久在线，实际上所有的安全联盟都有默认的存活超时时间，到了约定时间两端会自动重新协商生成新的密钥，这个过程是后台自动完成的，不需要人工干预，偶尔出现协商超时隧道断开的情况，只要有新的内网流量发起访问，网关会自动重新发起协商建立连接。
