很多企业IT运维人员首次部署跨站点加密组网方案时，很容易把站点到站点VPN和日常用的远程访问VPN的经验混同，网上流传的不少零散操作经验其实是广为流传的常见误解，照着配置反而容易出现隧道协商失败、业务异常裸奔、转发卡顿等问题，今天就结合企业常用的边界防火墙、出口路由器的实际配置场景，盘点几个站点到站点VPN的典型常见误解，帮一线运维避开不必要的踩坑环节。
一线运维人员调试出口网络设备，排查站点到站点VPN配置故障
误解一：站点到站点VPN只要两端公网IP能通就能直接建连
很多新手运维第一次配置站点到站点VPN的时候，以为只要两个站点的出口设备都能ping通对方的公网地址，就能直接拉起IPsec隧道，实际操作的时候反复调整参数，隧道始终卡在第一阶段协商失败，找不到问题根源。
实际上站点到站点VPN的协商报文默认依赖UDP 500、UDP 4500两个端口，还有ESP对应的50号网络层协议，单纯公网IP能通只代表ICMP报文被链路放行，很多运营商中间节点或者两端的前置安全网关如果没放开这几个端口和协议的通行权限，哪怕两端能正常互ping，也完全没法完成隧道协商流程。
验证这个问题的方法也很简单，在两端出口设备的外网接口开启端口镜像抓包，查看发出去的500端口协商报文有没有收到对端的响应，如果只有向外发送的协商包没有任何回包，优先排查中间链路的访问控制策略，不要反复修改预共享密钥浪费排查时间。
误解二：站点到站点VPN配置完成后所有跨站流量都会自动走隧道
不少非专职的企业IT管理员以为配完隧道接口、安易加速器官网填完对端参数之后，两个站点的所有内网网段流量就会自动走加密隧道，结果配置完成之后发现两个站点的内网服务器完全没法互访，甚至部分跨站业务流量直接走公网裸奔，完全没有加密防护。
实际上站点到站点VPN的加密域是需要两端手动指定感兴趣流的，也就是要明确声明哪些源网段、目的网段的流量需要被IPsec加密封装，只有完全匹配上感兴趣流规则的流量才会触发隧道建立，不匹配规则的流量还是会按照设备原有路由规则直接转发。
很多新手踩坑的高频场景就是两端的感兴趣流配置不对称，一端写了A站点所有内网到B站点所有内网的全量规则，另一端只写了部分业务网段的规则，就会出现部分业务能通、部分业务完全不通的诡异情况，排查的时候可以直接在设备的IPsec统计页面查看感兴趣流的匹配计数，就能快速定位是不是流量没被纳入加密规则。
误解三：站点到站点VPN的加密强度越高隧道性能越好
很多运维在配置的时候为了提升所谓的安全性，把加密算法、哈希算法都选了设备选项里的最高等级选项，结果隧道建立之后跨站访问业务卡顿明显，反而觉得是站点到站点VPN本身的稳定性不足。
实际上站点到站点VPN的加密、哈希运算都需要出口设备的算力支撑，超出设备硬件加密卡支持范围的高强度算法，会把所有加密运算转移到设备通用CPU处理，直接拖慢整个出口设备的转发性能，反而会导致隧道丢包、延迟异常升高。
验证这个问题可以在隧道建立后查看出口设备的实时CPU使用率，如果CPU占比明显异常升高，同时没有大量业务流量的情况下就出现高负载，大概率是选了设备硬件不支持的加密算法，换成设备官方适配的标准算法就能快速恢复正常转发状态。
误解四：站点到站点VPN完全可以替代专线承载所有核心业务
不少中小企业为了控制组网成本，直接把所有核心生产业务全部迁移到站点到站点VPN隧道上，没有做任何冗余备份机制，安易加速器官网一旦公网链路出现波动就直接导致跨站业务长时间中断。
站点到站点VPN本质上是依托公网链路搭建的加密隧道，安易本身的传输质量完全依赖两端的公网接入质量，没有物理专线对应的SLA服务保障，也没法完全规避公网链路的抖动、临时丢包问题，更适合对传输时延抖动容忍度较高的非实时业务。
企业如果要把核心业务放到站点到站点VPN上，至少要配置两条不同运营商的独立公网出口，同时开启双隧道冗余切换机制，才能尽可能降低业务中断的风险，不要默认认为站点到站点VPN的稳定性可以和物理专线持平。
总的来说，站点到站点VPN的配置和运维没有很多网传零散经验说的那么简单，避开这些广为流传的常见误解，结合实际设备的运行状态逐一排查，就能大幅降低隧道的连通故障概率，让跨站组网的运行状态符合预期。
