[Question] TUN模式下，clash 转发TCP握手失败

[Ret70]

Verify steps

• [X] 如果你可以自己 debug 并解决的话，提交 PR 吧 Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.
• [X] 我已经在 Issue Tracker 中找过我要提出的问题 I have searched on the issue tracker for a related issue.
• [X] 我已经使用 dev 分支版本测试过，问题依旧存在 I have tested using the dev branch, and the issue still exists.
• [X] 我已经仔细看过 Documentation 并无法自行解决问题 I have read the documentation and was unable to solve the issue.
• [X] 这是 Clash 核心的问题，并非我所使用的 Clash 衍生版本（如 OpenClash、KoolClash 等）的特定问题 This is an issue of the Clash core per se, not to the derivatives of Clash, like OpenClash or KoolClash.

Clash version

Premium 2022.06.19

What OS are you seeing the problem on?

Linux

Clash config

tun:
  enable: true
  stack: system
  auto-route: true # auto set global route
  auto-detect-interface: true # conflict with interface-name

dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:53
  enhanced-mode: redir-host
  default-nameserver:
    - 192.168.1.1
  nameserver:
    - 192.168.1.1
  fallback:
    - tls://8.8.8.8:853
    - tls://8.8.4.4:853
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

Clash log

No response

Description

网络环境：外网——>路由器(192.168.1.1)——>旁路由debian-clash直装(192.168.1.2)——>服务器(192.168.1.100)

现在服务器有一个web服务，通过路由器端口转发，在外网进行访问。 由于所有内网设备网关均是clash，实现全局clash流量分发

路由器端口转发配置 公网IP:8443 -> 192.168.1.2:8443，将路由器8443端口进来的数据转发到clash 然后在clash主机对nftables进行配置，将clash 8443端口的流量直接转发到服务器的443端口。

table ip nat {
        chain prerouting {
                type nat hook prerouting priority -100; policy accept;
                tcp dport { 8443 } log prefix "nat-pre tcp " dnat 192.168.1.100:443
        }
}

此上配置，在未使用tun模式的redir-host模式下，外网能正常访问该服务器的WEB服务，成功建立TCP连接。

————————————

当换成TUN模式后（redir-host） 以上配置则无法正常访问

尝试在nftables里将8443端口的流量在此直接return掉，再次尝试，仍然无法在浏览器端收到tcp的ACK包，无法建立连接 nftables配置：

table ip mangle {
        chain prerouting {
                type filter hook prerouting priority 0; policy accept;
                tcp sport { 8443 } log prefix "mangle-pre tcp " return
        }
}

table ip nat {
        chain prerouting {
                type nat hook prerouting priority -100; policy accept;
                tcp dport { 8443 } log prefix "nat-pre tcp " dnat 192.168.1.100:443
        }
} 

输出日志显示，SYN包已经成功转发到WEB服务，并且发送回了ACK包，但是ACK包并没有被成功送回。无论是return还是放行，都没有送到。 还有一点很奇怪的是，我并没有使用fake-ip模式，但是utun 网卡 里的流量似乎都是在fake-ip中传递？ 不知道为什么使用TUN模式，无法正常将ack包成功传出去？

00:03:05 nat-pre tcp IN=eno1 OUT= MAC=11:22:33:df:db:44:33:22:55:a6:88:23:08:00 SRC=172.70.23.232 DST=192.168.1.2 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=31474 DF PROTO=TCP SPT=43436 DPT=8443 WINDOW=65535 RES=0x00 SYN URGP=0
00:03:05 mangle-pre tcp IN=utun OUT= MAC= SRC=198.18.5.229 DST=198.18.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=8443 DPT=7777 WINDOW=64240 RES=0x00 ACK SYN URGP=0
00:03:06 nat-pre tcp IN=eno1 OUT= MAC=11:22:33:df:db:44:33:22:55:a6:88:23:08:00 SRC=172.70.23.232 DST=192.168.1.2 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=31475 DF PROTO=TCP SPT=43436 DPT=8443 WINDOW=65535 RES=0x00 SYN URGP=0
00:03:06 mangle-pre tcp IN=utun OUT= MAC= SRC=198.18.5.229 DST=198.18.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=8443 DPT=7777 WINDOW=64240 RES=0x00 ACK SYN URGP=0
00:03:08 nat-pre tcp IN=eno1 OUT= MAC=11:22:33:df:db:44:33:22:55:a6:88:23:08:00 SRC=172.70.23.232 DST=192.168.1.2 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=31476 DF PROTO=TCP SPT=43436 DPT=8443 WINDOW=65535 RES=0x00 SYN URGP=0
00:03:08 mangle-pre tcp IN=utun OUT= MAC= SRC=198.18.5.229 DST=198.18.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=8443 DPT=7777 WINDOW=64240 RES=0x00 ACK SYN URGP=0
00:03:12 nat-pre tcp IN=eno1 OUT= MAC=11:22:33:df:db:44:33:22:55:a6:88:23:08:00 SRC=172.70.23.232 DST=192.168.1.2 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=31477 DF PROTO=TCP SPT=43436 DPT=8443 WINDOW=65535 RES=0x00 SYN URGP=0
00:03:12 mangle-pre tcp IN=utun OUT= MAC= SRC=198.18.5.229 DST=198.18.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=8443 DPT=7777 WINDOW=64240 RES=0x00 ACK SYN URGP=0
00:03:21 nat-pre tcp IN=eno1 OUT= MAC=11:22:33:df:db:44:33:22:55:a6:88:23:08:00 SRC=172.70.23.206 DST=192.168.1.2 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=23794 DF PROTO=TCP SPT=17724 DPT=8443 WINDOW=65535 RES=0x00 SYN URGP=0
00:03:21 mangle-pre tcp IN=utun OUT= MAC= SRC=198.18.5.229 DST=198.18.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=8443 DPT=7777 WINDOW=64240 RES=0x00 ACK SYN URGP=0
00:03:28 nat-pre tcp IN=eno1 OUT= MAC=11:22:33:df:db:44:33:22:55:a6:88:23:08:00 SRC=172.70.23.206 DST=192.168.1.2 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=23797 DF PROTO=TCP SPT=17724 DPT=8443 WINDOW=65535 RES=0x00 SYN URGP=0
00:03:28 mangle-pre tcp IN=utun OUT= MAC= SRC=198.18.5.229 DST=198.18.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=8443 DPT=7777 WINDOW=64240 RES=0x00 ACK SYN URGP=0

另外我尝试了端口直接转发到目标服务器的web服务上，只是在clash上的nft把mangle表里收到的包return，仍然失败。 还有就是fake-ip模式也尝试过，也是一样的结果。

[Victor2333]

tcp我没碰到问题 udp端口转发流量不知道为什么走了clash

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days