shadowsocks-rust
shadowsocks-rust copied to clipboard
There is something wrong with the ACL in ios.
[proxy_all]
[bypass_list]
121.41.110.161
||ipip.net
||ip111.cn
The domain rule of the ACL does not take effect. Only the IP rule takes effect. But in the log, it shows bypassed.
log:
2022-04-01T18:32:23.336375+08:00 - shadowsocks local 1.14.3 build 2022-04-01T10:24:09.261425+00:00
2022-04-01T18:32:23.343940+08:00 - shadowsocks socks TCP listening on 127.0.0.1:7778
2022-04-01T18:32:23.344313+08:00 - shadowsocks socks5 UDP listening on 127.0.0.1:7778
2022-04-01T18:32:23.961959+08:00 - created udp association for 127.0.0.1:63499
2022-04-01T18:32:24.065433+08:00 - CONNECT 1.1.1.1:53
2022-04-01T18:32:24.070625+08:00 - established tcp tunnel 127.0.0.1:62940 <-> 1.1.1.1:53 through sever 185.184.223.136:38293 (outbound: 185.184.223.136:38293)
2022-04-01T18:32:24.083928+08:00 - CONNECT myip.ipip.net:80
2022-04-01T18:32:24.124455+08:00 - established tcp tunnel 127.0.0.1:62941 <-> myip.ipip.net:80 bypassed
2022-04-01T18:32:24.415261+08:00 - CONNECT www.google.com:443
2022-04-01T18:32:24.429813+08:00 - created udp association for 127.0.0.1:50209
2022-04-01T18:32:25.532650+08:00 - established tcp tunnel 127.0.0.1:62944 <-> www.google.com:443 through sever 185.184.223.136:38293 (outbound: 185.184.223.136:38293)
2022-04-01T18:32:26.935104+08:00 - CONNECT 23.55.56.213:443
2022-04-01T18:32:26.959292+08:00 - established tcp tunnel 127.0.0.1:62946 <-> 23.55.56.213:443 through sever 185.184.223.136:38293 (outbound: 185.184.223.136:38293)
2022-04-01T18:32:27.424003+08:00 - CONNECT 121.41.110.161:80
2022-04-01T18:32:27.459131+08:00 - established tcp tunnel 127.0.0.1:62948 <-> 121.41.110.161:80 bypassed
So why you still said that it didn’t have any effects?
So why you still said that it didn’t have any effects?
对不起,我没有说明白。比如ip11.cn的ip是121.41.110.161。 我用以下的配置不生效:
[proxy_all]
[bypass_list]
||ip111.cn
ip111的结果仍然是服务器的ip,而不是本地运营商的ip。
但用以下的配置是生效的,ip111的结果也是正确的:
[proxy_all]
[bypass_list]
121.41.110.161
The logs in your previous comment showed that myip.ipip.net
is already bypassed.
The logs in your previous comment showed that
myip.ipip.net
is already bypassed.
实际上,ipip.net显示的结果是服务器的ip而不是本地ip,所以它并没有bypassed
Then you have to take a look at the environment that running sslocal
. Maybe there is something related to the DNS nameserver setting.
I don’t think they are related. It already bypassed.
myip.ipip.net
is already bypassed. There is nothing related to ACL. The only problem here is that why requests sent via sslocal
was from foreign IP.
What you are talking about will only happen in protocol "dns", which is completely unrelated in this issue. Don’t make other users confused.
There is no local and remote DNS in SOCKS5 local server.
What you are talking about will only happen in protocol "dns", which is completely unrelated in this issue. Don’t make other users confused.
真的不好意思,我打扰到别人了。🥹
PS. 希望@zonyitoo 可以检视一下acl这块的代码。
I just ran both sslocal
and ssserver
locally on my laptop with your ACL, myip.ipip.net
was bypassed as expected, and ssserver
didn't show any logs about myip.ipip.net
, which means that the request to myip.ipip.net
was sent directly from sslocal
(bypassed).
I can see the correct IP from myip.ipip.net
. So I don't think there is anything related to the ACL rules here.
@Yewenyu You can try to do the same test by running a ssserver
with -vvv
and see if there are any connections to myip.ipip.net
are made when you see bypassed
in sslocal
's log.
BTW, you are talking about iOS, maybe there is something related to routing? Maybe the requests sent from sslocal
may be routed back to the Network Extension and then sent through another tunnel.
Client (SOCKS5: myip.ipip.net) -> `sslocal` -> (TARGET: myip.ipip.net, bypassed) -> [Network Extension] -> ?
Since we can see bypassed
in log, then a TCP socket was made connected to myip.ipip.net
in sslocal
, for sure.
I just ran both
sslocal
andssserver
locally on my laptop with your ACL,myip.ipip.net
was bypassed as expected, andssserver
didn't show any logs aboutmyip.ipip.net
, which means that the request tomyip.ipip.net
was sent directly fromsslocal
(bypassed).I can see the correct IP from
myip.ipip.net
. So I don't think there is anything related to the ACL rules here.@Yewenyu You can try to do the same test by running a
ssserver
with-vvv
and see if there are any connections tomyip.ipip.net
are made when you seebypassed
insslocal
's log.BTW, you are talking about iOS, maybe there is something related to routing? Maybe the requests sent from
sslocal
may be routed back to the Network Extension and then sent through another tunnel.Client (SOCKS5: myip.ipip.net) -> `sslocal` -> (TARGET: myip.ipip.net, bypassed) -> [Network Extension] -> ?
Since we can see
bypassed
in log, then a TCP socket was made connected tomyip.ipip.net
insslocal
, for sure.
好的,我再see see,非常感谢
What you are talking about will only happen in protocol "dns", which is completely unrelated in this issue. Don’t make other users confused.
真的不好意思,我打扰到别人了。🥹
你也是想帮忙而已,也谢谢你
I just ran both
sslocal
andssserver
locally on my laptop with your ACL,myip.ipip.net
was bypassed as expected, andssserver
didn't show any logs aboutmyip.ipip.net
, which means that the request tomyip.ipip.net
was sent directly fromsslocal
(bypassed).I can see the correct IP from
myip.ipip.net
. So I don't think there is anything related to the ACL rules here.@Yewenyu You can try to do the same test by running a
ssserver
with-vvv
and see if there are any connections tomyip.ipip.net
are made when you seebypassed
insslocal
's log.BTW, you are talking about iOS, maybe there is something related to routing? Maybe the requests sent from
sslocal
may be routed back to the Network Extension and then sent through another tunnel.Client (SOCKS5: myip.ipip.net) -> `sslocal` -> (TARGET: myip.ipip.net, bypassed) -> [Network Extension] -> ?
Since we can see
bypassed
in log, then a TCP socket was made connected tomyip.ipip.net
insslocal
, for sure.
我发现ios不启用http代理的话,dns包就会走ss local的udp relay,然后dns包返回后,ss local并没有把解析好的ip记录到acl里面,所以acl域名规则就不生效了
Of course it won't, sslocal is just a tunnel, it won't parse your data.