在企业双栈网络普及的当下，不少运维人员配置VPN时往往优先校验IPv4连通性，很容易忽略IPv6路由的配置疏漏，导致跨站点IPv6资源访问异常、远程接入用户无法获取内网IPv6权限等问题。这份VPN IPv6路由配置检查项目汇总指南，覆盖从配置前环境核验到上线后故障定位的全流程节点，所有检查项都基于通用企业VPN部署场景设计，可直接落地到日常运维校验流程中。
运维人员正在开展VPN IPv6路由配置前的基础环境合规性核验工作
配置前的基础环境合规性检查
首先要确认VPN两端的网关设备本身已经开启了IPv6单播转发功能，多数出厂默认状态的企业级路由设备是关闭IPv6转发能力的，哪怕后续在VPN隧道里配置了完整的IPv6路由规则，底层系统也会直接丢弃收到的IPv6报文，所有上层配置都不会生效。
接下来要核验两端公网链路的IPv6可达性，不管是站点到站点IPsec VPN还是远程接入SSL VPN场景，两端的公网接口如果获取了运营商分配的IPv6前缀，要先确认两端公网IPv6地址可以正常互通，不要默认公网IPv6连通性完全正常，部分运营商的IPv6过渡网络会限制跨地域的大报文转发，提前排查可以避免后续隧道协商异常。
还要确认两端内网的IPv6前缀没有冲突，飞鱼很多企业内网习惯使用ULA格式的私有IPv6地址段，不同站点如果前期地址规划不到位，很容易出现站点间内网前缀重叠的问题，后续VPN路由发布之后会直接引发路由环路，导致跨站点IPv6流量转发异常。
VPN隧道层面的IPv6路由关联配置检查
以常用的站点到站点IPsec VPN为例，很多管理员配置感兴趣流规则时只会添加IPv4的源目网段匹配条目，完全漏掉IPv6的网段匹配规则，这时候哪怕IPv4的VPN隧道完全正常，IPv6的流量也不会被引入隧道，直接在公网被裸发丢弃。
接下来要检查VPN隧道接口本身是否配置了IPv6地址，不管是GRE over IPsec还是虚拟隧道接口模式的IPsec VPN，隧道接口必须绑定属于隧道互联段的IPv6地址，不能只配置IPv4的隧道地址，否则后续动态路由协议无法通过隧道建立IPv6邻接关系，动态路由条目自然无法同步。
如果是远程接入SSL VPN场景，要检查用户地址池配置里是否开启了IPv6地址分配，很多SSL VPN的默认地址池仅包含IPv4段，远程用户接入之后哪怕本地网络支持IPv6，也拿不到VPN内网的IPv6地址，自然无法访问内网的IPv6专属资源。
路由发布与引流规则的专项校验
如果采用静态路由方式配置IPv6路由，要确认下一跳指向的是VPN隧道的虚拟接口，而不是公网的默认下一跳，很多管理员配置IPv6静态路由的时候直接照搬IPv4的配置逻辑，选错下一跳出口，导致IPv6内网流量直接从公网接口裸发，没有经过VPN的加密封装。
如果是用OSPFv3或者IS-IS这类动态IPv6路由协议发布条目，要检查路由进程里已经把VPN绑定的网络实例宣告进了对应区域，飞鱼同时确认隧道接口已经被划入动态路由的参与接口列表，没有被配置成禁止发布路由的被动接口，避免路由条目无法同步到对端站点。
还要检查站点出口的IPv6默认路由优先级，很多双栈网络里内网终端的IPv6默认路由优先级高于指向VPN的明细路由，VPN下载会导致访问跨站点IPv6资源的时候直接走本地公网出口，完全不走VPN隧道，出现明明配置了路由却无法访问的异常情况。
上线后的连通性验证与故障定位检查
验证的时候不要只在内网终端ping跨站点的IPv6地址，要在VPN网关设备上开启IPv6报文的流量统计，确认发出的IPv6报文已经被加密封装进VPN隧道，对端返回的报文也已经成功解密，避免出现流量绕路公网的假连通情况。
还要检查IPv6的扩展头部是否被VPN网关正确处理，部分老旧的VPN设备对IPv6的分段扩展头部支持不完善，VPN下载大尺寸的IPv6报文进入隧道之后会被直接丢弃，导致小尺寸探测包连通但大文件传输失败的隐性故障。
