关于ipts_proxy_dst_port的疑问

bluehj777 commented 11 months ago

说明里，这个要代理的端口表现出很随机性。也是最近才发现。global下到时没问题

模式选择chnroute 反复用SSH 客户端登录一个国外IP的sshd port 44422 ，然后发现被代理的很随机，大部分都是被直连过去了

ss-tproxy.conf 里的ipts_proxy_dst_port 留空和指定 1-1000;40000-50000都试了

还经常出现第一个连接被代理了，再开第二个连接就又被直连了。确认是否被直连了，是在国外IP的这个机器上用netstat -natlup | grep 44422看连接的IP是哪个

================================================================================== ipts_proxy_dst_port 要代理黑名单的哪些端口，留空表示全部，等价于 1:65535。允许指定多个范围，逗号隔开即可。

如果觉得端口范围太大，可以设置为 1:1023,8080；此时，只有当我们访问黑名单的 1~1023 和 8080 端口时才会走代理，访问其它端口不走代理，因此可以利用此选项来放行 BT、PT 流量，因为这些流量的目的端口通常在 1024 以上。

修改此选项需要足够小心，配置不当会导致某些软件无法走代理，因为它们访问的目标端口可能不在你指定的范围内；因此将此选项留空，可能是最保险的一种做法，防止出现漏网之鱼。

zfl9 commented 11 months ago

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

zfl9 commented 11 months ago

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

cattyhouse commented 11 months ago

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

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

zfl9 commented 11 months ago

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 commented 11 months ago

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

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

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

bluehj777 commented 11 months ago

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 commented 11 months ago

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

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

cattyhouse commented 11 months ago

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

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

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

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

zfl9 commented 11 months ago

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

bluehj777 commented 11 months ago

echo "$SSH_CONNECTION"

域名

zfl9 commented 11 months ago

sshd 服务器有多个 ip ?

bluehj777 commented 11 months ago

sshd 服务器有多个 ip ?

sshd 单IP

zfl9 commented 11 months ago

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

for ((i=0; i<10; ++i)); do
    ssh -p44422 xx@aa.bb.yy.zz 'echo $SSH_CLIENT'
done

cattyhouse commented 11 months ago

做这个测试:

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

cattyhouse commented 11 months ago

你先在 ss-tproxy 本机测试下：
for ((i=0; i<10; ++i)); do
    ssh -p44422 xx@aa.bb.yy.zz 'echo $SSH_CLIENT'
done

想到一块去了...

bluehj777 commented 11 months ago

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 commented 11 months ago

你先在 ss-tproxy 本机测试下：
for ((i=0; i<10; ++i)); do
    ssh -p44422 xx@aa.bb.yy.zz '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 commented 11 months ago

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

cattyhouse commented 11 months ago

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

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

zfl9 commented 11 months ago

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

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

bluehj777 commented 11 months ago

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

bluehj777 commented 11 months ago

检查你的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 commented 11 months ago

检查你的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 commented 11 months ago

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

cattyhouse commented 11 months ago

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

zfl9 commented 11 months ago

有时候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 commented 11 months ago

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

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

bluehj777 commented 11 months ago

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

zfl9 commented 11 months ago

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

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

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

bluehj777 commented 11 months ago

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

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

zfl9 commented 11 months ago

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

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

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

cattyhouse commented 11 months ago

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

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

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

bluehj777 commented 11 months ago

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

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

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

做了，没在的

zfl9 commented 11 months ago

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

zfl9 commented 11 months ago

有个验证的办法，先确保此时没有人通过 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 commented 11 months ago

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

zfl9 commented 11 months ago

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

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

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

zfl9 commented 11 months ago

有个验证的办法，先确保此时没有人通过 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 commented 11 months ago

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

zfl9 commented 11 months ago

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

是的。

bluehj777 commented 11 months ago

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

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

zfl9 / ss-tproxy

关于ipts_proxy_dst_port的疑问 #258