软路由

最近发现clash(mihomo)核心的内存使用率有明显问题，用几天这玩意就能吃200M以上的内存了，再后面就不得不重启。 并且这个核心的DNS性能也存在部分问题，我不得不使用chinadns-ng来代替clash内部的dns. ...

好长时间没写blog了，这段时间暂时没有写代码，一直在倒腾软路由的事情。 不过多亏了软路由，我对网络知识的储备又增加了一些。 这篇文章是想好好讲一下关于Linux上的网络数据包的路由处理. 据我现在所了解到的知识，Linux上决定数据包路由流向的关键模块有两个, 第一个是RPDB(Routing Policy DataBase 路由策略数据库)，第二个是netfilter/iptables，很多人会把netfilter/iptables直接称之为iptables，也没有问题，但是严格上来说还是分开为好，netfilter是内核中的一部分，提供了一组数据包的hook. iptables则是实现了这些hook，并且提供了在用户空间操作这些hook的办法. ...

分流其实我一直有在调整, 从最开始使用ssr默认的PAC规则,到后来使用的clash更加强大的规则集, 最后是现在使用的dae的规则. 我一直使用的是白名单模式的分流, 也就是命中的规则会走直连, 未命中的会走代理. 白名单又有一些问题, 确确实实的折磨到了我. ...

最近不想用Tun了，但是OpenClash的转发也不是全走的TProxy，TCP走Redirect，UDP走TProxy 这次修改一下防火墙来达到两个协议都用TProxy 1 2iptables -t mangle -N clash_tproxy 3 4iptables -t mangle -A clash_tproxy -p udp -m udp --sport 500 -j RETURN 5iptables -t mangle -A clash_tproxy -i lo -j RETURN 6iptables -t mangle -A clash_tproxy -m set --match-set localnetwork dst -j RETURN 7 8iptables -t mangle -A clash_tproxy -p udp -m udp --dport 53 -j RETURN 9 10iptables -t mangle -A clash_tproxy -d 198.18.0.0/16 -p udp -j TPROXY --on-port 7895 --on-ip 0.0.0.0 --tproxy-mark 0x162 11iptables -t mangle -A clash_tproxy -d 198.18.0.0/16 -p tcp -j TPROXY --on-port 7895 --on-ip 0.0.0.0 --tproxy-mark 0x162 12 13iptables -t mangle -A clash_tproxy -p udp -j TPROXY --on-port 7895 --on-ip 0.0.0.0 --tproxy-mark 0x162 14iptables -t mangle -A clash_tproxy -p tcp -j TPROXY --on-port 7895 --on-ip 0.0.0.0 --tproxy-mark 0x162 15 16iptables -t mangle -N clash_tproxy_output 17 18iptables -t mangle -A clash_tproxy_output -p udp -m udp --sport 500 -j RETURN 19iptables -t mangle -A clash_tproxy_output -d 198.18.0.0/16 -p udp -m owner ! --uid-owner 65534 -j MARK --set-xmark 0x162 20iptables -t mangle -A clash_tproxy_output -d 198.18.0.0/16 -p tcp -m owner ! --uid-owner 65534 -j MARK --set-xmark 0x162 21 22iptables -t mangle -A PREROUTING -j clash_tproxy 23iptables -t mangle -A OUTPUT -j clash_tproxy_output 然后修改OpenClash的系统脚本 ...

在OpenWrt社区逛的时候又发现了一些宝贝。 https://github.com/daeuniverse/dae DAE（鹅）又是一个代理程序，不过它是透明代理，可以理解成全局代理，所有流量都会经过该软件。 DAE的特色是使用上了eBPF技术。 eBPF 是 extended Berkeley Packet Filter 的缩写，它是一种内核技术，允许开发人员在不修改内核代码的情况下运行特定的功能。eBPF 的概念源自于 Berkeley Packet Filter（BPF），后者是由贝尔实验室开发的一种网络过滤器，可以捕获和过滤网络数据包。 其实用最简单的话来说就是内核插件技术。 ...

这几天闲来无事, 学习了一些关于iptables的知识, 同时也了解了一下OpenClash在OpenWRT上是怎么对经过网关的流量做透明代理的. 首先是Filter规则, filter是一个专门的流量过滤器, 它是不做任何流量处理的, 只负责拦截. ...

其实在翻SmartDNS文档的时候找到了另一个DNS服务器, 那就是MosDNS. “一个 DNS 转发器” MosDNS官方是这么介绍这个DNS的, 但是实际上我更愿意称它是一个可编程的DNS服务器. MosDNS对比其他DNS服务器不同之处就是它的在请求的逻辑处理能力, 以及分流能力非常优秀. ...

最近发现我的Clash的经常会去重新解析DNS, 导致很多时候网站访问速度变慢. Clash的DNS缓存不是很值得信赖. 所以我又找了一个DNS服务器来做Clash的上游, 比较不错的就是SmartDNS, 具有测速和DNS分组的功能. 可以在不同端口上启动不同组别的DNS, 这个很符合clash的nameserver和fallback的机制. ...

我的软路由上一般只会开两个软件, 一个是Openclash, 还有一个是AdGuardHome. 一般会首先把ADH替换掉dnsmasq, 让DNS请求全部走到ADH这边, 我使用ADH的理由也比较简单, 就是做一个DNS日志, 然后ADH的上游设成Openclash的DNS, 我使用的clash模式是fake-ip 混合模式, UDP走TUN, TCP走直连. 一般就这么用着. fake-ip用了很长时间稳定性也不错, 基本不会遇到什么问题. ...

软路由使用的固件基本已经定型了, 目前使用的Openwrt固件是18.06版本, 内核是5.4 https://github.com/SuLingGG/OpenWrt-Rpi 该项目只维护18.06-5.4k内核版本的OpenWrt, 不过18.06已经停止支持了. 原本18.06使用的内核版本是4.14, 这个固件是一个定制版, 使用的是5.4内核, 我也没有使用过4.14内核, 也不清楚和5.4对比到底如何, 在我目前使用情况来看, 5.4内核还是比较可靠, 目前也没有出现过非常明显的网络波动以及断线的情况. ...