cproxy: 使用简单的 Linux per app 透明代理

[iceorange]

刚开源了我的新项目 cproxy: https://github.com/NOBLES5E/cproxy 。

解决的问题和 proxychains 一样，就是对单独进程走代理，而不需要进程本身支持代理。

使用上和 proxychains 一样简单，但是可以代理 TCP, UDP 并且对静态链接的程序（比如像 docker 这样的 Go 程序） 和已经在运行的程序也可以进行代理。

之前也用过 graftcp 等等软件，大部分情况下挺好用。不过 graftcp 每次要起两个程序，而且最近有代理 DNS 请求的需求了，只好自己动手了。

既然开源出来了，还是希望更多人能知道，对大家产生帮助，也收集一下建议。欢迎讨论~

[Jirajine]

@iceorange #9 因为操作 iptables 不是原子性的，一个进程在添加 /删除规则的同时正好有其他进程也在添加 /删除规则，最终的结果就是乱七八糟。
我看了一下你是用 pid 区分链名，多数情况下应该没有问题，但要是恰好有回收的 pid 导致重复就会导致非常令人困惑且难以排查的 bug 。
另外你的大多数逻辑甚至连文件 IO 都不写代码而是用 shell 命令实现，与其把 shell 脚本嵌入到代码里，直接用 shell 脚本不方便吗？
解析命令行参数和信号处理同样可以用库。至于检查错误，shell 脚本检查 shell 命令的错误当然比 rust 容易。

[iceorange]

@Jirajine 真的很奇怪。
1. 说乱七八糟不要凭感觉，需要具体的分析。为了避免误导其他人，我解释一下。在这种场景下，不存在 pid 回收的问题，因为 cproxy 是把自己的 pid 放入 cgroup，再 launch 子进程。删除链是 cproxy 进程进行删除，因此删除的时候不可能 pid 被回收。而且 pid 这个事情跟原子性完全没有任何关系，不要把不相关的事情放在一起，逻辑非常混乱。
2. 您觉得 shell 脚本写更好，是您的 personal taste，争论这种 detail 没有任何意义，只会把讨论带偏。我觉得 rust 写更好。

[iceorange]

@Jirajine 建议讨论的时候不要太多 “乱七八糟”、“十分不合适” 这种主观感觉。这对技术社区讨论是不利的。
比如您觉得使用 iptables 有问题，那么讨论方向应该是使用了 iptables，比如多进程一起操作，可能会带来什么具体后果，这个后果会造成什么影响，对使用场景是否不可接受。在您的回复中这个后果叫做 “乱七八糟”，和“非常令人困惑且难以排查的 bug ”但又不明确是什么 bug 。这样讨论是没有意义的，对社区互相帮助提升技术有害。

[Jirajine]

@iceorange #22 结果“乱七八糟”哪里是主观感觉了，你的程序存在 race condition，运行的结果是不确定的，那就是乱七八糟啊。
同样，这个后果造成的影响就是多数情况正常工作，偶发性的突然出现无法连接、没有回收等各种问题（出现冲突时时运行结果本身就是不明确的）。当然很容易让用户非常困惑并且难以排查（复现）。
又看了下你这个 pid，你的程序可能会使用自己的 pid，也可能会使用目标程序的 pid，当然存在 pid 回收后再次分配导致你的名称冲突，进而因为缺乏原子性造成 race condition 。

当然也不是说没有原子性就一定会有问题，但你需要考虑各种不同的情况，子进程嵌套调用、不同方式调用、僵尸进程、被 kill 后未回收等，这是非常 error prune 的。

[iceorange]

@Jirajine 您开心就好 ：）

[cathedrel]

@gfreezy 看起来很棒，我先点个 star 。
releases 页面的 seeker-0.4.0-x86_64-unknown-linux-musl.tar.gz 这个文件是直接可以在 alpine linux 里运行的文件？

[gfreezy]

@cathedrel musl 打包出来的，普通 Linux 可以执行，没测试 alpine

[cathedrel]

@gfreezy 我在 alpine 里面试了一下，./seeker -h 可以运行，配置文件我该怎么写？“直接使用的 clash 的规则”，clash 我完全不懂。如果想让系统里的所有流量全部走代理，该怎么写？‘'DOMAIN,ALL,PROXY'’？

[gfreezy]

@cathedrel 对。有啥问题可以加 GitHub 页面上的 slack 聊吧。