很多企业的网络管理员在首次部署跨地域站点互联方案时，很容易对站点到站点VPN产生各种想当然的判断，最终导致配置反复出错、运维成本飙升，甚至留下内网安全隐患。本文结合实际网关配置、火烧云故障排查的常见场景，梳理站点到站点VPN：常见误解对应的真实技术逻辑，帮大家避开实际运维里的各类不必要的坑。
误区一：站点到站点VPN等同于普通远程VPN的多站点叠加
不少刚接触跨站点组网的运维人员，第一次搭建站点到站点VPN环境时，会想当然地在总部VPN网关里开大量用户接入权限，让分支办公室的所有终端都用独立账号拨号连总部，火烧云以为这样就能模拟出站点级互通的效果。
实际上站点到站点VPN的核心运行逻辑，是两个站点的出口网关设备直接建立加密隧道，两端的内网网段是预先在网关后台做路由映射的，不需要分支侧的每台终端单独发起连接。如果用多用户SSL VPN堆叠的方式模拟站点互通，一旦分支终端数量超过网关的预设并发阈值，很容易出现随机断连的情况，完全达不到站点级互联的稳定性要求。
正确的站点到站点VPN由两端网关直接建立加密隧道，无需分支终端单独拨号
验证当前配置是否为标准站点到站点VPN连接，你可以分别在总部网关和分支网关的隧道监控页面查看对端的接入类型，如果显示的是对端网关公网IP对接而非大量零散的终端IP，就说明配置逻辑是符合要求的。
误区二：只要两端公网能通就能成功建立站点到站点VPN隧道
很多管理员配置完两端的加密策略、预共享密钥之后，发现隧道一直协商失败，火烧云VPN反复核对好几次密钥参数都没问题，就下意识判定是硬件设备出了故障，其实大多是忽略了两端网关的NAT穿越配置限制。
不少运营商给中小分支分配的公网IP其实是在运营商侧的NAT网关后面的，也就是常说的内网形式公网地址，这种情况下如果两端都没有配置对应的NAT穿透策略，或者其中一端的网关没有固定公网IP，隧道协商的IKE第一阶段报文根本就没法被对端正常接收。
排查这个问题的时候你可以先在两端网关的系统日志里过滤IKE协商报文的记录，如果一直显示对端响应超时，先分别在两个网关的命令行下向对端的公网地址发起ping测试，确认公网三层连通之后，再检查两端的安全策略有没有放通IKE协议对应的端口权限。
误区三：站点到站点VPN打通之后所有流量都会自动走加密隧道
很多企业部署站点到站点VPN的初衷是让分支访问总部的OA、财务系统走加密链路，结果配置完之后发现分支访问公网的网页、下载文件的速度明显变慢，就直接判定是隧道加密带来的性能损耗，实际上大概率是错误地把所有内网网段的路由都指向了VPN隧道接口。
站点到站点VPN的路由转发规则是管理员手动定义的，只有你明确把需要访问的对端内网网段加到感兴趣流的匹配规则里，对应的流量才会被封装进加密隧道，其余普通上网的流量默认还是走分支本地的公网网关。
你可以在网关的流量统计页面查看隧道内的转发流量明细，如果发现大量非业务的公网访问流量也出现在隧道统计里，就说明感兴趣流的规则配置范围写得太宽了，需要重新调整匹配的网段段，把公网网段排除在外。
误区四：站点到站点VPN的加密传输等于全链路绝对安全
不少管理员觉得两个站点之间的流量已经走了IPsec加密隧道，就不需要再在两端的内网侧配置访问控制策略，甚至直接把总部的核心服务器网段完全开放给分支所有终端，很容易出现分支终端中毒之后直接通过隧道扩散到总部内网的情况。
站点到站点VPN的加密保护的只是两个网关之间的公网传输段，避免报文在公网传输过程中被窃听篡改，但是两端内网内部的流量本身是没有经过隧道加密的，也不会自动做入侵检测。
日常运维里你可以定期在隧道两端的网关配置流量审计规则，统计跨站点访问的异常连接请求，一旦出现不在业务白名单里的访问行为，及时调整两端的安全策略做拦截。
