search

zfl9 / ss-tproxy

搭建 SS/SSR/V2Ray/Trojan/Socks5 透明代理的 Shell 脚本
GNU Affero General Public License v3.0
2.21k stars 437 forks source link

关于参数tcponly='true'后仅代理tcp流量，QUIC/HTTP3 问题 #237

Closed bluehj777 closed 1 year ago

bluehj777 commented 1 year ago

cat ss-tproxy.comf

tproxy='true'
tcponly='true'
selfonly='false'
proxy_startcmd='start_multiple_proxy_exec 4'
proxy_stopcmd='kill -9 $(pidof ss-redir v2ray xray obfs-local chinadns-ng dns2tcp)  >/dev/null 2>&1'

dns_direct='119.29.29.29#53'
dns_direct6='240C::6666#53' 
dns_direct_white='true'
dns_direct6_white='true'

dns_remote='8.8.8.8#53' 
dns_remote6='2001:4860:4860::8888#53' 
dns_remote_black='true' 
dns_remote6_black='true' 

dns2tcp_enable='auto'   
dns2tcp_bind_port='65454'  

ipts_if_lo='lo'
ipts_rt_tab='233'  
ipts_rt_mark='0x2333'
ipts_set_snat='false' 
ipts_set_snat6='false' 
ipts_reddns_onstop='192.168.100.1#53'  
ipts_reddns6_onstop='240C::6666#53
ipts_proxy_dst_port='1:65000'

设置 tcponly='true'仅代理tcp流量时.不管用global 还是chnroute 还是gfwlist 访问chat.openai.com都会被识别出是使用宽带的中国IP而禁止被访问了。访问其他网站GOOGLE,YOUTUBE等倒是没问题，可按所设模式预期处理。如果改成false代理tcp/udp则访问chatgpt没有此问题。

尝试处理cloudflare的IP段和opeanai.com,ai.com相关域名加入到gfwlist，也没有改善。

zfl9 commented 1 year ago

难道是 openai 用了 quic？走了 UDP？

zfl9 commented 1 year ago

试试在 ss-tproxy 主机添加如下 iptables 规则，将 udp 443 端口的流量给干掉（QUIC）

post_start() {
    iptables -t mangle -I SSTP_PREROUTING \
        -s 内网主机IP -p udp --dport 443 \
        -m addrtype ! --dst-type LOCAL \
        -j DROP
}
bluehj777 commented 1 year ago

试试在 ss-tproxy 主机添加如下 iptables 规则，将 udp 443 端口的流量给干掉（QUIC）

post_start() {
    iptables -t mangle -I SSTP_PREROUTING \
        -s 内网主机IP -p udp --dport 443 \
        -m addrtype ! --dst-type LOCAL \
        -j DROP
}

这条mangle记录貌似有效果。我在再多试试

还有，其实不光chatgpt的这个网站有这问题，我发现一些套cloudflare保护的网站都有几率出现这个问题，比如ip.sb这个查询IP地址的网站，他也是套在cloudflare下的。在tcponly时，也会回显出本地IP而不是代理IP

zfl9 commented 1 year ago

套了cf的也不一定就是要走代理的吧，我不认为这个是“问题”。

bluehj777 commented 1 year ago

套了cf的也不一定就是要走代理的吧，我不认为这个是“问题”。

我的意思是套了CF的网站比如ip.sb这个，解出的IP是CF的IP地址段吧，CF的IP地址段不算CHNROUTE范围，所以应该去走代理而不是直连。不是这样吗？

上面代码，又测试了，使用后可以解决这个内网主机的问题。

codecasex commented 1 year ago

试试在 ss-tproxy 主机添加如下 iptables 规则，将 udp 443 端口的流量给干掉（QUIC）

post_start() {
    iptables -t mangle -I SSTP_PREROUTING \
        -s 内网主机IP -p udp --dport 443 \
        -m addrtype ! --dst-type LOCAL \
        -j DROP
}

这条mangle记录貌似有效果。我在再多试试

还有，其实不光chatgpt的这个网站有这问题，我发现一些套cloudflare保护的网站都有几率出现这个问题，比如ip.sb这个查询IP地址的网站，他也是套在cloudflare下的。在tcponly时，也会回显出本地IP而不是代理IP

老师 您好 小白用户再次向您请教 这个规则具体是在哪里添加的？

zfl9 commented 1 year ago

ss-tproxy.conf 里面，钩子函数 post_start。

zfl9 commented 1 year ago

套了CF的网站比如ip.sb这个，解出的IP是CF的IP地址段吧，CF的IP地址段不算CHNROUTE范围，所以应该去走代理而不是直连。

你使用的是什么分流模式，chnroute吗？

bluehj777 commented 1 year ago

套了CF的网站比如ip.sb这个，解出的IP是CF的IP地址段吧，CF的IP地址段不算CHNROUTE范围，所以应该去走代理而不是直连。

你使用的是什么分流模式，chnroute吗？

是的，主要测试的是chnroute情况

bluehj777 commented 1 year ago

如果不加post_start之前，在gfwlist和global里情况也是一样

zfl9 commented 1 year ago

我整理下，你是说这样吗？

然后如果把 QUIC 给阻止了，就是都走代理（无论tcponly是什么值）

zfl9 commented 1 year ago

如果说是上面说的这种情况，那可以推测，ip.sb 也是使用了 QUIC(HTTP/3)，也就是走了 UDP 协议。

因为 tcponly='true' 时，UDP 没有走代理。

zfl9 commented 1 year ago

我自己测试了下，访问 ip.sb，然后 chrome F12 看了，确实是 h3，也就是 quic，也就是 udp。

codecasex commented 1 year ago

ss-tproxy.conf 里面，钩子函数 post_start。

收到 谢谢大佬 晚上回去试试

bluehj777 commented 1 year ago
  • chnroute 模式，并且没有 drop QUIC 流量
  • tcponly='false' 时，访问 ip.sb，走了代理
  • tcponly='true' 时，访问 ip.sb，走了直连

是这样 global 模式， tcponly='false' 时，访问 ip.sb，走了代理 访问 chatgpt，走了代理 tcponly='true' 时，访问 ip.sb，走了代理 访问 chatgpt，走了直连

chnroute 模式， tcponly='false' 时，访问 ip.sb，走了代理 访问 chatgpt，走了代理 tcponly='true' 时，访问 ip.sb，走了直连(这个不确定好像比较随机，可能和我清理浏览器cache不干净有关) 访问 chatgpt，走了直连

bluehj777 commented 1 year ago

如果说是上面说的这种情况，那可以推测，ip.sb 也是使用了 QUIC(HTTP/3)，也就是走了 UDP 协议。

因为 tcponly='true' 时，UDP 没有走代理。

又测了gwwlist模式，也是一样的结果，是QUIC 的影响，CF没啥关系。只要加了kill quic的代码，就可以解决访问CHATGPT这类网站的问题

bluehj777 commented 1 year ago

可以在原来代码里修改，在条件为 tcponly='true' 时启用kill quic 部分。

zfl9 commented 1 year ago

嗯，待会处理下，加个配置控制下，是否丢弃 quic 流量。

cattyhouse commented 1 year ago

youtube.com google.com 在你使用 chrome 浏览器的时候, 都会默认用 quic, 除非设置下 chrome. 丢弃 quic 杀伤力有点大.

zfl9 commented 1 year ago

tcponly='true'时（也就是只代理tcp），丢弃quic，应该没问题。

比如：代理本身不支持udp，或者代理的udp性能/体验差，还是有用处的。

bluehj777 commented 1 year ago

youtube.com google.com 在你使用 chrome 浏览器的时候, 都会默认用 quic, 除非设置下 chrome. 丢弃 quic 杀伤力有点大.

国内的udp环境不好，感觉纯用TCP，chrome浏览速度有提升啊

icy37785 commented 1 year ago

youtube.com google.com 在你使用 chrome 浏览器的时候, 都会默认用 quic, 除非设置下 chrome. 丢弃 quic 杀伤力有点大.

就是因为youtube google默认quic，所以更需要丢弃quic呀。

zfl9 commented 1 year ago

想了下，quic 不止国外网站在使用（Google、Youtube、Cloudflare），国内也很多网站、APP 在使用，比如抖音这些。

所以，最好还是只 drop 黑名单列表的 quic 流量（udp 443），白名单的不要 drop 掉。

大家怎么看？

xtccc commented 1 year ago

想了下，quic 不止国外网站在使用（Google、Youtube、Cloudflare），国内也很多网站、APP 在使用，比如抖音这些。

所以，最好还是只 drop 黑名单列表的 quic 流量（udp 443），白名单的不要 drop 掉。

大家怎么看？

我只想说下我是准备用quic代理的 hysteria2是用quic的 ，希望这个drop做成参数可选的

zfl9 commented 1 year ago

可选是肯定的，不会一刀切。

bluehj777 commented 1 year ago

想了下，quic 不止国外网站在使用（Google、Youtube、Cloudflare），国内也很多网站、APP 在使用，比如抖音这些。

所以，最好还是只 drop 黑名单列表的 quic 流量（udp 443），白名单的不要 drop 掉。

大家怎么看？ 可选 "黑名单"或 “非国内” 喜欢用udp443的就开tcponly=false吧

zfl9 commented 1 year ago

新增配置：ipts_drop_quic='tcponly'，丢弃发往"黑名单"的QUIC:

这里说的“黑名单”，是指在“分流”时，被判定为“要走代理的目标IP/域名”。

另外，此处的 drop 不会影响 $proxy_group 的进程（比如本机代理进程）。

zfl9 commented 1 year ago

见 v4.7.4 版本，ipts_drop_quic。