很多企业跨地域组网都会用到IPsec VPN，不少运维人员配置时经常遇到隧道起不来、业务不通的问题，大多是对IPsec VPN连接建立的完整过程理解不透彻，没有对应阶段排查问题的思路。本文从实际运维场景出发，拆解IPsec VPN连接建立的全流程原理，梳理配置前置要求、各阶段检查要点和常见误区，帮你快速定位连接异常问题。
IPsec VPN连接建立的前置配置前提
在发起IPsec VPN连接之前，两端的网关首先要保证基础网络连通，也就是公网层面两端的互联地址可以互相访问，没有中间防火墙拦截ESP、AH协议和IKE用到的UDP端口。很多新手配置时会忽略运营商中间链路的限制，直接配置IKE策略，最后隧道一直卡在协商初始化阶段，找不到问题根源。
除了基础网络连通，两端的预共享密钥或者证书体系必须匹配，感兴趣流的规则不能出现两端镜像不对应的情况，也就是本端指定的需要走VPN的私网网段，必须和对端允许接入的私网网段完全对应，不能出现单边写反网段的问题。如果其中一端网关处于NAT网关之后，还需要提前配置NAT穿越的相关开关，保证协商报文可以穿透中间的NAT设备。
运维人员对照IPsec VPN协商阶段逐一排查两端网关配置问题
IKE第一阶段协商的完整过程
IKE第一阶段是IPsec VPN连接建立的第一步，核心作用是在两端之间搭建一条安全的控制通道，用来后续协商IPsec的加密策略。首先发起方会向对端网关发送第一个IKE协商报文，携带本端支持的加密算法、哈希算法、认证方式、DH组标识等参数，请求发起第一阶段协商。
对端收到报文之后，会对比自身配置的IKE策略，找到和发起方参数完全匹配的策略条目，返回确认报文，之后两端通过DH算法交换临时生成的随机密钥材料，共同算出第一阶段的共享会话密钥。这个阶段完成之后，后续的所有协商报文都会被加密传输，避免参数在公网明文泄露。
很多运维人员排查第一阶段故障时，只会检查预共享密钥是否一致，经常忽略两端IKE策略里的生命周期、DH组号不匹配的问题，这类问题不会直接提示密钥错误，只会反复重传协商报文，很难快速定位。遇到这类协商停滞的场景，可以先逐一对齐两端的IKE策略参数，再重新发起连接测试。
IKE第二阶段协商的核心逻辑
第一阶段协商完成之后，就会进入IPsec VPN连接建立的第二阶段，这个阶段的所有报文都已经通过第一阶段的会话密钥加密，核心目的是协商出用于加密用户业务数据的IPsec SA策略。两端会互相发送本地配置的感兴趣流信息，也就是需要走VPN加密的私网网段对，同时携带本端支持的ESP或者AH协议的加密、认证算法。
两端校验感兴趣流镜像匹配、安全协议参数匹配之后，就会生成两个方向独立的IPsec SA，分别用于本端发往对端的加密流量，和对端发往本端的解密流量。第二阶段协商完成之后，两端的IPsec VPN隧道就正式建立完成了，符合感兴趣流规则的私网流量就会被封装加密后通过公网传输。
这里很容易出现的误区是，不少管理员会把两端的感兴趣流配置成包含所有私网大段，没有做最小化限制，一旦某一端私网新增网段没有同步更新对端配置，就会出现部分网段业务能通、部分网段走不通的奇怪现象。日常配置时建议按需最小化指定需要加密的网段，避免不必要的流量被错误引入VPN隧道。
隧道保活与异常断开的处理逻辑
IPsec VPN连接建立完成之后，两端会按照配置的生命周期定期更新SA，不需要每次流量断了就重新走完整协商流程。如果配置了DPD对等体存活检测，两端会在没有流量的间隙发送探测报文，确认对端网关是否在线，避免对端公网地址变动之后，旧的SA一直占用设备资源。
实际运维中经常遇到隧道闲置一段时间之后自动断开的问题，大多是没有配置DPD检测，中间运营商的NAT会话超时之后，两端没有及时感知到链路状态变化，梯子后续有新流量触发时才会重新发起协商，导致业务短暂中断。这类场景可以通过调整DPD探测的间隔参数，及时感知对端状态，提前触发SA更新。
需要注意的是，IPsec VPN只是对指定的私网网段流量做加密传输，不会对所有上网流量做处理，奈云不要混淆IPsec VPN和普通代理类VPN的使用边界，避免配置错误导致正常公网访问被异常拦截。IPsec VPN的核心作用是企业跨站点的私网加密互联，不要用于超出合规范围的使用场景。
