[分享]应对运营商 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]

windows 下配合虚拟机可以稳定使用。

[ovear]

先收藏下，不过如果走 TCP 不是就失去了 UDP 的意义了么 0 0

[kuretru]

$$下加一层 kcptun 现在再加一层 udp2raw 隧道，怕是我的搬瓦工吃不消

[15015613]

@ovear
还是 udp，不过伪装成 tcp。

[wangyucn]

这不是真正的走 TCP，是给 UDP 加上 tcp/icmp 包头，以骗过 udp 防火墙。本质上仍然是 UDP，跟传统的 tcp over udp 是不同的(比如 tcp 模式的 openvpn)。

引用一下我在 github 上的回复：

```
@wangyu-
有一个疑惑，如果 udp over tcp 的话不就失去 kcptun 的意义了？
本来就是因为 tcp 协议效率低才会用 Kcptun 吧？
@wangyu-

wangyu- commented 7 hours ago • edited
@sqwwqw5 这是个非常好的问题。
普通的 udp over tcp 方案配合 kcptun 确实几乎没有意义(比如用 openvpn 把 udp 转成 tcp 再用 kcptun 加速的想法)。
udp2raw 的方式是，用 raw socket 给 udp 加上 tcp 包头，模拟 tcp 握手和 seq ack_seq，以打通 tcp NAT pipe 和骗过 udp 防火墙。但是这种模拟的 tcp 本质上还是 udp，继承 udp 的实时乱序到达特性，没有拥塞控制和重传（所以可以让上层的 kcptun 自己完全控制拥塞和重传），忽略对方的接收窗口。本质上不属于 udp over tcp，所以没有类似问题。

==updated==
重新编辑了一下，补充了些细节。

普通的 udp over tcp 方案配合 kcptun ”失去意义“的原因：tcp 只支持按序到达，破坏了上层承载的 udp 的实时性(tcp 只要丢一个包，后续的包就都要等这个包的重传完成才能投递给上层，上层承载的 udp 也继承了这个特性，会为上层 kcp 引入额外延时，也可能会误导 kcp 造成额外重传)； tcp 有激进的拥塞控制，上层承载的 udp 不能自由控制发送速率； tcp 丢包后还必须重传，kcp 有自己的重传策略，两个重传策略在一起有双倍重传的问题，造成性能下降。

注:
这里说的是 kcptun_client---->udp over tcp----->kcptun_server 的问题。
不是 udp over tcp---->kcptun_client---->kcptun_server-----> udp over tcp，虽然这个方案也有问题。
```

[wangyucn]

尴尬了，原来回复是不支持 markdown 语法的，格式好乱。 可以去 kcptun 的这个 issue 下看，有我的回复:

https://github.com/xtaci/kcptun/issues/228

[akwIX]

让出口炸的更猛烈一些

[wangyucn]

@akwIX

取决于使用者怎么用。我这个不多倍发包方案，只是绕过 udp qos 限制。udp qos 确实造成了很多不便。

我觉得节省出口的更好方式是看 youtube 用 720p 不用 1080p = = 。

[wangyucn]

不是多倍发包方案

[wangyucn]

假设，仅仅是假设：你的本地运营商不做 udp Qos,而别人的运营商做 Qos,你不希望别人能绕过 Qos，以防止挤占你的出口带宽。

这也是种自私吧 = =。

[wangyucn]

@kuretru 96M 的那种，一小时平均 CPU 占用不能超过 10%的，确实有点吃不消。

[Love4Taylor]

外挂就比较累 看哪个项目愿意集成吧 233333

[wangyucn]

@Love4Taylor

其实有人做过集成的版本，只是 kcptun 作者决定不 merge 这个功能。比如这个，https://github.com/Chion82/kcptun-raw

外挂的方案比较通用。这个可以支持 kcptun finalspeed openvpn 还有 ss 的 udp 转发。

[suikator]

配合 ss 的 udp 转发 是无加密的吗

[s82kd92l]

这个非常有意义，曾经有一样的想法但觉得实现起来很麻烦。想知道楼主怎么实现的？

如果要伪装成 tcp，必然需要实现一个用户态 tcp 状态机，难道要借用内核 tcp 代码？

还有，感觉项目名称不准确。这个项目核心在于 fake-tcp/icmp 头部包装隧道，而 payload 可以是 udp，也可以是 tun/tap，对吧？鉴于 icmp-tunnel 这东西早就有人实现， 建议改为 faketcp-tunnel

[wangyucn]

@suikator ss 本身是加密的，udp2raw 也有加密。不用担心失去加密。

而且 udp2raw 的加密是防重放攻击的，ss 的 udp 模式据我所知不能做到完全的放重放攻击。

[s82kd92l]

感觉 icmp 隧道比 faketcp 效果还是差很多的，尤其是 nat 设备会让 icmp 很快超时，而 faketcp 连接可以保留很长一段时间。建议楼主砍掉 icmp,专注 faketcp。

[HaoyangWei]

很有想法，手动点赞 :D

[suikator]

@wangyucn ok 回去试试

[wangyucn]

@s82kd92l
实现起来确实麻烦。 首先用 iptables 屏蔽掉内核对指定端口的 tcp 处理。 然后用 raw_socket 在 3 层发 ip 包，用另一个 raw_socket 在 2 层（链路层）收 Ip 包（因为用 iptables 屏蔽掉，就无法在 3 层收到包了）。

确实实现了简单的用户态 tcp 状态机。这个没有重传策略、拥塞控制、按序到达，所以简单很多。

名字我就不改了 = =。 这个项目可以把 udp 用 raw 发出，支持模拟成 tcp/icmp/udp 本身。所以就叫 udp2raw 了 = = 。

github 上确实有个 Imcptunnel 很多，但是那个是不能穿透 nat 的，而且有一个大问题就是没有认证 /加密机制，你架设了服务，任何人都可以用。