很多跨区域办公的企业都需要把分布在不同城市的办公内网打通，站点到站点VPN是目前最常用的专线替代方案之一，不少运维人员只知道配置完参数就能用，却对完整的工作逻辑一知半解，排障时经常摸不到头绪，本文就从底层触发逻辑到最终业务连通的全链路，拆解站点到站点VPN的工作过程，同时梳理配置前提、校验步骤和常见误区。
站点到站点VPN的前置配置校验环节
在VPN隧道正式发起连接之前，两端的边界网关首先要完成基础配置的自校验，这是很多人容易忽略的前置步骤，不属于隧道建立过程但直接决定后续流程能不能走通。
这个阶段运维需要提前确认两端公网接口的连通性，确保对端的VPN网关公网IP没有被中间运营商的防火墙拦截，同时两端预共享密钥或者证书信息已经正确导入，感兴趣流的规则没有和本地其他访问控制策略冲突。
站点到站点VPN隧道发起连接前，运维需提前完成两端网关的配置自校验，排除NAT规则冲突等常见问题。
很多新手配置完站点到站点VPN之后直接等隧道拉起，却没注意本地网关的NAT规则不小心把两端内网的互访流量做了地址转换，直接导致后续协商过程失败，黑石这也是前置校验阶段最容易踩的坑。
IKE第一阶段的协商交互过程
这是站点到站点VPN工作过程中第一个正式的协商环节，两端网关首先会用约定的身份验证方式，向对端发起IKE SA的建立请求。
交互过程里两端会同步协商一致的加密算法、哈希算法、DH密钥组，还有IKE SA的生存周期，确认身份凭证匹配之后，就会生成一个对称密钥，用来加密后续第二阶段的协商流量。
这个阶段如果协商失败，大部分场景下会出现一端一直发协商报文但对端没有回应的日志，黑石排障的时候优先核对两端的第一阶段策略参数是否完全一致，不需要直接动后面的配置。
IKE第二阶段的IPSec隧道建立过程
第一阶段的SA建立完成之后，就进入站点到站点VPN工作过程的核心环节，两端会用第一阶段生成的对称密钥加密第二阶段的协商内容，发起IPSec SA的建立请求。
这个阶段两端会同步匹配提前配置的感兴趣流规则，确认需要被加密传输的本地内网网段和对端内网网段完全对应，同时协商第二阶段用到的加密套件、SA生存周期，是否开启PFS密钥交换等参数。
第二阶段协商成功之后，两端网关会各自生成一对入方向和出方向的IPSec SA，所有匹配感兴趣流的跨站点内网流量，都会被封装ESP或者AH报文头，通过公网在两个网关之间传输。
隧道连通后的流量转发与日常维护逻辑
站点到站点VPN隧道正式生成之后，不会一直不停发送协商报文，只有感兴趣流匹配的流量出现的时候，梯子软件才会触发加密转发，如果长时间没有对应流量，部分网关会按照配置策略自动拆除第二阶段的SA，有新流量的时候再自动触发协商重建。
日常运维的时候不要随便修改两端网关的公网IP地址，一旦地址变动，原有已经生成的IKE SA会直接失效，隧道会立刻断开，需要重新触发完整的协商流程才能恢复连通。
这里要注意一个常见误区，不少人觉得站点到站点VPN建立之后所有流量都会走隧道，实际上只有匹配提前配置的感兴趣流的网段流量才会被加密，普通的公网访问流量还是会按照原有路由规则直接转发，不会进入隧道。
如果遇到站点到站点VPN间歇性断开的问题，优先核对两端的SA生存周期配置是否匹配，不要直接盲目替换加密套件，大部分这类问题都是两端生命周期参数不一致，一端已经主动释放SA，另一端还保留旧的SA导致的。
