很多企业在搭建跨地域办公专线的时候，都会优先选择IPsec VPN作为站点间加密传输的方案，但不少运维人员刚接触的时候，经常卡在连接协商失败的环节，搞不清到底是哪一步出了问题。本文就把IPsec VPN：连接建立过程的核心步骤拆解清楚，从前期配置校验到最终隧道保活的全链路逻辑讲透，帮大家避开常见的配置误区，快速定位协商故障。
IPsec VPN连接建立前的前置校验要求
IPsec VPN的协商不是两端设备随便填参数就能触发的，第一步必须完成基础网络连通性的前置校验。很多新手上来就直接配置加密策略，忽略了两端公网接口的可达性检查，最后排查半天发现中间运营商封了相关服务端口，完全做了无用功。
前置校验阶段需要确认两端的公网IP没有被运营商侧强行NAT映射，或者如果存在内网出口NAT场景，要提前在两端配置NAT-T的兼容开关，同时确认两端的内网私网网段没有出现重叠，不然就算隧道成功建立，后续路由转发也会出现冲突。
IKE第一阶段主模式/野蛮模式协商核心逻辑
这是IPsec VPN：连接建立过程里的第一个正式协商环节，主要作用是在两端设备之间生成一条安全的控制通道，用来后续加密传输密钥协商的相关报文。主模式下两端会先交互多轮报文，依次完成身份校验、加密算法套件匹配、DH密钥交换的操作，整个过程的身份信息都是加密传输的，安全性更高。
不少运维人员图省事直接选野蛮模式，野蛮模式可以用更少的报文完成第一阶段协商，但身份ID是明文传输的，这种模式只适合其中一端公网IP不固定的场景，固定站点的站点到站点VPN不建议随便启用野蛮模式，避免引入不必要的安全风险。
这个阶段最常见的故障点就是两端的IKE策略参数不匹配，比如一端选了AES加密另一端选了老旧的加密套件，或者预共享密钥输入的时候多打了看不见的空格，这些问题都会直接导致第一阶段协商失败，设备日志里一般会直接提示策略不匹配，顺着提示排查就能快速定位。
IKE第二阶段IPsec安全联盟协商流程
第一阶段协商完成之后，就会进入IPsec VPN：连接建立过程的第二阶段，这个阶段的核心目的是生成用于加密用户业务数据的IPsec安全联盟，也就是通常说的SA。两端会基于第一阶段生成的加密通道，交互各自感兴趣流的匹配规则，也就是哪些内网网段的流量需要走IPsec隧道加密传输。
很多人在配置感兴趣流的时候容易踩坑，一端写的是本端私网到对端私网的反向规则，另一端只写了单向规则，这样就会导致两端感兴趣流镜像不匹配，第二阶段协商直接卡住。还有部分场景下管理员配置了过于宽泛的感兴趣流，把本端访问公网的流量也放进了加密域，最后导致正常上网的流量被错误转发到隧道对端，引发大面积网络故障。
这个阶段协商成功之后，两端设备会各自生成出入方向的IPsec SA，每个SA都有对应的生命周期，到达生命周期阈值之后两端会自动重新协商新的SA，不需要断开现有连接，避免业务传输中断。
隧道连通性验证与常见故障定位思路
完成两个阶段的协商之后，IPsec VPN的隧道其实已经正式建立完成了，但这时候还需要做最后的连通性校验，从本端的内网主机发起访问对端内网主机的测试，确认加密流量可以正常转发。不少人会直接用公网接口去ping对端公网接口验证，这种测试方法是错误的，因为这类流量不会被引入IPsec加密策略，就算通了也不能证明隧道的业务转发是正常的。
如果测试的时候发现协商成功但业务流量不通，首先要检查两端设备的安全域放通规则，确认跨安全域的隧道流量没有被默认拦截，其次要检查路由配置，确认去往对端私网网段的下一跳是指向IPsec隧道接口，而不是默认路由转发到公网。
日常运维的时候不要随意修改两端的IKE和IPsec策略参数，任何参数调整都要保证两端配置完全同步，调整之后可以主动触发一次协商，确认隧道可以正常重新建立，避免后续隧道老化之后无法自动重连，影响跨站点的业务访问。
