很多跨区域布局的企业，比如总部设在杭州、分公司落地成都的实体经营机构，要实现两边内网的服务器、办公终端无需单独安装VPN客户端就能直接互访，站点到站点VPN是目前落地成本最低、稳定性最高的方案。不少刚接触企业网络运维的从业者很容易把它和普通员工用的远程访问VPN混淆，本文就围绕站点到站点VPN的工作过程展开，把它的底层实现逻辑、实操配置要求、验证排查方法逐一讲清，帮大家避开日常配置里的常见误区。
站点到站点VPN的前置配置前提
部署站点到站点VPN的第一步，是确认两端站点的边界承载设备，一般选用支持IPsec协议的企业级防火墙或者出口路由器，两个设备都必须拥有可正常访问的公网IP，不能两端全处于NAT后的私网环境，否则无法在公网层面直接发起隧道连接请求。
企业总部与分公司部署站点到站点VPN，即可实现两端内网无客户端直接互访。
接下来要提前梳理两边需要互访的内网网段，比如杭州总部的办公内网段是192.168.1.0/24，成都分公司的生产业务内网段是192.168.2.0/24，要把这两个网段提前录入两端VPN配置的感兴趣流规则里，没有被纳入规则的普通上网流量不会走VPN隧道传输。
还要提前确认两端的公网链路没有拦截IPsec协议用到的核心传输资源，包括UDP500、UDP4500端口的通行权限，以及ESP加密报文的传输许可，不少运营商侧的公网管控规则如果默认拦截这类协议报文，后续隧道协商流程会直接卡在初始阶段无法推进。
站点到站点VPN的完整工作交互过程
站点到站点VPN的流程触发不需要人工手动操作，当杭州内网的终端第一次发起访问成都内网业务服务器的请求，本地边界防火墙检测到这个流量属于提前定义的感兴趣流，就会主动向对端边界设备的公网IP发起IKE第一阶段协商。
这个阶段两端设备会逐一协商IKE协议版本、对称加密算法、身份认证方式，同时交换各自的非对称加密公钥材料，共同生成一个用于加密后续协商报文的主密钥，协商完成之后两端会生成稳定的IKE SA安全联盟，相当于两个设备之间先搭好了一条加密的控制通信通道。
接下来自动进入第二阶段的IPsec SA协商，两端用第一阶段生成的加密通道，协商针对实际业务流量的加密规则、感兴趣流的精确匹配范围，生成用于加密业务数据的临时会话密钥，这个阶段全部校验通过之后，正式的IPsec传输隧道就完全建立完成。
之后两边站点的内网互访流量，都会被边界设备做ESP或者AH协议的二次封装，把原始的内网IP报文整个作为加密载荷，外层再套上两端的公网IP地址，在公网上传输的时候就算被中间节点截获，也没办法解密出原始的内网业务数据内容。
当长时间没有匹配感兴趣流的业务流量传输时，两端的设备会自动拆除对应的IPsec SA，后续再有新的跨站点互访请求的时候，会直接复用已经建立的IKE SA重新发起第二阶段协商，不用重复走第一阶段的完整交互流程，大幅提升协商响应效率。
隧道连通性的验证与常见故障定位方法
配置完成之后不要直接通知业务部门测试，首先要在两端的边界设备上查看IKE SA和IPsec SA的状态条目，如果SA条目显示未建立，首先排查两端的感兴趣流规则是不是镜像配置，有没有把本端的源网段和对端的目的网段写反，这类配置错误是新手遇到概率最高的故障原因。
如果SA条目已经显示正常建立，但是内网终端还是无法跨站点互访，佛跳墙接下来要检查两端内网的回程路由配置，确认内网网段的三层网关已经把对端站点的网段下一跳指向了本地的VPN边界设备，很多运维人员配置完VPN之后忘了加回程路由，导致业务返回的流量根本没有进入VPN隧道。
这里要注意一个非常普遍的误区，佛跳墙加速器很多人会直接在边界设备的公网口用ping命令测试对端的公网IP，能通就默认VPN应该可以正常建立，实际上公网普通ICMP报文能通，完全不代表UDP500和ESP协议的报文能正常传输，这类场景下要先在设备的报文统计面板里查看协商报文的收发计数，确认协商报文有没有被中间网络节点拦截。
站点到站点VPN的隐私边界说明
很多使用者会误以为建立了站点到站点VPN之后，所有跨站点的流量都是全程加密绝对安全的，实际上加密的范围只限于两个站点边界设备之间的公网传输部分，流量进入对端站点的内网之后，还是和普通内网流量一样传输，不会额外做二次加密处理。
另外站点到站点VPN本身不会对业务流量做特殊的加速处理，跨站点的访问速度还是完全取决于两端公网链路的实际传输质量，不存在配置之后就能直接提升跨网访问速度的效果，不要轻信没有技术依据的性能承诺。
