20191001 更新：

• 高通SFE(开源)、博通CTF(闭源) 都属于软件实现的NAT加速，属于 accelerated NAT，不是 HNAT
• 高通SFE(fast-classifier)也会在一定程度上将数据包offload，tcpdump 在 ppp 接口抓包表现同博通CTF，在连接建立后很快即被 offload；

1. 写在前面

祖国母亲的生日要到了，墙自然也就高了，在两个 IP 被 ban 之后，决定周末彻底换用 wireguard （后记：换 wireguard之后，国庆的前两天每天被封一个端口，一怒之下抓包发现其头部特征明显，遂弃之）；
其实6月份的时候那一波，就有换掉 sha（delete me）dow（delete me）socks 的想法了，于是这个周末都在折腾梯子，踩到了各种坑，技术的、非技术的。。。心累。。。

2. 问题描述

首先，wireguard 是无状态的（协议层）(wg 有握手过程，虽然使用UDP简化了状态，但是协议层还是有状态的)，因此对于设备漫游非常友好，随意迁移到不同网络下，基本察觉不到可用性的影响

• 路由器是网件 R6300v2（俗称电磁炉），梅林固件（kookshare 的最后一个版本）
• PC 设备连接 5G 频段的 WiFi, 使用 wg-quick 启动 wireguard， 默认全局路由，工作正常
• 切换到 2.4G 的 WiFi 信号， wireguard 工作不正常， 无法连接服务器；手动修改路由策略，确认服务器正常可达， 但 wireguard 无法联通，有出去的包，但收不到响应包
• 同样地，从 2.4G 切换到 5G 也存在同样的问题
• 但此时切换到其他路由器的网络，wireguard 正常可用

3.关键排查过程

• 在各种接口上抓包都看不到包，甚至 ppp0 接口上面都看不到肯定发出去了的包；在 Wlan 接口上只能看到服务器的响应包，没有设备发出的包，一度感到崩溃
• 梅林的无线驱动 (wl) 十分有趣，不同频段的 WiFi 接口所展现的设备名是 eth1、eth2 这样的；同样有趣的是他们没有使用 hostapd 管理 WiFi，而是使用了一个名为 nas 的程序
• 关闭 wireguard，单独分析抓包失败的问题； 发现 icmp 是稳定可以抓到的，而 udp、tcp 只能抓到链接开始时候的部分报文，之后 tcpdump 就安静了
  这个时候已经基本确定是 nf_conntrack 的问题，也就是说一个链接被 conntrack 记录之后，就被 offload 了，因此 tcpdump 会抓不到
• 卸载 ctf 模块 (rmmod ctf)，现象消失，问题解决

4. 结论猜测（可能存在细节错误）

在 conntrack 记录确定了五元组之后， ctf 模块就接管了 netfilter 的工作；然后可能是因为要支持 Wlan 接口的 offload，估计把 conntrack 条目和网络接口绑定了（可以使用其他设备监听无线帧来确认是否如此）

那么这样你从 2.4G 换到 5G的时候，已有的 tcp、udp 连接都会无法使用；正常的 TCP 程序和非“常连接”的 UDP 程序，都会使用随机源端口重发请求，网络五元组发生改变，于是建立新的 conntrack，也就不影响上网; 而 wireguard 启动之后，源端口不会改变，整个五元组都没变，所以匹配上旧的 conntrack 记录，发包没问题，回包会被 ctf 继续走之前的 WiFi 接口发出去，完。