search

shadowsocks / shadowsocks-rust

A Rust port of shadowsocks
https://shadowsocks.org/
MIT License
8.4k stars 1.15k forks source link

Site w 60 DNS lookups for CDN's fails to load #410

Closed AmazingGinger closed 3 years ago

AmazingGinger commented 3 years ago

A friend uses the XNXX website. Unfortunately, all their thumbnails are hosted on different CDNs which subsequently have CNAME lookups. Something about that causes the shadowsocks server to give up and only 60% of thumbnails load as a consequence.

How I reproduce:

  1. Server is Android 10, no root, not hotspot plan
  2. Visit XNXX website

What happens:

  1. Half the time Thumbnails don't load... specifically... 
    
$ curl  --insecure https://89.187.164.30
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
$ curl https://cdn77-pic.xnxx-cdn.com
^C  // Just hangs... for no reason

$ ssh unrelated-cloud-server.aws.com $ sudo nano /etc/hosts // Add resolution of ip of thumbnail's hostname $ curl https://cdn77-pic.xnxx-cdn.com

403 Forbidden

Request forbidden by administrative rules.

$ exit

$ ssh server-hosting-shadowsocks.com $ curl --insecure https://89.187.164.30 curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1) $ curl 'https://cdn77-pic.xnxx-cdn.com/videos/thumbs169xnxxll/a3/8d/b3/a38db3c37d82613db22deea779314f52/a38db3c37d82613db22deea779314f52.27.jpg' --output img.jpg % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:05:00 --:--:-- 0 curl: (28) Operation timed out after 300460 milliseconds with 0 out of 0 bytes received $ echo "WTF"


**Logs on the server:**
Yes I've tried with nodelay false and no buffers. And in on the go version of ss2.

$ ./ssserver-dbg.sh 2>&1 | grep '89.187.164.30' TRACE [31508:] [shadowsocks_service::server::tcprelay] accepted tcp client connection 192.168.142.68:54020, establishing tunnel to 89.187.164.30:443 DEBUG [31508:] [shadowsocks_service::server::tcprelay] established tcp tunnel 192.168.142.68:54020 <-> 89.187.164.30:443 with ConnectOpts { fwmark: None, vpn_protect_path: None, bind_local_addr: None, bind_interface: None, tcp: TcpSocketOpts { send_buffer_size: Some(262144), recv_buffer_size: Some(262144), nodelay: true } } TRACE [31508:] [shadowsocks_service::server::tcprelay] accepted tcp client connection 192.168.142.68:54048, establishing tunnel to 89.187.164.30:443 DEBUG [31508:] [shadowsocks_service::server::tcprelay] established tcp tunnel 192.168.142.68:54048 <-> 89.187.164.30:443 with ConnectOpts { fwmark: None, vpn_protect_path: None, bind_local_addr: None, bind_interface: None, tcp: TcpSocketOpts { send_buffer_size: Some(262144), recv_buffer_size: Some(262144), nodelay: true } } TRACE [31508:] [shadowsocks_service::server::tcprelay] tcp tunnel 192.168.142.68:54048 -> 89.187.164.30:443 closed TRACE [31508:] [shadowsocks_service::server::tcprelay] accepted tcp client connection 192.168.142.68:54052, establishing tunnel to 89.187.164.30:443 DEBUG [31508:] [shadowsocks_service::server::tcprelay] established tcp tunnel 192.168.142.68:54052 <-> 89.187.164.30:443 with ConnectOpts { fwmark: None, vpn_protect_path: None, bind_local_addr: None, bind_interface: None, tcp: TcpSocketOpts { send_buffer_size: Some(262144), recv_buffer_size: Some(262144), nodelay: true } }


Ideas on how to fix?

Reproduced on go-shadowsocks2 and shadowsocks-rust with tokio and trust-dns
The server is aarch64-linux-android
Tried many different clients... Same result.

My latest failed config:

{ "mode": "tcp_and_udp", "server": "0.0.0.0", "server_port": 8388, "password": "hentai9000", "timeout": 9, "method": "plain", "udp_timeout": 10, "udp_max_associations": 4096, "worker_threads": 16,

"dns": "google",

// TCP_NODELAY "no_delay": true,

// Soft and Hard limit of file descriptors on *NIX systems "nofile": 10240,

// Try to resolve domain name to IPv6 (AAAA) addresses first "ipv6_first": true }

!/bin/bash

"$HOME"/bin/ssserver-rust \ -c "$HOME"/ssserver-rust.conf \ --udp-max-associations 4096 \ --worker-threads 16 \ --outbound-recv-buffer-size 262144 \ --outbound-send-buffer-size 262144 \ --inbound-recv-buffer-size 262144 \ --inbound-send-buffer-size 262144 \ --no-delay -v

database64128 commented 3 years ago
  1. Your timeout and udp_timeout are both too low. I would recommend dropping both to use default values.
  2. You are using the unencrypted mode on the default port without a plugin.
AmazingGinger commented 3 years ago
  1. Your timeout and udp_timeout are both too low. I would recommend dropping both to use default values.
  2. You are using the unencrypted mode on the default port without a plugin.

  1. The android server can pull over 70Mbps, Over shadowsocks the Xfinity Speedtest has pushed past 60Mbps. I'll try raising them after playing around with resolved/unbound to unburden Shadowsocks' DNS duties.

  2. I should have mentioned Im using ShadowSocks on a LAN.... the servers and the clients are on the same LAN. WiFi, Ethernet over USB has made no difference. Also tried AEAD ciphers and a plethora of Stream ciphers. You might be asking why not use ip tables, ipsec or openvpn.... ip tables if off the table as I don't have root access to some of the servers, openvpn and tun interfaces are very hard to use on android.... and you have built-in load balancing here which would be useful with a couple android servers.... Specially if I can sneak into a mmWave isp without paying a fortune.

Will report back once the science gets done. Rust seems really cool, might need it for Pi Pico projects. Btw, compiling this thing on a Raspberry Pi with 2GiB was an exercise in futility... I didn't see your aarch64 before it was too late. An aarch64-linux-android build would be sweet.

Thanks!

database64128 commented 3 years ago

I should have mentioned Im using ShadowSocks on a LAN

Then you might want to use SOCKS5 directly.

and you have built-in load balancing here which would be useful with a couple android servers

You might've misunderstood what shadowoscks-rust's "load balancer" does. The ping balancer is actually a server selector that takes latency into account. It's not designed for your use case.

with resolved/unbound to unburden Shadowsocks' DNS duties.

DNS lookups are not a burden. My setup also routes plain DNS UDP traffic via shadowsocks-rust, and I haven't observed any issues on recent builds.

zonyitoo commented 3 years ago

Btw, compiling this thing on a Raspberry Pi with 2GiB was an exercise in futility... I didn't see your aarch64 before it was too late. An aarch64-linux-android build would be sweet.

Just cross compile it with cross on your host:

$ cross build --release --target aarch64-linux-android

A friend uses the XNXX website. Unfortunately, all their thumbnails are hosted on different CDNs which subsequently have CNAME lookups. Something about that causes the shadowsocks server to give up and only 60% of thumbnails load as a consequence.

If I understand correctly that ssserver failed to proxy some of the TCP connections to XNXX websites?

That was interesting. Could you tried to run ssserver with debug logs open (-vvv) and see if there are anything abnormal when you open your website?

Also, if you suspect that DNS resolver is broken, try to build without the trust-dns feature, which will use libc's getaddrinfo for resolving domains.

$ cross build --release --target aarch64-linux-android --no-default-features --features "logging server multi-threaded"
AmazingGinger commented 3 years ago

Figured it out... It was an issue with some upstream content filter... My ISP blocks the domain entirely, but allows access to the server.