关于ipts_proxy_dst_port的疑问

[bluehj777]

关于ipts_proxy_dst_port的疑问

[cattyhouse]

你先在 ss-tproxy 本机测试下：

for ((i=0; i<10; ++i)); do
    ssh -p44422 [email protected] 'echo $SSH_CLIENT'
done

想到一块去了...

[cattyhouse]

搞不好他的域名恰好落在 chnlist 里面了也有可能...

[zfl9]

$ curl https://raw.githubusercontent.com/zfl9/ss-tproxy/master/chnlist.txt | fgrep -x cn
cn

是的。

[zfl9]

你是不是 本地代理进程 配置了 分流？

[zfl9]

chnroute 模式时，ss-tproxy show 发来看看

[cattyhouse]

ipts_proxy_dst_port='' # 要代理哪些端口，留空表示全部，多个逗号隔开，冒号表示范围(含边界)，详见 README

楼主似乎用了分号(;)隔开?

[zfl9]

multiport match options:
[!] --source-ports port[,port:port,port...]
 --sports ...
				match source port(s)
[!] --destination-ports port[,port:port,port...]
 --dports ...
				match destination port(s)
[!] --ports port[,port:port,port]
				match both source and destination port(s)

格式似乎错了，多个之间使用,分隔，如果有范围，则使用:连接。

[bluehj777]

ipts_proxy_dst_port='' # 要代理哪些端口，留空表示全部，多个逗号隔开，冒号表示范围(含边界)，详见 README

楼主似乎用了分号(;)隔开?

没有，是书写错误，实际上用得逗号分的 1:10000,40000:50000

[bluehj777]

chnroute 模式时，ss-tproxy show 发来看看

==> iptables-mangle <==
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N SSTP_OUTPUT
-N SSTP_PREROUTING
-N SSTP_RULE
-A PREROUTING -j SSTP_PREROUTING
-A OUTPUT -j SSTP_OUTPUT
-A SSTP_OUTPUT -m addrtype --dst-type LOCAL -j RETURN
-A SSTP_OUTPUT -m conntrack --ctdir REPLY -j RETURN
-A SSTP_OUTPUT -m owner --gid-owner 1001 -j RETURN
-A SSTP_OUTPUT -p udp -m udp --dport 53 -m owner ! --gid-owner 1002 -j RETURN
-A SSTP_OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m multiport --dports 1:10000,40000:50000 -j SSTP_RULE
-A SSTP_OUTPUT -p udp -m conntrack --ctstate NEW,RELATED -m multiport --dports 1:10000,40000:50000 -j SSTP_RULE
-A SSTP_OUTPUT -m connmark --mark 0x2333 -j MARK --set-xmark 0x2333/0xffffffff
-A SSTP_PREROUTING -m addrtype --dst-type LOCAL -j RETURN
-A SSTP_PREROUTING -m conntrack --ctdir REPLY -j RETURN
-A SSTP_PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m addrtype ! --src-type LOCAL -m multiport --dports 1:10000,40000:50000 -j SSTP_RULE
-A SSTP_PREROUTING -p udp -m udp ! --dport 53 -m conntrack --ctstate NEW,RELATED -m addrtype ! --src-type LOCAL -m multiport --dports 1:10000,40000:50000 -j SSTP_RULE
-A SSTP_PREROUTING -p tcp -m connmark --mark 0x2333 -j TPROXY --on-port 60080 --on-ip 127.0.0.1 --tproxy-mark 0x2333/0xffffffff
-A SSTP_PREROUTING -p udp -m connmark --mark 0x2333 -j TPROXY --on-port 60080 --on-ip 127.0.0.1 --tproxy-mark 0x2333/0xffffffff
-A SSTP_RULE -m set --match-set sstp_white dst -m set ! --match-set sstp_black dst -j RETURN
-A SSTP_RULE -j CONNMARK --set-xmark 0x2333/0xffffffff

==> iptables-nat <==
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N SSTP_OUTPUT
-N SSTP_POSTROUTING
-N SSTP_PREROUTING
-N ts-postrouting
-A PREROUTING -j SSTP_PREROUTING
-A OUTPUT -j SSTP_OUTPUT
-A POSTROUTING -j ts-postrouting
-A POSTROUTING -s 192.168.100.0/24 -o tun0 -j MASQUERADE
-A POSTROUTING -j SSTP_POSTROUTING
-A SSTP_OUTPUT -p udp -m udp --dport 53 -m conntrack --ctstate NEW -m owner ! --gid-owner 1001 -m owner ! --gid-owner 1002 -j REDIRECT --to-ports 53
-A SSTP_POSTROUTING ! -s 127.0.0.1/32 -d 127.0.0.1/32 -j SNAT --to-source 127.0.0.1
-A SSTP_PREROUTING -p udp -m udp --dport 53 -m conntrack --ctstate NEW -m addrtype ! --src-type LOCAL -j REDIRECT --to-ports 53
-A ts-postrouting -m mark --mark 0x40000/0xff0000 -j MASQUERADE

[bluehj777]

你是不是 本地代理进程 配置了 分流？

本地代理的xray或v2ray 没做分流，很干净，但是出口路由IKUAI因为多线，做了多线负载，有规则是电信默认路由，联通走联通。

[cattyhouse]

ipts_proxy_dst_port='' # 要代理哪些端口，留空表示全部，多个逗号隔开，冒号表示范围(含边界)，详见 README

楼主似乎用了分号(;)隔开?

没有，是书写错误，实际上用得逗号分的 1:10000,40000:50000

那么建议 ssh 进去后, 用 echo "$SSH_CONNECTION" 查看 source ip. 因为 netstat 可能显示之前的旧的没有关闭的链接, 另外服务器那边最好不要用 tmux 之类的 (会显示旧的信息, 非常罕见的case)

[zfl9]

怎么连接 ssh 服务器的，ip 还是 域名？

[bluehj777]

echo "$SSH_CONNECTION"

域名

[zfl9]

sshd 服务器有多个 ip ?

[bluehj777]

sshd 服务器有多个 ip ?

sshd 单IP

[zfl9]

你先在 ss-tproxy 本机测试下：

for ((i=0; i<10; ++i)); do
    ssh -p44422 [email protected] 'echo $SSH_CLIENT'
done

[cattyhouse]

做这个测试:

1. 现有规则不变: 1:10000,40000:50000
2. 在客户端的机器上运行 : for i in 1 2 3 4 5 6 7 8 9 ; do ssh USER@VPS_SERVER_DOMAIN -p 44422 'echo "$SSH_CLIENT"' ; done

[bluehj777]

ipts_proxy_dst_port='' # 要代理哪些端口，留空表示全部，多个逗号隔开，冒号表示范围(含边界)，详见 README

楼主似乎用了分号(;)隔开?

没有，是书写错误，实际上用得逗号分的 1:10000,40000:50000

那么建议 ssh 进去后, 用 echo "$SSH_CONNECTION" 查看 source ip. 因为 netstat 可能显示之前的旧的没有关闭的链接, 另外服务器那边最好不要用 tmux 之类的 (会显示旧的信息, 非常罕见的case)
echo "$SSH_CONNECTION 看也是一样
服务器那边 是XRAY ，最近是调过配置，做过分流 但只是针对NF和OPENAI的

{
  "log": {
    "access": "/var/log/v2ray_access.log",
    "error": "/var/log/v2ray_error.log",
    "loglevel": "none"
  },
  "inbounds": [
    {
      "port": XXXX
      "protocol": "vmess",
      "listen": "0.0.0.0",
      "settings": {
        "udp": true,
        "clients": [
          {
            "id": "xxxxxxxxxxxx-XXXX",
            "security": "auto",
            "alterId": 100
          }
        ]
      }
    },
    {
      "port": 443,
      "protocol": "vless",
      "listen": "0.0.0.0",
      "settings": {
        "udp": true,
        "clients": [
          {
            "id": "XXX--523-",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "dest": "www.xxxx:443",
          "xver": 0,
          "serverNames": [
            "www.gov.hk"
          ],
          "privateKey": "xxxxxxxxxxxxxUNxxxx1E",
          "publicKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
          "maxTimeDiff": 0,
          "shortIds": [
            ""
          ]
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "NFUNLOCK",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "server1",
            "port": xxxx,
            "users": [
              {
                "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
                "security": "none"
              }
            ]
          }
        ]
      }
    },
    {
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "OPENAI",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "serverB",
            "port": xxxxx,
            "users": [
              {
                "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
                "security": "none",
                "alterId": 0
              }
            ]
          }
        ]
      }
    },
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "block"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:cloudflare"
        ],
        "outboundTag": "OPENAI"
      },
      {
        "type": "field",
        "domain": [
          "geosite:openai",
          "bard.google.com"
        ],
        "outboundTag": "OPENAI"
      },
      {
        "type": "field",
        "domain": [
          "geosite:netflix"
        ],
        "outboundTag": "NFUNLOCK"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "block"
      }
    ]
  }
}

[bluehj777]

你先在 ss-tproxy 本机测试下：

for ((i=0; i<10; ++i)); do
    ssh -p44422 [email protected] 'echo $SSH_CLIENT'
done

123.172.xx.xx 48172 44422
123.172.xx.xx 53634 44422
123.172.xx.xx 53644 44422
123.172.xx.xx 53646 44422
123.172.xx.xx 53662 44422
123.172.xx.xx 36902 44422
123.172.xx.xx 36910 44422
123.172.xx.xx 36912 44422
123.172.xx.xx 36922 44422
123.172.xx.xx 36938 44422
直连的IP

[bluehj777]

有时候ss-tproxy stop 再ss-tproxy start 被代理的几率就大，但是在做几个SSH过去，就一直是直连的了

[cattyhouse]

有时候ss-tproxy stop 再ss-tproxy start 被代理的几率就大，但是在做几个SSH过去，就一直是直连的了

把你的域名加入 gfwlist.ext 里面呢 ?

[zfl9]

检查你的sshd服务器ip是否在ipset里面：

ipset test sstp_white sshd服务器ip
ipset test sstp_black sshd服务器ip

[bluehj777]

有时候ss-tproxy stop 再ss-tproxy start 被代理的几率就大，但是在做几个SSH过去，就一直是直连的了
平时用HTTPS/HTTP连接多，分流也一直正常，就没在意。最近SSH到国外，发现这个问题。但是好久以前记忆中SSH是没问题的

[bluehj777]

检查你的sshd服务器ip是否在ipset里面：

ipset test sstp_white sshd服务器ip
ipset test sstp_black sshd服务器ip

is in set sstp_white.
is NOT in set sstp_black.

[zfl9]

检查你的sshd服务器ip是否在ipset里面：

ipset test sstp_white sshd服务器ip
ipset test sstp_black sshd服务器ip

is in set sstp_white. is NOT in set sstp_black.

这肯定走直连（因为在 ip 白名单里面）

[zfl9]

你把 sshd 服务器的域名加到了 ignlist.ext ？

[zfl9]

有时候ss-tproxy stop 再ss-tproxy start 被代理的几率就大，但是在做几个SSH过去，就一直是直连的了

那我可以猜测到发生什么了，restart 时被代理的几率大，那是因为客户机有 dns 缓存吧，所以 ss-tproxy 主机没有收到来自客户机的 dns 解析请求（针对 sshd 域名），这时候你 ssh 上去就是走代理（我假设你的 sshd 服务器在国外，而又因为 chnroute 模式，所以）。

然后后面再多做几次 ssh 连接，可能客户机就会进行 dns 解析了，这时候经过 ss-tproxy 的 dnsmasq/chinadns-ng，如果你的域名在 chnlist.txt/ignlist.ext 里面，那么解析出来的 ip 就被加入到 sstp_white 白名单，于是这次和后续就走直连了。

[cattyhouse]

假设你的域名是 aaa.bbb.ccc.ddd, 取最后2个段 'ccc.ddd' 然后

cd ss-tproxy ; grep -R 'ccc.ddd'

[bluehj777]

你把 sshd 服务器的域名加到了 ignlist.ext ？
无效。不应该加入黑名单gfwlist.ext里吗？

[zfl9]

你把 sshd 服务器的域名加到了 ignlist.ext ？
无效。不应该加入黑名单gfwlist.ext里吗？

我想你误会我的意思，我是说，你不能将 sshd 服务器的域名，加入到 ignlist.ext。

如果你没有这么做，那么将你的域名加入到 gfwlist.ext 就好了。因为默认 gfwlist 优先。

[bluehj777]

搞不好他的域名恰好落在 chnlist 里面了也有可能...

我一个个人域名怎么会被落在里面？

[zfl9]

搞不好他的域名恰好落在 chnlist 里面了也有可能...

我一个个人域名怎么会被落在里面？

这个难说，我的域名都在里面 😂

[cattyhouse]

搞不好他的域名恰好落在 chnlist 里面了也有可能...

我一个个人域名怎么会被落在里面？

有可能呀, 我们也不知道你的域名是什么, 假如是个二级域名... 是有可能落在里面的, 所以你要按照上面的那个建议去 grep 一下

[bluehj777]

搞不好他的域名恰好落在 chnlist 里面了也有可能...

我一个个人域名怎么会被落在里面？

有可能呀, 我们也不知道你的域名是什么, 假如是个二级域名... 是有可能落在里面的, 所以你要按照上面的那个建议去 grep 一下

做了，没在的

[zfl9]

那就加入 gfwlist.ext，问题应该就解决了。

[zfl9]

有个验证的办法，先确保此时没有人通过 ss-tproxy 访问 sshd 服务器

• 执行 ss-tproxy restart
• 进行 ipset test 测试（就是上面发你的那个）
• 在 ss-tproxy 主机（客户机也行，但不一定能触发dns解析，因为客户机可能有dns缓存）执行 ssh 测试（echo $SSH_CLIENT）
• 再次执行 ipset test 测试，如果结果与 restart 后测试的不同，说明你的域名在 chnlist.txt/ignlist.ext。另外你也可以打开 chinadns-ng 的 log，搜索你的域名解析日志，如果是 tag:chn，那么也能说明在 chnlist.txt/ignlist.ext 里面。

[bluehj777]

那就加入 gfwlist.ext，问题应该就解决了。
嗯，是解决了。
问题的根源是客户机有 dns 缓存？

[zfl9]

我能想到有两种原因，具体要你自己确认。

• 你的域名被判定为了 tag:chn，也就是说你的域名在 chnlist.txt 或 ignlist.ext 中
• 你的服务器 ip 在 chnroute 路由表，检查 chnroute.txt（可使用 ipset test 测试，在排除干扰的情况下）

根据你的描述，我觉得第一种可能性大。

[zfl9]

有个验证的办法，先确保此时没有人通过 ss-tproxy 访问 sshd 服务器

• 执行 ss-tproxy restart
• 进行 ipset test 测试（就是上面发你的那个）
• 在 ss-tproxy 主机（客户机也行，但不一定能触发dns解析，因为客户机可能有dns缓存）执行 ssh 测试（echo $SSH_CLIENT）
• 再次执行 ipset test 测试，如果结果与 restart 后测试的不同，说明你的域名在 chnlist.txt/ignlist.ext。另外你也可以打开 chinadns-ng 的 log，搜索你的域名解析日志，如果是 tag:chn，那么也能说明在 chnlist.txt/ignlist.ext 里面。

你只要执行这个测试，把两次 ipset test 的结果发出来，我也能帮你推测原因。

[bluehj777]

啊，想明白了应该是第一种，才醒悟我的域名是.cn的！chnlist.txt标记所有.cn的对吧

[bluehj777]

啊，想明白了应该是第一种，才醒悟我的域名是.cn的！chnlist.txt标记所有.cn的对吧

之所以很久以前没有这个问题，是当时ss-tproxy是要把代理地址填写到conf里的，也就是强制加入黑名单的。