Wireguard 漫游与 CTF NAT加速的坑爹经历

20191001 更新:

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

1. 写在前面

祖国母亲的生日要到了,墙就自然高了,在两个 IP 被 ban 之后,决定周末彻底换用 wireguard. 其实6月份的时候那一波,就有换掉 shadow(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 接口发出去,完。

发表评论

电子邮件地址不会被公开。 必填项已用*标注