在负责NAT的OpenWrt上使用tun中的auto-route和auto-redir会让原有防火墙规则失效

[Mosney]

操作系统

Linux

系统版本

OpenWrt 23.05.3 内核版本5.15.150

安装类型

sing-box 原始命令行程序

如果您使用图形客户端程序，请提供该程序版本。

No response

版本

root in ~ λ sing-box version             
sing-box version 1.10.0-beta.11

Environment: go1.23.1 linux/amd64
Tags: with_gvisor,with_quic,with_dhcp,with_wireguard,with_ech,with_utls,with_reality_server,with_acme,with_clash_api
Revision: 19295f651b13ea1b811c6894409b5e0077c4d349
CGO: disabled

描述

在负责NAT的OpenWrt上使用sing-box做透明网关代理，会导致原本设置的路由规则（包括通信规则和端口转发）失效。
似乎是sing-box一刀切接管了所有接口流量导致的，具体原理迫于nft/iptables苦手整不清楚。

据我观察openclash的解决方法是通过init.d运行脚本，在启动前获取OpenWrt的防火墙配置，去做额外的规则RETURN跳过打标进行规避。
跟sing-box有一点不同的是openclash中将流量重定向到clash内核是启动脚本实现的，而非像sing-box一样auto-redir。
从命名推测是在firewall_redirect_exclude和firewall_rule_exclude这两个函数中实现的。

如果网关和NAT分离在两个host，sing-box只在网关上运行就不需要考虑防火墙，sing-box无疑是目前最易于使用的透明网关代理实现。

虽然严格来说这并不是sing-box的问题，但还是希望在NAT的OpenWrt上也可以简单地开启网关代理。
突然想到这种OS特化的适配好像更应该通过特定的软件包，例如[luci-app-]sing-box，在init.d启动脚本中实现。

重现方式

/usr/bin/sing-box run -c /etc/sing-box/config.json -D /usr/share/sing-box

以下是删除了无关项目的配置文件/etc/sing-box/config.json

{
  "inbounds": [
    {
      "type": "mixed",
      "tag": "mixed-in",
      "listen": "::",
      "listen_port": 8888
    },
    {
      "type": "direct",
      "tag": "dns-in",
      "listen": "::",
      "listen_port": 5053
    },
    {
      "type": "tun",
      "tag": "tun-in",
      "interface_name": "tunsb",
      "mtu": 9000,
      "gso": false,
      "address": "172.18.0.1/24",
      "auto_route": true,
      "auto_redirect": true,
      "strict_route": false,
      "route_address": [
        "0.0.0.0/1",
        "128.0.0.0/1",
        "::/1",
        "8000::/1"
      ],
      "route_exclude_address": [
        "10.0.0.0/8",
        "172.16.0.0/24",
        "192.168.0.0/16",
        "fc00::/7"
      ],
      "sniff": true,
      "sniff_override_destination": true
    }
  ],
  "route": {
    "final": "FINAL",
    "auto_detect_interface": true
  },
  "experimental": {
    "cache_file": {
      "enabled": true
    }
  }
}

日志

N/A sing-box可以按预期正常运行，因此sing-box日志就不贴了

支持我们

• 我已经 赞助

完整性要求

• 我保证阅读了文档，了解所有我编写的配置文件项的含义，而不是大量堆砌看似有用的选项或默认值。
• 我保证提供了可以在本地重现该问题的服务器、客户端配置文件与流程，而不是一个脱敏的复杂客户端配置文件。
• 我保证提供了可用于重现我报告的错误的最简配置，而不是依赖远程服务器、TUN、图形界面客户端或者其他闭源软件。
• 我保证提供了完整的配置文件与日志，而不是出于对自身智力的自信而仅提供了部分认为有用的部分。

[nekohasekai]

试试 0ef4f80

[Mosney]

试试 0ef4f80

感动，这么快就patch了。但是我目前暂时没有测试条件，只好蹲一个有缘人或者等我回家了

看起来改动不大，要是能合并到某个带预编译的分支就好了，不仅是nft苦手更是编译苦手🥲

[nekohasekai]

看起来改动不大，要是能合并到某个带预编译的分支就好了，不仅是nft苦手更是编译苦手🥲

GOOS=linux GOARCH=arm64 make

[Mosney]

试试 0ef4f80

试了一下，问题依旧。

测试用例是从公网连接运行在OpenWrt的wg(wireguard)，运行sing-box后wg不能成功握手，客户端侧只有发送流量，没有接收流量。关掉sing-box后立刻握手成功，VPN通信正常。推测是如之前所述sing-box使开放wg端口的防火墙规则失效导致的。

使用的sing-box是以beta.12为基础patch上述commit后自编译的版本

sing-box version 1.10.0-beta.12

Environment: go1.23.2 linux/arm64
Tags: with_gvisor,with_dhcp,with_wireguard,with_reality_server,with_clash_api,with_quic,with_utls,with_ech
Revision: e68a9e623f09840552554ea15e4973b668a9d648
CGO: disabled

[Mosney]

update:

wg测试用例的推测不完整，似乎不是防火墙的入站规则失效，更像是出站数据包被过滤掉。

理由是开启sing-box的情况下，尝试从公网连接wg，可以看到wg0接口会有随时间步进为1的数据包计数增长，疑似是在尝试握手。

其它条件不变，使用release的1.10.1版本复现现象一致，因此 0ef4f80 似乎没有解决问题

[Mosney]

依然通过wirguard测试，开启sing-box后依然可以通过wan进入的wg0接口IPv6地址成功连接wireguard，使用wan的IPv4地址连接会因为开启sing-box而失败，因此推断防火墙的IPv6规则不受影响。

@nekohasekai 有时间的话帮忙看一下，之前 0ef4f80 试过了并不能解决问题