正式宣传下新写的代理程序 Fyuneru

[sogisha]

Fyuneru 是我在过去几天用 Python （和 NodeJS ）写的代理程序，其原理接近虚拟专用网络。

当前 Fyuneru 只能运行在 Linux 类操作系统上（由于 TUN 设备）。在 Ubuntu14.04 和 Fedora 21 上测试成功。

这个程序的可以在服务器和客户端上分别“安装”一块虚拟网卡（实际上是 Linux 的 TUN 设备）。两块网卡之间直接连接的“虚拟网线”，可以由一系列平行的隧道代理搭建。之后，服务器和客户端就好像位于同一个局域网了。

隧道代理可以由任何协议构建，只要它们能够代理 UDP 包（ UDP 包用来封装从虚拟网卡获得的 IP 数据帧）。目前已经有了一个用 WebSocket 写的版本。未来还可能有借助即时通信协议（ XMPP ），或者 HTTP 等等的版本。

程序的亮点在于：

1. 由于传递的是 IP 数据帧，程序不对隧道代理有什么要求——隧道服务器完全可以和真正的代理服务器分离。
2. 在服务器和客户端上的程序在发送每一个数据帧时都会随机选择隧道——意味着，例如对于同一个 TCP 连接，实际发送的数据包和接收的数据包完全可以走不同的隧道。

此外， IP 数据帧在送进隧道代理之前用对称算法加密，保证机密性和完整性。隧道代理自己也有可能继续加密，那样就更安全了。

---

这个贴子就是借助于 Fyuneru 和 Tor 发出的。项目主页：

https://github.com/sogisha/fyuneru

欢迎试用～程序仍在调试中，如果有什么问题，我会在此回答。

[sogisha]

@aliuwr 可以./run_as.py --debug c|s 就是添加 debug 选项。会输出收发的包。不过我注意到这个确实和别的因素还有点关系，比如如何处理 MTU 大小的包，这应该是问题所在。

我目前没有墙的环境，没办法严格测试，还请多多指教。

@rainy3636 头像是新画的，不过难道没人认出我的 id 和这个软件名的梗？

[sogisha]

@aliuwr 不过这么说难道偶尔还是可用的？(目前能确认这一点对我来说就是好消息了)

我测试时用 polipo 搭的 http 代理到服务器上的 tor 。要注意的是防火墙的设置。

[vzch]

你要不提我都忘了罪恶王冠了，上述内容开 issue 讨论或者单写一份 MD 文档，这边帖子不移走也会沉得很快啦，谢谢

[seki]

看到最后才发现原来是中二皇冠 - -

[aliuwr]

@sogisha 确认大部分时候是可以工作的，只是效率不高，通过 ping 值的起伏可以看出非常不稳定，经常出现极度糟糕的情况。我没法确定是代码问题，还是墙的问题。
重新测试了下，在 youtube 看视频，使用 ss 最高可以有 17000 Kbps ，而这个只有 600 Kbps 。
下面是 ping 的情况：
61 packets transmitted, 60 received, 1% packet loss, time 60085ms
rtt min/avg/max/mdev = 36.600/37.932/40.210/0.699 ms

102 packets transmitted, 92 received, 9% packet loss, time 101258ms
rtt min/avg/max/mdev = 40.696/4020.489/16639.397/5189.823 ms

[quix]

多端口发送数据和楼主的想法不谋而合~ 支持一下
成熟以后 墙就要开始封 udp 了

[aalska]

事实上国内很多运营商是限速 udp 的

[sogisha]

@aliuwr 非常感谢！其实我在墙外，所以在调试中并没有感受到连接问题。我 ping 的时候小 2 个数量级。

我认为一方面是墙的问题，一方面，目前用 WebSocket 或者所有的 TCP 连接传送 UDP 数据包（强调下实际上只是 UDP 数据包的内容，亦即加密的 IP 数据帧）是个很糟糕的主意。对于被代理的 TCP 连接，这就成了 TCP over TCP 。可以说只是用来验证可行性之用。

实话说，我不太理解为什么 SS 会更快。不过既然它很快，那么给我的程序写一个利用 SS 的代理的话是不是也会很快？ XD

---

@aalska @quix UDP 在本程序中只是作为一种内部的接口协议而存在。当然也可以真的在互联网上放出 UDP 包。但是 UDP 包在穿越各种防火墙时并不容易，程序也不好写。

@rwx 这个很难分析啊。我倾向于抱有希望。程序中用到 UDP 的地方，实际上是和中间的隧道代理解除了耦合，不需要等待具体哪个隧道代理完成对包的发送。因为传递的 IP 帧是可以被丢弃的，不像 TCP 协议。实际情况可能是，一个隧道代理被堵塞之后，程序接着往这里发包，包就不会被传送出去。在 TCP 看来包也许是 drop 了，所以会重发。重发时因为随机选择路线，就可能走另一条路线。

[isbase]

想起前几天在 Twitter 看到一句话，大意是 ss 强悍之处不在协议本身而在于它的整个生态。

任重而道远。。。

[l12ab]

得知楼主在墙外，我放心了

[CRight]

@sogisha 在墙外就好，喝不了茶

[rwx]

@sogisha 所以某一隧道被堵塞 /丢包 /速度慢其实只是相当于增加了整体的丢包率，后续可以屏蔽掉不健康的隧道来保证质量？

[TakanashiAzusa]

没细看，不过虚拟网卡的话，那是不是意味着连接上就肯定是全局的呢。。

[Dongdong36]

先顶后看，看到可以在 Fedora 下运行好感动，前两天想试用下 Lantern...诶，都是泪

[Dongdong36]

好巧, 这是我收藏的第 100 个主题～ 2333

[sogisha]

@rwx 原则上可以如此，然而我并没有写这方面的代码。

@TakanashiAzusa 不一定，不过可以。需要配置路由表，本渣表示还是先在服务器上架代理比较好理解。

[TakanashiAzusa]

@sogisha 主要我看你的客户端也是虚拟了一张网卡。。就我的理解来说，用了虚拟网卡的话，全部流量都走这边了吧。。那不就是相当于 VPN 的全局模式吗。

[sogisha]

@TakanashiAzusa 除了虚拟网卡之外，还有路由表是需要配置的，我的理解是类似电脑上有 2 张网卡，比如笔记本同时插网线还用 wifi ，那么怎么上网，走哪个，并不是自动的。类似的 Python 程序确实有使用 ip route 命令自动修改系统配置的例子，退出时改回来。我认为这个比较费解，不知道一来如何保证适合于所有的系统，二来不知道程序出错崩溃之后不改回来会有什么后果，所以先不做。不过，确实应该是有这个潜力的，比如可以先尝试手动配置。

[liuxu]

fork 一下

[lszbao]

好东西啊 必须 mark