包的路由转圈圈——谈谈使用nftable配置透明代理碰到的那些坑 | KosWu 's blog

[Koswu]

https://koswu.github.io/2019/08/19/tproxy-config-with-nftables/

透明代理，可以使得在代理后面的所有流量都经过代理，而发出流量的软件本身并不知道代理的存在。但网上大多配置教程都以iptables为主，由于本人用的是nftables，就尝试依葫芦画瓢搞了一个，同时也大概弄清除了其中的原理，供参考。

[overcache]

在output链上对tcp包进行了重定向，不会死循环吗？

[Koswu]

@overcache 在output链上对tcp包进行了重定向，不会死循环吗？

不会的，因为里面有一个重定向白名单，重定向一次以后会变成白名单里的ip

[overcache]

另外, 我的代理软件是 v2ray, 使用 tproxy 来处理 tcp+udp. 如果没有添加对应的路由, 网络是不通的. 所以

ip rule add fwmark 0x233 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

应该是和 tproxy 配套使用的, 虽然我也不懂 tproxy 的具体原理

[overcache]

@Koswu

@overcache 在output链上对tcp包进行了重定向，不会死循环吗？

不会的，因为里面有一个重定向白名单，重定向一次以后会变成白名单里的ip

我明白你的意思了, 经过 ss-redir 处理的包, 目的地址都是 vps_ip, 这个 ip 是白名单.

我用的是 v2ray , 经过它处理的数据包, 不是全部通过代理发出去的, 情形不一样所以不能在 output 上做这个操作

[Koswu]

@overcache

@Koswu

@overcache 在output链上对tcp包进行了重定向，不会死循环吗？

不会的，因为里面有一个重定向白名单，重定向一次以后会变成白名单里的ip

我明白你的意思了, 经过 ss-redir 处理的包, 目的地址都是 vps_ip, 这个 ip 是白名单.

我用的是 v2ray , 经过它处理的数据包, 不是全部通过代理发出去的, 情形不一样所以不能在 output 上做这个操作

处理以后不一定通过代理发出去，是指特定ip直连？那只要和v2ray维护同样的ip段就行了吧

[LinaChong]

你好，我想请问一下你的代理（我的是v2ray）和nftables是怎么配置的。 我使用redirect的话可以正常工作， 但tproxy不行，v2ray的访问日志完全没有看到。 nftables里的counter有增加。 附nftables配置：

table inet nat {
    chain prerouting {
        type filter hook prerouting priority mangle; policy accept;
        goto proxy
    }

    chain proxy {

        ip daddr $private_list return
        ip6 daddr {::1/128, fc00::/7, fe80::/10} return

        mark 255 return
        mark 1 return

        tcp dport != 53 redirect to :12345 #这行, 使用redirect正常工作
        #tcp dport != 53 counter tproxy to :12345 meta mark set 1 accept#使用redirect客户端除局域网请求都会超时.

    }
}

v2ray:

        {
            "tag": "transparent",
            "port": 12345,
            "protocol": "dokodemo-door",
            "settings": {
                "userLevel": 0,
                "network": "tcp,udp",
                "timeout": 30,
                "followRedirect": true
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls"
                ]
            },
            "streamSettings": {
                "sockopt": {
                    "tproxy": "tproxy" // 透明代理使用 TPROXY 方式
                }
            }
        },
        {
            "tag": "httpIn",
            "port": 1081,
            "protocol": "http",
            "settings": {
                "auth": "noauth"
            }
        },
        {
            "port": 30000,
            "protocol": "socks",
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls"
                ]
            },
            "settings": {
                "auth": "noauth",
                "udp": true
            },
            "streamSettings": null
        }
    ],
    "outbounds": [
        {
            "tag": "ssr",
            "protocol": "socks",
            "settings": {
                "servers": [
                    {
                        "address": "::1",
                        "port": 30001
                    }
                ],
                "streamSettings": {
                    "sockopt": {
                        "mark": 255
                    }
                }
            }
        },
        {
            "tag": "direct",
            "protocol": "freedom",
            "settings": {
                "streamSettings": {
                    "sockopt": {
                        "mark": 255
                    }
                }
            }
        },
        {
            "tag": "adblock",
            "protocol": "blackhole",
            "settings": {}
        }
    ],

[Koswu]

@LinaChong 不好意思现在才看到

我自己配置的时候，TCP是走的redirect，udp才用了tproxy

我看了一下你的配置，似乎你在prerouting链中给数据包打了标记

tcp dport != 53 counter tproxy to :12345 meta mark set 1 accept

这会导致数据包的重新路由，结果就是你的数据包一直在循环路由导致超时了

我上面打标记是因为tproxy没法在output链使用，所以打个标记可以重新路由到prerouting链

[overcache]

再次拜读，nftables+透明代理，怎么都会搜到这里来。 这次关于udp的部分，有新的疑问： set mark 之后的包会reroute，然后经过代理处理，处理完之后这个包不会重新被output链处理然后死循环吗

[Koswu]

@overcache 再次拜读，nftables+透明代理，怎么都会搜到这里来。 这次关于udp的部分，有新的疑问： set mark 之后的包会reroute，然后经过代理处理，处理完之后这个包不会重新被output链处理然后死循环吗

不会的，由于reroute以后，改写了目的IP为127.0.0.1，这个IP在whitelist里面，output链中会直接return

[overcache]

@Koswu

@overcache 再次拜读，nftables+透明代理，怎么都会搜到这里来。 这次关于udp的部分，有新的疑问： set mark 之后的包会reroute，然后经过代理处理，处理完之后这个包不会重新被output链处理然后死循环吗

不会的，由于reroute以后，改写了目的IP为127.0.0.1，这个IP在whitelist里面，output链中会直接return

我正好有这个疑问, 打日志发现 DST 地址确实变成了 127.0.0.1. 既然命中了白名单, 那 chain prerouting 中 tproxy 的规则就没机会执行了. ip daddr @whitelistset return ip protocol udp tproxy to 127.0.0.1:PROXY_PORT

没执行 tproxy to, 代理软件就不能拿到包的内容进行代理了吧?

[CCint3]

@overcache

@Koswu

@overcache 再次拜读，nftables+透明代理，怎么都会搜到这里来。 这次关于udp的部分，有新的疑问： set mark 之后的包会reroute，然后经过代理处理，处理完之后这个包不会重新被output链处理然后死循环吗

不会的，由于reroute以后，改写了目的IP为127.0.0.1，这个IP在whitelist里面，output链中会直接return

我正好有这个疑问, 打日志发现 DST 地址确实变成了 127.0.0.1. 既然命中了白名单, 那 chain prerouting 中 tproxy 的规则就没机会执行了. ip daddr @whitelistset return ip protocol udp tproxy to 127.0.0.1:PROXY_PORT

没执行 tproxy to, 代理软件就不能拿到包的内容进行代理了吧?

请问如何打印日志?