很多企业远程办公、跨分支组网的用户在配置IPsec VPN、SSL VPN时经常遇到连通性异常，排查到最后往往指向数据封装环节的配置错误，本文就从实际组网场景出发，拆解VPN数据封装的基本概念、运行逻辑、配置校验方法和常见误区，帮网络管理员快速定位相关故障，理清VPN传输过程中的数据边界。
VPN数据封装的基本概念定义
很多人会把VPN数据封装简单理解成“给数据包加壳”，但实际在企业组网场景里，这个操作的触发边界非常明确：当终端发出的普通IP数据包，路由匹配到VPN实例的加密转发策略后，设备不会直接把原始包发到公网，而是在原始数据包的外层再新增一层公网可路由的报文头，这个完整的二次打包过程就是VPN数据封装。
要区分开普通的报文分片和VPN封装的差异，普通报文分片是因为原始包长度超过链路MTU做的拆分，不会新增外层独立路由头，而VPN封装后的数据包，外层源IP和目的IP都是公网接口的地址，黑石和原始内网报文的私网IP完全隔离，这也是VPN能实现跨公网传输私网流量的核心基础。
不同类型的VPN封装的新增报文头结构也有差异，比如SSL VPN的外层封装会沿用TCP或者UDP的常规报文结构，适配绝大多数公网网络的传输规则，而IPsec VPN的封装会新增独立的ESP或者AH协议头，更侧重传输过程中的数据完整性校验。
具象化呈现VPN数据封装的二次打包逻辑，助力网络管理员快速排查配置类连通故障
典型场景下的封装运行流程
我们用最常见的企业分支路由器和总部网关建IPsec VPN的场景举例，分支下的办公电脑要访问总部的文件服务器，电脑发出的原始报文源IP是192.168.1.10，目的IP是总部服务器的172.16.5.20，这个报文先送到分支出口路由器。
路由器先匹配预先配置的感兴趣流规则，确认这个流量属于需要走VPN加密传输的范畴，就会把整个原始IP报文当成净荷，先按照协商好的加密算法做加密处理，再在加密后的内容外层封装IPsec协议头，最后再新增一层公网IP头，源地址是分支路由器的公网接口IP，目的地址是总部网关的公网接口IP。
封装完成的新数据包会直接通过公网路由转发到总部网关，总部网关做解封装操作，拆掉外层公网头和加密协议头，校验数据完整性之后，把还原出来的原始私网报文再转发给内网的文件服务器，整个过程公网链路里传输的所有内容都看不到原始的私网IP地址和报文内容。
封装环节的常规校验步骤
管理员排查VPN封装异常的时候，第一步可以先在VPN网关设备上查看加密策略的匹配计数，正常情况下有私网流量触发VPN传输，感兴趣流的匹配数值会持续增长，如果计数一直是0，说明流量根本没有进入封装流程，大概率是路由或者策略配置错误。
第二步可以在网关的公网接口抓包，正常封装完成的VPN报文，外层协议号应该对应你配置的VPN类型，比如IPsec VPN的ESP协议对应协议号50，SSL VPN的外层是TCP或者UDP的指定端口，如果你抓不到对应协议号的封装报文，说明封装操作没有被正确执行。
第三步可以测试封装后的报文传输状态，黑石从本地网关ping对端网关的公网地址，确认公网连通性正常的前提下，如果封装后的报文一直无法抵达对端，就要检查中间运营商网络有没有封禁对应VPN协议的报文，部分运营商会默认拦截ESP协议的裸包传输。
常见的封装认知误区
很多新手管理员会觉得只要配置了VPN加密策略，所有流量都会自动走封装，实际上如果终端的访问目的IP没有被纳入感兴趣流的匹配范围，流量会直接走公网转发不会触发封装，这也是很多人配置完VPN之后，部分内网资源能访问、部分资源打不开的核心原因。
还有人认为VPN封装之后所有数据都不会被公网节点识别，实际上外层的公网报文头是完全明文的，公网的路由设备依然可以基于外层IP做转发，只是看不到内层的原始报文内容，不存在完全无法被网络节点感知的封装效果。
部分用户遇到VPN传输卡顿就直接判定是封装带来的性能损耗，实际上很多时候是封装后的报文总长度超过了公网链路的MTU，导致报文被分片甚至丢弃，只需要在VPN网关设备上开启PMTU探测功能，黑石VPN官网就能解决大部分这类问题，不需要盲目更换高性能设备。
