不少运维人员在配置站点到站点VPN或者远程访问VPN时，经常遇到隧道协商成功但内网业务完全不通的问题，排查大半天加密策略、协商参数都没找到错误，最后才发现是IPv4地址相关的配置环节漏了校验项。本文就把VPN IPv4地址配置全流程的必备检查项目逐一拆解，覆盖从配置前预校验到上线后验证的全环节，帮技术人员快速定位地址类故障。
运维人员在配置VPN前逐一校验两端IPv4地址段的合法性，提前规避网段重叠类隐性故障
配置前的IPv4地址段合法性预检查
很多运维上来就直接敲VPN隧道的协商配置，忘了先核对两端内网的IPv4私网段有没有重叠，比如总部内网用192.168.1.0/24，分支办公网络也配置了完全相同的网段，哪怕后续所有VPN参数都配置正确，隧道内的路由转发也会出现地址冲突，业务流量根本无法正确抵达对端设备。
还要提前检查两端用来建立VPN的公网接口IPv4地址，不能是运营商内网保留地址，要是公网可路由的合法IPv4地址，如果其中一端部署在公网NAT网关后面，要提前做好VPN协商相关端口的映射，把对应端口的流量转发到内网VPN设备的IPv4管理地址上，不然公网侧发起的协商报文根本无法送达内网VPN设备。
配置前还要确认后续要放进VPN加密域的所有IPv4地址段，有没有和VPN设备本身的管理地址、公网接口IPv4地址属于同一网段，VPN加速器不然很容易出现路由优先级冲突，本该从公网接口发出的VPN协商报文被错误导进还没完全建立的隧道里，直接形成转发环路。
VPN加密域IPv4地址条目精准性检查
加密域也就是多数网络厂商文档里提到的感兴趣流，这部分的IPv4地址配置是最容易出现笔误的环节，比如把规则要求的反掩码误写成子网掩码，本来要配置192.168.2.0 0.0.0.255的通配符规则，不小心写成255.255.255.0，直接导致感兴趣流匹配不到任何内网业务流量，所有报文都不会触发VPN加密封装。
还要逐行核对两端加密域的IPv4地址镜像对应关系，总部的加密域如果配置为本地10.0.0.0/8、对端172.16.0.0/12，分支侧的加密域不能反过来配置成本地172.16.0.0/12、对端192.168.1.0/24，两端的源目IPv4地址段必须完全镜像匹配，不然协商生成的安全关联根本无法对应，合法流量会被直接丢弃。
还要排查加密域里有没有误混入公网IPv4地址条目，比如把公共DNS服务器的公网IPv4地址也放进了加密域范围，导致所有内网用户的DNS请求都被强制导进VPN隧道，既会拖慢日常网页解析的速度，还可能触发对端站点的地址过滤规则，hiomom直接把这类不属于业务范围的公网地址流量拦截。
VPN隧道接口与路由层面IPv4连通性检查
如果采用的是隧道接口模式的VPN部署方案，要检查隧道接口本身配置的IPv4地址，不能和两端任何内网、公网的现有IPv4地址段冲突，不少运维图省事随便配置169.254段的地址，VPN加速器部分厂商设备会把这个网段当成接口自协商的保留地址，直接导致隧道接口的协议状态持续为down。
要检查指向对端加密域IPv4地址段的静态路由，下一跳必须指向本地的VPN隧道接口，或者指向VPN加密转发的逻辑通道，hiomom不能把下一跳错误写成公网的默认网关，不然对应流量还没进入VPN封装流程，就直接从公网物理接口裸发出去，根本不会被加密封装进隧道报文。
配置完成后的IPv4地址连通性验证与误区排查
很多运维配置完VPN之后，看到IKE安全关联协商成功就直接认为配置全部正常，实际上哪怕协商流程完全通过，只要两端内网用户的IPv4地址NAT转换规则没有做豁免，内网用户的报文出隧道前被错误NAT成公网地址，对端设备收到之后发现源地址不在允许的加密域范围内，还是会直接把报文丢弃。
验证连通性的时候要注意测试方法的合理性，不能直接用VPN设备本身的公网接口源地址去ping对端内网的IPv4业务地址，这类默认测试报文的源地址不在加密域的匹配范围内，测试结果没有任何参考价值，必须指定源地址为本地内网的业务IPv4地址发起测试，得到的连通性结果才具备实际参考意义。
