Silver

Lasciate ogni speranza, voi ch'entrate.
(Abandon hope, all ye who enter here.)
- Dante

TPROXY's different behavior in different kernel

Last updated:Jan.16, 2023 CST 01:30:46

Q: 某代理软件如果不关闭tproxy,重启软件会断网。是不是应该让代理软件接管对防火墙的修改操作?

A: 摘录聊天记录如下

silver:
tproxy这个其实还是防火墙。。。防火墙这个就tm麻烦了

你看你有iptables,还有nft

然后iptables还有iptables-legacy和iptables-netfilter

用户机器上有可能是个iptables-legacy的binary,但他内核实现是netfilter的

也有可能用户机器上既有nft 又有iptables-netfilter,然后他两个都配了规则(

如果是nft,有可能用户同时配了table ip/table ip6/table inet

tl; dr: linux firewall is messy

群友提到其他软件的用户会使用Namespace解决这个问题,这样就不需要改防火墙了,进程死掉的时候顺便也删掉规则。但:

silver: 

exactly but如果想跑在路由器上,那对应版本的内核有没有namespace

uname -a: linux 2.6.32

gg

所以我觉得你的问题其实是在挂掉的时候怎么优雅处理tproxy

于是吃了个晚饭后翻源码:

silver:
调研了下,这个case是这样的。
Linux <=3.x的版本,这个功能只有一个实现,也就是xftables项目的xt_TPROXY.c
=4.x的版本,因为nftables也来了,所以有两个实现,nft_tproxy.c和xt_TPROXY.c
>=5.x的版本,xftables彻底被干掉了,就剩下nftables的实现了。
所以在一个4.x的内核上你就能体验到两种不同实现的差异。如果tproxy重定向到的那个端口上没有一个listening socket:
- 如果走了nftables的实现,那么规则无效,继续执行其他规则,换句话说网络是正常的: https://elixir.bootlin.com/linux/v4.19/source/net/netfilter/nft_tproxy.c#L143
- 如果走的是xftables的老实现,那么丢包: https://elixir.bootlin.com/linux/v4.19/source/net/netfilter/xt_TPROXY.c#L184

我搞了个测试环境复现了下,换句话说你必须用nftables,不能用iptables-nat(iptables-nat出于兼容性还是用了xftables的实现),也不能用iptables-legacy,这样就算tproxy背后的socket没了,网络也正常

so tl; dr: blame upstream

群乌贼:
草

silver: 
讲道理你想tproxy就是把一个应该丢到网络设备的包丢到了socket上(

所以socket没了内核肯定是知道的(

所以肯定内核做了什么操作才会丢包(

群友A:
云理解就是做没做的问题 吧(

silver:
对,老内核就是看到socket不存在就丢包,新内核就是看到socket不存在就当这条规则不存在,继续执行下一跳规则

所以如果你用4.x的话,用nft写规则;或者你用5.x+的内核就好了

当然这个事情解法很多。用tun/tap device结合路由规则就不需要考虑tproxy的问题,但涉及到策略路由,有一定门槛,而且对应用实现的速度要求就比较高了。

Per-device去分发PAC也可以,但这个操作不保险。

或者说在路由层面通过两个路由(有点像是所谓的旁路由方案),但依然折腾。

可能在一个不能直接互联的网里,这种事情就是无法避免的吧。我大多数的网络知识都来自于这种攻防对抗,但我并不会因此而感谢这种对抗。

Contact webmaster at:
[email protected]