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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2660 天前的主题，其中的信息可能已经有所发展或是发生改变。

专门应对 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

第 1 条附言 · 2017-08-11 21:13:55 +08:00

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

如果你觉得有用，求转载= =

第 2 条附言 · 2017-08-15 21:52:10 +08:00

预装了 udp2raw 的 openwrt x86 版 vmware 镜像已发布，容量只有 4.4m 。网卡已经设置成自动获取 ip，开机即用。

地址：

https://github.com/wangyu-/udp2raw-tunnel/releases

如果你没有 vmware，可以安装 vmware player，容量 75m。

第 3 条附言 · 2018-02-21 15:54:02 +08:00

在windows和mac上运行udp2raw，门槛已经极大降低：

https://github.com/wangyu-/udp2raw-tunnel/wiki/在windows-mac上运行udp2raw客户端，带图形界面

第 4 条附言 · 2018-06-21 22:26:09 +08:00

现在udp2raw已经原生支持Windows/Mac/BSD了，不再需要虚拟机：

Windows/Mac/BSD版的repo

76 条回复 • 2022-09-11 04:41:00 +08:00

wangyucn

2017-08-11 18:19:54 +08:00

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

ovear

2017-08-11 18:25:55 +08:00

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

kuretru

2017-08-11 18:28:51 +08:00

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

15015613

2017-08-11 18:29:51 +08:00 via Android

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

wangyucn

2017-08-11 18:30:23 +08:00

这不是真正的走 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

2017-08-11 18:31:34 +08:00

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

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

akwIX

2017-08-11 18:31:45 +08:00

让出口炸的更猛烈一些

wangyucn

2017-08-11 18:38:10 +08:00

@akwIX

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

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

wangyucn

2017-08-11 18:39:11 +08:00

不是多倍发包方案

wangyucn

2017-08-11 18:41:38 +08:00

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

这也是种自私吧 = =。

wangyucn

2017-08-11 18:43:02 +08:00

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

Love4Taylor

2017-08-11 18:45:36 +08:00

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

wangyucn

2017-08-11 18:48:16 +08:00

@Love4Taylor

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

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

suikator

2017-08-11 18:54:50 +08:00 via Android

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

s82kd92l

2017-08-11 18:55:10 +08:00

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

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

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

wangyucn

2017-08-11 18:58:17 +08:00

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

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

s82kd92l

2017-08-11 18:58:44 +08:00

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

HaoyangWei

2017-08-11 19:00:14 +08:00

很有想法，手动点赞 :D

suikator

2017-08-11 19:01:18 +08:00 via Android

@wangyucn ok 回去试试

wangyucn

2017-08-11 19:03:17 +08:00

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

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

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

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

wangyucn

2017-08-11 19:03:49 +08:00

github 上确实有个 Imcptunnel 很火。

wangyucn

2017-08-11 19:09:24 +08:00

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

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

wangyucn

2017-08-11 19:10:48 +08:00

@HaoyangWei

thx :)

s82kd92l

2017-08-11 19:14:47 +08:00

@wangyucn

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

wangyucn

2017-08-11 19:22:01 +08:00

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

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

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

s82kd92l

2017-08-11 19:35:05 +08:00

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

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

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

wangyucn

2017-08-11 19:36:01 +08:00

@s82kd92l

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

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

wangyucn

2017-08-11 19:38:58 +08:00

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

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

wangyucn

2017-08-11 19:40:57 +08:00

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

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

wangyucn

2017-08-11 19:51:19 +08:00

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

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

t123yh

2017-08-11 20:02:59 +08:00 via Android

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

s82kd92l

2017-08-11 20:13:30 +08:00

@t123yh

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

pisser

2017-08-11 20:23:01 +08:00

支持 shadowvpn 吗？

wangyucn

2017-08-11 20:27:18 +08:00

@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

2017-08-11 20:29:59 +08:00

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

swulling

2017-08-11 20:41:31 +08:00 via iPhone

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

s82kd92l

2017-08-11 20:50:25 +08:00

@wangyucn

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

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

wangyucn

2017-08-11 20:55:41 +08:00

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

s82kd92l

2017-08-11 21:08:25 +08:00

@wangyucn

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

wangyucn

2017-08-11 21:12:03 +08:00

@s82kd92l 这是个好消息：）

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

wangyucn

2017-08-11 21:25:11 +08:00

@s82kd92l 我觉得运营商有时候都不是故意 UDPQos 你，只是他们设备对 udp 支持不好，或者 udp NAT 的设备压力太大导致不稳定。我这边的移动 tcp 多线程（单线程当然不行）连国外基本都满速。但是 udp 连有一些方向的线路总是时断时续，有的时候 nat pipe 都打不通。既然 tcp 都满速，udp 故意 Qos 你有什么用呢。

所以我觉得这个项目某种程度上也是在帮运营商，解决 udp nat 支持不好带来的用户抱怨 = = 。

wangyucn

2017-08-11 21:25:42 +08:00

当然，这纯属不负责任猜测。

s82kd92l

2017-08-11 21:28:04 +08:00

@wangyucn

运营商绝对是故意 udp-qos 的，主要限制 p2p, 不然 bt/emule 会把他们整疯的。

FishTorres

2017-08-11 21:29:54 +08:00

QUIC 跟着倒霉

wangyucn

2017-08-11 21:30:44 +08:00

@s82kd92l 我这边到美国西海岸 udp 基本满速，到日本经常连都连不上，但是多线程 tcp 到日本和美国西海岸又都满速。有点费解。

terrytw

2017-08-11 21:32:32 +08:00

有意思，非常支持！

1423

2017-08-11 23:27:20 +08:00

测了下 kcptun + udp2raw-tunnel 一起用，带宽利用率相当低。。不知道怎么分析原因？

wangyucn

2017-08-11 23:43:06 +08:00

@1423，性能问题去项目里提 issue，贴出配置吧。

有可能你使用的是路由器版，用了 aes128cbc 加密，导致 cpu 被打满。路由器建议用 --cipher xor --auth simple

wangyucn

2017-08-11 23:49:45 +08:00

我这边移动 20m 宽带，测试出的性能：
./iperf3 -c 10.222.2.1 -P40 -t30
[SUM] 0.00-30.00 sec 68.3 MBytes 19.1 Mbits/sec 3391 sender
[SUM] 0.00-30.00 sec 64.6 MBytes 18.1 Mbits/sec receiver

./iperf3 -c 10.222.2.1 -P40 -t30 -R
[SUM] 0.00-30.00 sec 71.3 MBytes 19.9 Mbits/sec 10046 sender
[SUM] 0.00-30.00 sec 56.6 MBytes 15.8 Mbits/sec receiver

客户端在 linux 虚拟机上，如果是路由器的话，因为 cpu 速度的原因，只有 8Mbits/sec.

wangyucn

2017-08-12 00:10:10 +08:00

server 在 vultr 日本。

Damaidaner

2017-08-12 09:28:50 +08:00 via Android

收藏！！

hjc4869

2017-08-12 10:14:52 +08:00 via Android

Windows 没必要用虚拟机，装 Windows Server 就能用 raw socket 艹 tcp 了。

或者用 pcap 之类的也行

johnlui

2017-08-12 10:34:00 +08:00

kcptun 和 BBR 有实测数据嘛？

wangyucn

2017-08-12 11:02:05 +08:00

@johnlui
window raw socket 没有 linux 的功能强大。pcap 的话得移植一下。winpcap 也要单独装得，干脆装虚拟机吧。如果嫌麻烦可以去网上找做好的 vmware 镜像。

@johnlui
kcptun 的数据暂时没有。finalspeed 移动 20M 宽带从日本下载，1.6MB/s （ Byte ）的下载速度。

wangyucn

2017-08-12 11:03:51 +08:00

BBR 感觉跟这个项目不搭边吧。也许你想到了什么特殊用法？比如用 openvpn+udp2raw 再测开启了 bbr 的 tcp 性能？

linhua

2017-08-12 12:15:14 +08:00

@wangyucn
厉害

@kuretru
如果丢包率不高的话(<15%)，可以使用 BBR
github.com/linhua55/lkl_study 搬瓦工 64M 也是可以使用的，只是 CPU 占用有点高

wangyucn

2017-08-12 12:36:32 +08:00

不敢不敢
@linhua 是最早实现了用 raw_socket 中转 udp 这个点子的人:
https://github.com/linhua55/some_kcptun_tools/tree/master/relayRawSocket

Chion82 在他的基础上加上了 tcp 握手功能，集成到了 kcptun 里:
https://github.com/Chion82/kcptun-raw

我这个项目，把 kcptun-raw 的功能做成通用的了，再加了点小功能。如果没有 relayRawSocket，可能也就没有 kcptun-raw 了，也没有我这个项目了。

palxex

2017-08-12 12:54:46 +08:00

建议还是考虑一下 pcap。这样 win/mac 上应该都能原生跑了（虚拟机感觉还是太重），final speed 的 tcp 模式印象中就是这么做到跨平台的，尽管可能是实现略 naive 始终没做到 udp 模式的稳定程度，但原理上跟这个项目应该一样是用 raw socket 发包。

wangyucn

2017-08-12 13:09:28 +08:00

finalspeed 用的就是 pcap。而且他也不愿意同时支持 pcap 和 raw socket，所以他的版本不能在 openvz 上运行。

支持 windows 理论上没问题，问题是开发成本= =。 raw socket 要改成 pcap,epoll 要改成 libevent，暂时不想增加开发负担。

虚拟机很稳定，而且性能很好，如果爱折腾还是装个备用吧。

wangyucn

2017-08-12 13:12:40 +08:00

可以考虑后续发布装了 udp2raw 的 vmware image。用 openwrt x86 版的，容量可以控制在几 MB。

linhua

2017-08-12 14:24:15 +08:00

@wangyucn
这扯得就有点远了，当初因为 kcptun 才写了这个小玩意，不过能力有限，只能凑合着用。不过和 finalSpeed 结合着用还是会断流（ kcptun 没问题），然后就改用 bbr 了。

用 docker，网络设置成桥接网卡，应该也可以

iijboom

2017-08-12 15:32:06 +08:00

老夫 iperf3 测速这么多年，都是直接单线程梭哈！能跑满就继续上网，跑不动就下海干活(x

KCheshireCat

2017-08-12 15:44:47 +08:00

@wangyucn #55

如果 fack-tcp 完全工作在 2 层或者 3 层,隧道内部承载真实 TCP 流的话,

就可以让承载的流自己完成拥塞检测和重传.

把这个 fack-tcp 当作 TCP/IP 里的一层,不重复劳动,只完成本职工作.

wangyucn

2017-08-12 16:01:28 +08:00

@iijboom 我这个是 udp2raw+openvpn 测的，只应对 qos，没用 kcptun/finalspeed 这种加速工具，所以只有用多线程才能测出吞吐。 kcptun finalspeed 这种工具通过自定的拥塞 /重传 /ACK 策略可以让单线程达到很高的速度，所以单线程测大概也能反映出信道的吞吐率。

udp2raw+finalspeed 之前我测过一次，移动 20m 带宽,单线程 1.6MByte/s。

@KCheshireCat faketcp 通过 openvpn 承载真实 tcp 确实是让上层承担拥塞和重传的，这种用法里 faketcp 相当于 ip 层的作用。

tys

2017-08-15 11:33:51 +08:00

@pisser 可以用。已测试。

wangyucn

2017-08-15 21:53:34 +08:00

@palxex 预装了 udp2raw 的 openwrtx86 虚拟机镜像已发布，容量 4.4m 。

wangyucn

2017-08-20 14:19:55 +08:00

"用 docker，网络设置成桥接网卡，应该也可以"

@linhua 我看了一下 docker，它只有在 linux 上才是原生的，在 windows 上和 mac 上都是跑在 virtualbox 虚拟机里的。所以。。还是直接用虚拟机更轻量吧。我在 release 里发布了预装了 udp2raw 的 ova image(容量也是 4.4m)，用独立的 virtualbox 可以运行，用安装 docker tools 时自带的那个 virtualbox 应该也行。