在前面配置飞塔防火墙跟我们的自研strongSwan管理系统对接时（成本省下99.7%！用40元的腾讯云服务器自建IPsecVPN，成功对接企业级飞塔防火墙），我们提到过一个飞塔新版本防火墙支持的新功能：使用TCP封装进行IKE协商。IPsec VPN的IKE协商，竟然不用UDP，改用TCP了？这背后究竟是人性的扭曲还是道德的沦丧？
不！其实，这个操作是有RFC规范支撑的（IKE和IPsec数据包的TCP封装），思科工程师在2017年就发表了这一RFC。对于IKEv2，设计了一种在TCP连接内封装IKE控制消息以及IPsec数据消息的方法。注意，规范中描述的是，可以在TCP连接内封装IKE控制消息以及IPsec数据消息，而飞塔新版本防火墙仅介绍了使用TCP协商IKE，那具体是怎么样呢？我们来验证一下。
我们上次介绍的是创建自定义IPsec隧道的方式，有明确的提示步骤。今天，我们依旧选择最新版本v7.6.5 build3651的防火墙，先使用VPN向导来配置一下。
可以看到，这里的站到站VPN支持对端是飞塔或者思科的设备，这就说明思科应该也是支持这个技术的。此外，我们注意到飞塔也支持ADVPN了（网络工程师的“白嫖”指南：手把手教你用免费IPv6，搭建企业级ADVPN专网），后面有机会测试一下。
本次先选择站到站，隧道名称配置为TCP，单击【开始】。
没想到，对于飞塔设备之间的互联，它默认的传输模式又成了UDP。还得手工切到【自动】来支持TCP协商，并且使用Fortinet封装也得手工开启，提示了符合RFC8229的协议规范。
简化配置，我们本次只是为了检查一下他是怎么协商的，所以远端站点和远端子网都配置简单一些。
本地站点的配置也简化，选择到本地接口就行了。
这就是使用向导配置最好的地方，可以自动不全地址和地址组的对象，并添加相关的策略与路由，直接提交即可。
接下来，我们按照相同的方式配置好对端设备。
配置完成之后，隧道马上协商成功。我们看一下抓包情况。
很奇怪，不是说默认仍是先使用UDP封装吗？如果UDP 500和4500都协商失败才回退到TCP吗？怎么一上来就TCP了？
我们看一下正常的IKEv2协商过程：
可以看到，正常的ISAKMP协商也是有4个握手报文的，在飞塔的协商过程里变成了3个，剩下的就都是TCP握手了。
而且，RFC规范建议使用专门为IPsec NAT穿越保留的TCP端口4500，飞塔也没有用，而使用的TCP端口443。
看来，飞塔还真是搞了一套私有化的对接协议，怪不得在配置时一直提醒：IKE TCP和HTTPS使用相同的端口，会影响管理访问，原来用的不是标准的4500端口，用443端口可不就是会影响HTTPS管理访问嘛。
如果把这个私有协议拆开来看，貌似就正常多了。正常的SA建立有2个交换：IKE_SA_INIT交换和IKE_AUTH交换。
在本次协商中，10.23.1.3设备请求了3次标准的IKE_SA_INIT交换，但是10.12.1.1没有响应；随即10.23.1.3设备开始向10.12.1.1的443端口发起请求，对方秒回。
在第一次TCP三次握手完成后，数据流的第一个报文内容是494b45544350。
这符合RFC 8229有关流前缀验证的协议规范，即TCP连接建立后发送的第一条数据必须是6字节的固定前缀IKETCP(0x49 0x4b 0x45 0x54 0x43 0x50)。
此外，抓包显示通信使用了TCP 443端口，虽然RFC规范建议默认使用4500端口，但规范也明确允许使用任意协商好的TCP端口，对于飞塔设备而言，其选择了伪装成HTTPS流量以绕过防火墙，这好像也并不违反RFC规范，缺点就是仅支持飞塔设备之间的对接时使用。
这下好了，我本来还准备封堵中间传输设备的UDP端口500和4500的，没想到他直接给我跳过了。
这次深入的抓包分析告诉我们，技术规范在落地时常因厂商策略而变形。飞塔防火墙的TCP封装IKE实现，更像是一种在特定场景下追求连接成功率的务实优化。它提醒我们，在现代网络管理中，仅关注传统端口已不足够，深度流量识别变得愈发重要。
你的网络中是否也存在这类伪装的流量？欢迎在评论区分享你的见解！
声明：来自铁军哥，仅代表创作者观点。链接：https://eyangzhen.com/6174.html
