当前大量跨区域办公的企业都会部署站点到站点VPN打通不同办公点的内网资源，不少运维人员初次配置时只关注隧道是否连通，绿茶完全没意识到这类VPN会直接改写原有网络的访问路径，并非简单新增一条加密传输通道那么简单。本文从实际部署的全流程拆解站点到站点VPN对访问路径的真实影响，帮技术人员避开常见的配置陷阱。
站点到站点VPN改写访问路径的核心原理
站点到站点VPN的路径调整本质是路由优先级的博弈，并非所有流量都会自动走加密隧道，只有两端网关配置的感兴趣流对应的网段，才会被路由条目指向加密隧道接口。
很多新手误以为只要两个站点的VPN隧道状态显示连通，两个站点所有内网设备的流量都会默认走隧道，实际上如果原有内网的静态路由、动态路由协议优先级高于VPN生成的隧道路由，跨站点访问路径还是会走原来的公网直连或者其他专线链路，根本不会触发加密封装。
直观呈现跨站点网络中VPN隧道路由与原有公网路由的路径差异，体现路由优先级博弈对访问路径的实际影响。
站点到站点VPN部署前的路径配置前提
配置站点到站点VPN之前，必须先梳理清楚两端站点的原有访问路径拓扑，包括现有内网路由条目、公网出口的NAT规则、跨网段访问的下一跳指向，不能上来就直接配置隧道加密参数。
尤其要注意两端站点的内网网段不能重叠，一旦出现网段冲突，VPN设备生成的隧道路由会和原有内网路由冲突，直接导致部分网段的访问路径出现环路，甚至整个站点的内网访问都出现异常。
还要提前确认两端VPN网关的路由优先级设置，多数通用网络设备的VPN隧道路由默认优先级会高于普通静态路由，如果原有业务依赖专线走跨站点访问，VPN下载配置前必须调整路由优先级，避免业务流量被强行切到VPN隧道上。
访问路径异常的常规检查步骤
配置完站点到站点VPN之后，不能只看隧道状态显示UP就判定路径正常，要分别从两个站点的内网终端发起跨站点的业务访问，同时在VPN网关的路由表中查看对应目标网段的下一跳是否指向隧道接口。
如果发现部分流量没有走预期的VPN隧道，可以在终端上执行路由跟踪操作，逐跳查看流量的转发节点，判断是中间某台三层设备的路由配置错误，还是VPN感兴趣流的匹配范围设置不全。
还要排查NAT规则的优先级，很多运维会把内网访问公网的NAT规则设置为全局匹配，没有把跨站点VPN的感兴趣流网段加入NAT排除列表，导致跨站点的流量先被做了公网地址转换，绿茶根本无法匹配VPN的加密规则，访问路径直接走了公网出口。
常见的路径配置误区
很多人为了图省事，把站点到站点VPN的感兴趣流设置成所有网段，也就是本地0.0.0.0/0对应对端0.0.0.0/0，这种配置会导致本地所有流量包括访问公网的流量都被强行导入VPN隧道，不仅跨站点的业务访问路径变得混乱，还可能出现本地终端访问本地公网服务的流量被绕到对端站点再返回，出现不必要的转发迂回。
还有不少运维忽略了多出口场景下的路径冗余问题，站点同时配置了站点到站点VPN和传统专线作为跨站点备份，没有配置动态路由的自动切换规则，一旦VPN隧道中断，原有访问路径不会自动切回专线，直接导致跨站点业务全部中断。
还要注意站点到站点VPN的隐私边界问题，VPN下载走隧道的流量只会在两个VPN网关之间做加密传输，终端到本地VPN网关的这段路径还是普通内网明文传输，不要误以为配置了站点到站点VPN之后全链路流量都处于加密保护状态。
实际部署站点到站点VPN的过程中，所有路径调整都要和企业自身的业务访问需求匹配，没有通用的最优配置方案，每次调整隧道路由之后都要做全业务的路径验证，才能避免非预期的流量转发影响正常业务运行。
