TPROXY: Prevent TCP loopback

[Fangliding]

根据透明代理的原理 它是获取localaddr获得得到地址的 如果有程序出于不知道什么目的直连这个端口那它就会无限尝试自己连自己最后一个请求就把核心打oom
找了一圈没找到什么办法判断一个conn是直连还是来自透明代理模块 目前的方法是检查目标地址是否和监听地址相等 对于监听0000的入站 先检查端口是否相同再用系统调用获得全部本地ip检查目标ip是否等于本地ip(先检查port的原因是syscall比较昂贵)
如果有更好的方法欢迎指出 网上大多数透明代理资料甚至还是ray周边的 甚至是我自己写的文档

[RPRX]

UDP 被你吃了

还有这个能改到 tunnel 入站吗

[RPRX]

想到了 ss-boom，VLESS Encryption 可能也得防一手

[patterniha]

‍it is better put new-codes in dest.IsValid() block, Just in terms of code logic, the results are the same.

this is not off-topic, you can check the code, although the results are the same.

[Fangliding]

UDP 被你吃了

还有这个能改到 tunnel 入站吗

UDP好像出于一些原因没有这个问题(实测)
至于入站 入站好像看不到实际监听的端口 因为结构是 [worker1 worker2 worker...] → inbound(因为inbound允许多个端口存在) → proxy protocol

[RPRX]

不确定这个是否能防 ss-boom 那种，不过不重要，先合了吧

[FDeghy]

This change in the tcpworker.callback function causes the SNI proxy mode in Dokodemo to stop working, because in this mode the dest is equal to the local address. Only after the router performs the dispatch and sniffs the real destination does the actual dest become known. If the goal is to prevent loopback, it should be done after the sniffing has been done and the real destination has been identified.
This is a sample configuration that I used on windows with older versions of Xray. It used to work, but it doesn’t anymore. I had mapped some domains to the IP 127.0.0.1 in the Windows hosts file for this to work.

{
            "listen": "127.0.0.1",
            "port": "443,8443,2096,2053,2083,2087",
            "protocol": "tunnel",
            "settings": {
                "network": "tcp",
                "followRedirect": true
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "tls",
                    "http",
                    "quic"
                ]
            },
            "streamSettings": {
                "sockopt": {
                    "tproxy": "tproxy"
                }
            }
        }

[RPRX]

这下被背刺了，先保持 latest 一天看看有没有更多问题吧

改到 tunnel 入站内应该没啥问题吧，localAddr 判断可能也行？

[Fangliding]

啧 放错地方了

[rldlive]

@FDeghy Hello. I have similar setup as yours and I am still getting the "app/proxyman/inbound: app/proxyman/inbound: loopback connection detected" error after updating to 25.9.11. Same error with 25.9.10. I had to roll back to 25.9.5. Was your issue fixed on the latest version after 30e10be?

[FDeghy]

@rldlive @Fangliding
The same issue still exists after 30e10be, and I’m getting the following error:
app/proxyman/inbound: app/proxyman/inbound: loopback connection detected

[RPRX]

说实话我不知道你们这个是什么 use case，commit tilte 都不知道该写啥

[Fangliding]

啧 搞错了 新旧代码是一样的 都没问题 多刷了一个没意义的commit
出问题是这个用法太奇怪了 这种情况下根本没必要开tproxy吧 你这哪看来的写法

[Fangliding]

说实话我不知道你们这个是什么 use case，commit tilte 都不知道该写啥

一个简单的透明代理配置 带一个private地址直连的路由 直接 curl 127.0.0.1:+端口就炸掉 有人说一些无聊的本地应用可能扫本地端口然后扫到炸掉

[Fangliding]

这种情况下根本没必要开tproxy吧 你这哪看来的写法

重新看了一下甚至是Windows Windows上的tproxy甚至没有意义 理论上应该拒绝启动的 只是史山还是开了起来而已

[RPRX]

不是，我的意思是他们这是什么用法，SNI 分流？

[Fangliding]

任意门进去的tls流量 嗅探系统是可以看到里面的sni的 然后可以加之分流什么的

[RPRX]

开 TPROXY/Redirect 的目的就是为了劫持流量，如果流量原本的目标就是 Tunnel 入站，还开什么 TPROXY

[RPRX]

就很搞笑，看到 SNI proxy mode 我都不知道 Dokodemo 啥时候有这 mode 了后面的我也没看，这 TPROXY 甚至是 Windows

不要乱起名词啊，说个 for SNI proxy/shunt 我都看得懂，一个 mode 说出口给我整不会了

[Fangliding]

洗洗睡吧(

[rldlive]

@Fangliding
Here is my configuration. Actually, it seems to have nothing to do with neither Windows or TPROXY but this PR added the loopback check in the "inbound" part that breaks my use case.

I have an old TV device where it is not possible to install xray-core or anything else but I need this TV to make the connection to "example.com" on port 443 through proxy.
192.168.0.5 is pc on my network that has xray-core installed listening on port 443 and also this PC acts as DNS server (AdGuardHome in my case).
I have set it up so when that TV device and only that device asks for IP address of "example.com" the DNS server returns "fake" address 192.168.0.5
Then the TV device connects to 192.168.0.5:443 where xray-core listens on "inbound". Xray-core "sniffs" the "example.com" SNI, and routes it successfully through the "proxy" outbound.
From TV device point the connection looks transparent and there is no loopback.
This is an old configuration I found a long time ago when I was using v2fly-core instead of xray-core so maybe there is a more "proper" way to achieve my goal. But for now, I had to roll back to 25.9.5

{
  ...
  "inbounds": [
    {
      "listen": "192.168.0.5",
      "port": "443",
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "quic"
        ]
      },
      "tag": "inbound"
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      ...
      "tag": "proxy"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "inboundTag": [
          "inbound"
        ],
        "domains": [
          "domain:example.com"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

These are logs from 25.9.5:

[Info] [2349929967] proxy/dokodemo: received request for 192.168.0.3:42044
[Info] [2349929967] app/dispatcher: sniffed domain: example.com
[Info] [2349929967] app/dispatcher: taking detour [proxy] for [tcp:example.com:443]
[Info] [2349929967] transport/internet/tcp: dialing TCP to tcp:[proxy]:443
[Info] [2349929967] proxy/vless/outbound: tunneling request to tcp:example.com:443 via [proxy]:443

25.9.11 there is only an error repeated multiple times:

[Error] [2348808451] app/proxyman/inbound: app/proxyman/inbound: loopback connection detected
...
[Error] [2942816848] app/proxyman/inbound: app/proxyman/inbound: loopback connection detected

[RPRX]

@rldlive 尝试删除 "followRedirect": true

[rldlive]

@RPRX
Thank you. It works as expected now.

[RPRX]

@Fangliding 要不把这 followRedirect 删了改成自动判断有没有 sockopt tproxy 算了

[patterniha]

followRedirect is also used for MitM

[Fangliding]

本来只是透明代理专用的话应该可以的 现在这么看被动了又不好动了
不过现在这样不会影响mitm 是那人不知道哪抄的配置往里填tproxy才炸的