[分享]应对运营商 udp 屏蔽和 qos 的解决方案，几乎支持任何 udp 程序，适合 kcptun 和 finalspeed

[wangyucn]

专门应对 UDP 封锁和 UDP QoS 的通用解决方案。用 raw socket 把 udp 协议包装成 tcp，模拟 3 次握手，模拟序号，模拟 tcp option，可以让防火墙认为是 tcp 流量；还可以把流量包装成 icmp。支持几乎任何 udp 应用。包括 kcptun 和 finalspeed。支持 openvz。支持 NAT 穿透。稳定。

repo： https://github.com/wangyu-/udp2raw-tunnel ，支持桌面 linux、openwrt、树莓派。

另一个功能是心跳保活、自动重连，自动重连后可以恢复上次的连接，重连后上层连接继续有效，底层掉线上层不掉线。可以有效解各种掉线问题的问题（比如你用 kcptun,就算你拔掉网线重插，或者重新拨号获得新 ip，上层的 kcp 也不会断线）。（功能借鉴自 kcptun-raw ）

udp2raw+kcptun step by step 教程：

https://github.com/wangyu-/udp2raw-tunnel/blob/master/doc/kcptun_step_by_step.md

udp2raw+finalspeed step by step 教程：

https://github.com/wangyu-/udp2raw-tunnel/blob/master/doc/finalspeed_step_by_step.md

[wangyucn]

github 上确实有个 Imcptunnel 很火。

[wangyucn]

@s82kd92l 你说的对。icmp 隧道效果确实不好，我的 20m 带宽用 icmp 模式只能达到 6m,用 faketcp 可以打满 20m。

icmp 对一般情况没用，但是在特殊情况下，比如只有 icmp 能通的情况下，可以救急使用。icmp 几乎没给代码增加维护代价，我暂时没有砍掉的想法。我的精力确实主要 forcus 在 faketcp 上的，不用担心。

[wangyucn]

@HaoyangWei

thx :)

[s82kd92l]

@wangyucn

没必要在 2 层与 3 层同时作业， 建议单独开一个 tun/tap 设备，添加一个内网地址 192.168.254.254 之类的，再利用 ip_forward 和 iptables masquerade，可以在第 3 层完成所有动作。

[wangyucn]

你说得很对。tun/tap 配合 ip_forward 也可以实现。https://github.com/chobits/tapip ,github 上这个项目就是这个原理。

这算实现路线的区别吧，tun tap 的方式我没深入研究，我从一开始就感觉 raw 的方式比较容易，就 forcus 在这个方案了。

2 层 3 层同时作业，看起来确实有点脏。 不过我已经做好了同时在 2 层收发的功能。用一个隐藏选项--lower-level 可以开启。在项目的一个 issue 里有提到。

[s82kd92l]

可是我觉得在第二层收包会带来性能问题啊，因为这个肯定需要遍历所有收到的 IP 包，不管目的地是否是 faketcp，而如果只是普通 IP 包的话，iptables 会再次遍历剩下的 IP 包。iptables 是内核实现，遍历速度应该比用户态快很多吧。

尤其是部署在路由器上的时候，双重遍历应该会带来很大压力吧。

新内核上好像有个 ebpf 接口，配合 pcap 应该能在内核态进行 filter，如果你坚持在第二层处理的话可以利用这个加速一下。

[wangyucn]

@s82kd92l

补充以下，关于 icmp 模式的。我这边的 icmp 没有 nat pipe 很快失效的问题。 开着一个 ping 可以 ping 几天不掉线。

貌似性能不好是因为运营商做了 icmp 流量或者包速限制。具体是流量还是包速我没有实验。

[wangyucn]

@s82kd92l
这个我已经实现了，在内核态用 bpf filter 做过滤，满足过滤条件的才会传到用户态。不会遍历所有包。

看起来你在这个方面很专业呀，期待你提交的代码 ：）

[wangyucn]

bpf filter : https://www.kernel.org/doc/Documentation/networking/filter.txt

不用担心内核版本不够新，这个据我查到的资料在 linux 2.1 版就有实现了。

[wangyucn]

@s82kd92l 这个是不用配合 pcap 的。直接用 setsockopt attach 在 socket 上就可以了。见我给 kcptun-raw 提的 issue，很简单，就几行代码：

https://github.com/Chion82/kcptun-raw/issues/15

[t123yh]

@s82kd92l 并不需要 TCP 状态机呀。他收到包就转发，如果有丢包也由上端来处理。

[s82kd92l]

@t123yh

syn,ack,seq 这些还是要装得像一些，不然过不了防火墙。不能总是用同一个 seq 啊，否则太容易识别了

[pisser]

支持 shadowvpn 吗？

[wangyucn]

@s82kd92l @t123yh
有一点简单状态机。syn,synack,ack 这些改装的都装了。前几个数据包(udp2raw client 和 server 互相认证的认证包)，还模拟了重传。

再后面（真正承载数据的包）的模拟就比较简单了，就是 seq 增长，ack_seq 跟着收到的 seq 增长一下。

========================
我以后可能会模拟一个从外部看起来完全和 tcp 一样、无法封杀的协议。模拟重传和拥塞控制但是支持实时乱序到达。

拥塞控制模拟带来的问题可以通过多条 tcp 克服。重传带来的 overhead 大部分时间都不大，普通 tcp 不能承载 Udp 的原因主要是不支持乱序到达，一个包丢了后续的包都必须等这个包的重传完成才能投递（一个包丢了会阻塞住所有包的投递）。

这个想法的可行性是没问题的。有一篇论文就是提了这个，https://arxiv.org/pdf/1103.0463.pdf 。但是他没有公开他的实现。而且他是用改内核的“笨”方法实现的，部署难度堪忧 = =.

[wangyucn]

@pisser 我没有用过，shaowvpn udp 模式应该没有问题。 他的 tcp 模式是用跟 udp2raw 类似的方式实现的，你可以直接用 tcp 模式。 如果连不上再试试套上 udp2raw

[swulling]

有点意思，我们办公网对 UDP 做了封禁，可以试试这个

[s82kd92l]

@wangyucn

"我以后可能会模拟一个从外部看起来完全和 tcp 一样、无法封杀的协议。模拟重传和拥塞控制但是支持实时乱序到达。 "

这个不用自己实现，直接在 faketcp 上加个 sctp 就行，什么 multihoming, multistreaming, out-of-order delivery 都有，sctp 内核态与用户态实现都有现成的。webrtc 就搞了个 sctp over udp, 咱只需改成 sctp over faketcp 就好

[wangyucn]

@s82kd92l 你可能没理解我的意思。我的意思是这个 faketcp 对标准 tcp 的模拟不够完全，所以如果运营商做深度包检测的话，理论上有可能把 faketcp 流量区分出来，再有针对性的 qos。 所以我打算模拟个 real-tcp 来代替 fake-tcp，消除被封杀的可能。

[s82kd92l]

@wangyucn

这个深度检测我觉得是多虑了。运营商的 qos 和流量区分完全是依赖与硬件设备提供商，他们没有自主开发深度检测的能力(大流量下用 cpu 做 spi 不现实，都是硬件 asic 做)。等到整个产业链都开始针对 faketcp 时，可能 ipv4/udp-qos 这些都不存在了。

[wangyucn]

@s82kd92l 这是个好消息 ：）

可以先用 fake-tcp，如果真有 real-tcp 的需求，我再做。