不少企业组网的运维人员刚接触站点到站点VPN的时候，飞鸟加速器很容易把它和日常用的远程访问VPN的特性混淆，在配置、排障、业务适配环节踩很多没必要的坑，我们结合实际防火墙配置场景，梳理几个行业内高频出现的站点到站点VPN常见误解，帮大家减少无效调试的时间。
误解一：站点到站点VPN协商成功就等于两端所有内网网段自动互通
很多新手运维在完成两端IPsec隧道的基础配置，看到设备页面显示隧道状态为UP之后，就直接认为两边内网的所有终端可以互访，实际在主流的边界防火墙设备上，站点到站点VPN的隧道只是打通了公网侧的加密传输通道，内网到隧道、隧道到内网的跨区域访问策略默认还是拦截状态，没有单独放通的话，业务流量根本进不了隧道。
验证互通性的时候不能只看隧道的协商指示灯，要分别在两端内网的普通办公终端上，traceroute对端内网的业务服务器IP，要是路径里直接跳转到本地的公网网关，说明感兴趣流的源目网段配置写反，流量根本没有被引入加密隧道，这是最常见的配置疏漏。
运维人员需通过实际路由追踪验证站点到站点VPN的连通性，不能仅以隧道UP状态判定全内网互通
误解二：加密规则配置得越复杂，站点到站点VPN的安全性就越高
不少刚接触IPsec VPN的运维，会特意选择设备支持的最高等级加密套件，甚至叠加多层嵌套的加密校验规则，结果反而导致两端隧道频繁断连、协商失败，飞鸟VPN官网尤其是不同厂商的边界设备对接的时候，部分老旧型号的硬件加密单元不支持过于小众的加密组合，协商阶段的报文反复重传，隧道的连通稳定性反而大幅下降。
合理的配置逻辑是先核对两端设备支持的加密套件交集，选择交集中优先级最高的通用组合即可，配置完成后在设备后台查看IPsec安全联盟的报文计数，计数持续平稳增长、没有反复重置的记录，就说明加密配置处于合理状态，不需要盲目叠加多余的加密规则。
误解三：站点到站点VPN天然支持跨站点动态路由自动同步
很多人以为隧道建立完成后，两端的OSPF、BGP这类动态路由协议的报文会自动通过隧道传输，内网路由会自动同步到对端，实际上默认的策略模式站点到站点VPN，只会转发你提前在感兴趣流里定义的网段流量，动态路由的协议报文本身根本不在匹配规则里，自然无法通过隧道传输。
验证路由同步效果的时候，可以分别在两端的边界设备上查看核心路由表，确认对端内网网段的路由下一跳是否指向本地的隧道接口，要是下一跳还是本地公网网关，说明路由发布规则没有关联到VPN隧道域，需要调整路由引入的配置，不要直接判定站点到站点VPN不支持动态路由对接。
误解四：站点到站点VPN的业务不通故障，只需要排查隧道协商日志就能定位
不少运维遇到业务访问失败的情况，翻遍了两端设备的VPN协商日志，确认隧道状态完全正常之后，就完全找不到故障根源，实际上站点到站点VPN的故障点很多不在VPN协商流程本身，比如中间公网运营商拦截了ESP协议报文、链路中间的NAT设备改动了报文的源端口，都会导致隧道显示协商成功，实际业务加密报文无法正常传输。
遇到这类隐性故障的时候，飞鸟VPN官网可以先在两端设备的公网物理接口上开启端口镜像抓包，过滤ESP协议的报文，确认本地发出的加密报文有没有收到对端的回应，如果报文有去无回，就可以顺着中间链路的协议放行规则逐步排查，不要把所有排障精力都放在两端设备的VPN配置上。
最后还要厘清一个常见的认知偏差，不少人认为站点到站点VPN可以完全替代运营商专线承载所有核心业务，实际上它的传输质量完全依赖两端之间的公网链路状态，没有服务等级协议保障的场景下，一定要搭配专线做冗余备份，不要把所有高优先级的生产业务都挂载在单条站点到站点VPN链路上。
