用Linux做透明代理后Windows网络联接显示不通，但实际是通的

[elfzweik]

最近回国，又需要使用梯子了。两年前弄过透明代理，效果挺好，这次把以前的配置文件找出来，本以为很简单，没想到折腾了3天才弄好。遇到几个以前没遇到过的问题，不知道是不是因为linux从ubuntu 21.04升级到22.04造成的不一样。

1. 在主路由的DHCP指向Linux网关以后，Linux上必须 sudo ip route add default via 192.168.0.1，2年前弄的时候好像没遇到这个问题。
2. Linux网关上需要使用sudo iptables -t nat -I POSTROUTING -j MASQUERADE，否则wifi连接的电脑无法上网。找到这个问题花了好长时间，2年前弄的时候绝对没有遇到过。网上查到这是主路由默认的net.bridge.bridge-nf-call-iptables = 1与旁路由模式不兼容造成的，但问题是我没有更换主路由啊。而且同一型号的另一主路由不加这条命令wifi也能上网。这个问题我没有搞懂，不知有没有大神来解惑。

现在遇到没有解决的问题是，当主路由的DHCP指向Linux网关时，局域网内的windows电脑的wifi连接全部显示为小地球，但实际上不管墙内墙外都是能访问的，Linux、Mac电脑，android、ios设备都没有这个问题。
查了windows判断连网成功的机制，是访问www.msftconnecttest.com/connecttest.txt，如果返回的值与注册表里的ActiveWebProbeContent的值一致，则认为联网成功。不开透明代理的情况下，我的windows电脑访问这个文件，返回的是Microsoft Connect Test，但是Linux电脑返回的是空。所以透明代理以后，windows访问从linux网关发出，返回值也就是空，所以导致windows认为联接不成功。不知道有没有办法解决？
我的config.json和iptalbes-rules设置如下：

{
  "log": {
    "loglevel": "error",
    "error": "/var/log/xray/error.log",
    "access": "/var/log/xray/access.log"
  },
  "inbounds": [
    {
      "tag": "all-in",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"],
        "domainsExcluded": ["mijia cloud"]
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    },
    {
        "listen": "127.0.0.1",
        "port": 10800,
        "protocol": "socks",
        "settings": {
            "auth": "noauth",
            "udp": true,
            "userLevel": 8
        },
        "sniffing": {
            "destOverride": [
                "http",
                "tls"
            ],
            "enabled": true,
            "metadataOnly": false,
            "domainsExcluded": ["mijia cloud"]
        },
        "tag": "socks"
    },
    {
      "tag": "http-in",
      "protocol": "http",
      "listen": "0.0.0.0",
      "port": 10801,
      "sniffing": {
        "enabled": true,
        "destOverride": [ "http", "tls"],
        "domainsExcluded": ["mijia cloud"],
        "metadataOnly": false
      },
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }  
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIPv4"
      },
      "streamSettings": {
        "sockopt": {
          "mark": 2
        }
      }
    },
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "MyDomain",
            "port": 443,
            "users": [
              {
                "id": "MyID",
                "flow": "xtls-rprx-vision",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
	"tlsSettings": {
                    "allowInsecure": false,
                    "fingerprint": "chrome",
                    "serverName": "Mydomain"
                },
        "sockopt": {
          "mark": 2
        }
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "http"
        }
      }
    },
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "address": "8.8.8.8"
      },
      "proxySettings": {
        "tag": "proxy"
      },
      "streamSettings": {
        "sockopt": {
          "mark": 2
        }
      }
    }
  ],
  "dns": {
    "hosts": {
      "Mydomain": "MyIP"
    },
    "servers": [
      {
        "address": "119.29.29.29",
        "port": 53,
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      "8.8.8.8",
      "1.1.1.1",
      "https+local://doh.dns.sb/dns-query"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["all-in"],
        "port": 53,
        "outboundTag": "dns-out"
      },
      {
        "type": "field",
        "ip": ["8.8.8.8", "1.1.1.1"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["geosite:gfw"],
        "outboundTag": "proxy"
      },
      { // BT 流量直连
        "type": "field",
        "protocol":["bittorrent"], 
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["spotify.com","api.weather.com", "apple.com", "icloud.com",  "weather-data.apple.com", "weather-data-origin.apple.com", 
                  "www.msftconnecttest.com", "dns.msftncsi.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:telegram"],
        "outboundTag": "proxy"
      }
    ]
  }
}

# Generated by iptables-save v1.8.7 on Mon May 22 22:34:05 2023
*mangle
:PREROUTING ACCEPT [3031149:4044147344]
:INPUT ACCEPT [4232350:4567759162]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4146622:4303599827]
:POSTROUTING ACCEPT [4146658:4303603221]
:DIVERT - [0:0]
:XRAY - [0:0]
:XRAY_SELF - [0:0]
-A PREROUTING -p tcp -m socket -j DIVERT
-A PREROUTING -j XRAY
-A OUTPUT -j XRAY_SELF
-A DIVERT -j MARK --set-xmark 0x1/0xffffffff
-A DIVERT -j ACCEPT
-A XRAY -d 10.0.0.0/8 -j RETURN
-A XRAY -d 100.64.0.0/10 -j RETURN
-A XRAY -d 127.0.0.0/8 -j RETURN
-A XRAY -d 169.254.0.0/16 -j RETURN
-A XRAY -d 172.16.0.0/12 -j RETURN
-A XRAY -d 192.0.0.0/24 -j RETURN
-A XRAY -d 224.0.0.0/4 -j RETURN
-A XRAY -d 240.0.0.0/4 -j RETURN
-A XRAY -d 255.255.255.255/32 -j RETURN
-A XRAY -d 192.168.0.0/16 -p tcp -m tcp ! --dport 53 -j RETURN
-A XRAY -d 192.168.0.0/16 -p udp -m udp ! --dport 53 -j RETURN
-A XRAY -p tcp -j TPROXY --on-port 12345 --on-ip 0.0.0.0 --tproxy-mark 0x1/0xffffffff
-A XRAY -p udp -j TPROXY --on-port 12345 --on-ip 0.0.0.0 --tproxy-mark 0x1/0xffffffff
-A XRAY_SELF -s 192.168.0.0/16 -p tcp -m tcp --sport 322 -j RETURN
-A XRAY_SELF -d 10.0.0.0/8 -j RETURN
-A XRAY_SELF -d 100.64.0.0/10 -j RETURN
-A XRAY_SELF -d 127.0.0.0/8 -j RETURN
-A XRAY_SELF -d 169.254.0.0/16 -j RETURN
-A XRAY_SELF -d 172.16.0.0/12 -j RETURN
-A XRAY_SELF -d 192.0.0.0/24 -j RETURN
-A XRAY_SELF -d 224.0.0.0/4 -j RETURN
-A XRAY_SELF -d 240.0.0.0/4 -j RETURN
-A XRAY_SELF -d 255.255.255.255/32 -j RETURN
-A XRAY_SELF -d 192.168.0.0/16 -p tcp -m tcp ! --dport 53 -j RETURN
-A XRAY_SELF -d 192.168.0.0/16 -p udp -m udp ! --dport 53 -j RETURN
-A XRAY_SELF -m mark --mark 0x2 -j RETURN
-A XRAY_SELF -p tcp -j MARK --set-xmark 0x1/0xffffffff
-A XRAY_SELF -p udp -j MARK --set-xmark 0x1/0xffffffff
COMMIT
# Completed on Mon May 22 22:34:05 2023

[us254]

I’m not sure why you have added the rule -A XRAY -d 192.168.0.0/16 -p tcp -m tcp ! --dport 53 -j RETURN in your XRAY chain. This rule seems to exclude all TCP packets that are not for port 53 from being redirected to xray. This means that any TCP traffic that is not DNS will bypass xray and go directly to the destination. Is this what you intended? If not, you may want to remove this rule or change it to match only specific ports or addresses that you want to exclude.
I noticed that you have set the mark option to 2 in your streamSettings sockopt for both direct and proxy outbounds in your config.json file. This means that any packets that are sent by xray will have a mark value of 2. However, in your XRAY_SELF chain, you have only added a rule to return packets that have a mark value of 2 and not redirect them to xray. This means that any UDP packets that are sent by xray will still be redirected to xray and cause a loop. To avoid this, you may want to add another rule to return UDP packets that have a mark value of 2 as well, like this: -A XRAY_SELF -p udp -m mark --mark 0x2 -j RETURN

[elfzweik]

Thanks for the reply. The rule -A XRAY -d 192.168.0.0/16 -p tcp -m tcp ! --dport 53 -j RETURN works for TCP traffics destinated to local network. It makes no sense to send these traffics to xray. In fact, ! -- dport 53 can be deleted as DNS traffic is UDP packets.

All the UDP packets will go via routing outbound "DNS-out", and this outbound is also marked 2. Thus your concern of loop will not happen.

[us254]

One way is to modify the hosts file on your Windows computer and add a line like this: 192.168.0.x www.msftconnecttest.com where 192.168.0.x is the IP address of your Linux gateway. This will make your Windows computer send the request to your Linux gateway instead of the real website. Then, on your Linux gateway, you need to create a file named connecttest.txt in the /var/www/html directory and write Microsoft Connect Test in it. This will make your Linux gateway return the expected value to your Windows computer and make it think that the connection is successful.

Another way is to modify the config.json file on your Linux gateway and add a rule in the routing section to bypass the proxy for www.msftconnecttest.com. For example, you can add something like this: { “type”: “field”, “domain”: [“www.msftconnecttest.com”], “outboundTag”: “direct” }. This will make your Linux gateway send the request to the real website without using xray and get the expected value back.

A third way is to disable the active probing feature on your Windows computer by setting the registry value of EnableActiveProbing to 0. You can follow this guide to do that: https://www.thewindowsclub.com/disable-active-probing-in-windows-10. This will make your Windows computer stop checking www.msftconnecttest.com/connecttest.txt and show the correct connection status.

[elfzweik]

As for the first way, I want to use a transparent proxy. It better not to modify the client device.

As for the second way, as you can see from my config.json, the domain has already be added.

 {
        "type": "field",
        "domain": ["spotify.com","api.weather.com", "apple.com", "icloud.com",  "weather-data.apple.com", "weather-data-origin.apple.com", 
                  "www.msftconnecttest.com", "dns.msftncsi.com"],
        "outboundTag": "direct"
      },

The problem I met is that it seems the website judges the type of client. It returns the file connecttest.txt when the client is a Windows device, while empty packet returned for a Linux device. When transparent proxy functions, the request was sent via the the Linux gateway, and consecutively the server returns empty which makes Windows think the connection is broken.

As for the third way, the same as the first way, I am not willing to do modification on clients. By the way, on my Windows 11 Pro 22621.1702, the way to set EnableActiveProbing to 0 does not stop the probing job.

[elfzweik]

神奇的事情发生了，什么都没做，我在电脑前发现Listary不工作（怀疑是因为windows判断未联网的原因），卸载了listary，从task manager里kill掉Liistary进程，然后重装listary。这时，神奇的事情发生了，wifi连接的图标突然正常了。我重启windows，仍然是正常联网的图标，listary也开始工作了。而且把sudo iptables -t nat -I POSTROUTING -j MASQUERADE去掉也可以正常上网了。谁能告诉我是什么情况？不可能是listary的影响吧？完全说不通啊？

[elfzweik]

今天早上开机后，又恢复到小地球状态了。昨晚显示连通的时候，我试了用windows通过透明代理访问www.msftconnecttest.com/connecttest.txt，仍然返回空回复，但是windows显示网络是联通的。而且我重启了几次，都是联通状态。看来windows的判断联通机制还有别的要素，现在看起来跟运营商有关系。但是如果不开透明代理，是能够显示联通的。无法解释啊！

[elfzweik]

找到原因了，是我的config.json写得有问题。