search

SagerNet / sing-box

The universal proxy platform
https://sing-box.sagernet.org/
Other
18.82k stars 2.25k forks source link

Problem with REALITY when connecting from Russia #696

Closed dani0854 closed 1 year ago

dani0854 commented 1 year ago

Welcome

Description of the problem

I have a problem connecting from Russia. Client is in Russia, and server is in Germany. I have tried connecting with exactly same client config from different country and it worked. For some reason, when connecting from Russia, I get context deadline exceeded.

I have checked time on client and server, which turns out it was correct. Also, I can easily telnet from client into port 443 on server.

Also, TLS handshake seems to get stuck on a client in Russia: 

curl -v --resolve www.amazon.de:443:<server ip> https://www.amazon.de
* Added www.amazon.de:443:<server ip> to DNS cache
* Hostname www.amazon.de was found in DNS cache
*   Trying <server ip>:443...
* Connected to www.amazon.de (<server ip>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):

Seems to get stuck, in other countries it works perfectly. Moreover, on a client in Russia, TLS handshake works perfectly when running curl -v https://www.amazon.de

I am afraid at that point my knowledge is insufficient to continue debugging it on my own. I looked through news and issues, couldn't find anything relevant.

Version of sing-box

Client ```console $ sing-box version sing-box version unknown Environment: go1.20.5 linux/arm64 Tags: with_reality_server,with_utls,with_quic,with_wireguard,with_acme Revision: e482053c8a01fe1d3f64ea4599d1896ca3c73298 CGO: enabled ``` Server: ```console $ sing-box version sing-box version unknown Environment: go1.20.5 linux/amd64 Tags: with_reality_server,with_quic,with_wireguard,with_acme Revision: e482053c8a01fe1d3f64ea4599d1896ca3c73298 CGO: disabled ```

Server and client configuration file

Client: ```json { "log": { "level": "trace" }, "inbounds": [ { "type": "socks", "tag": "socks-in", "listen": "0.0.0.0", "listen_port": 1080 } ], "outbounds": [ { "type": "vless", "tag": "proxy", "server": "", "server_port": 443, "uuid": "", "flow": "xtls-rprx-vision", "tls": { "enabled": true, "server_name": "www.amazon.de", "utls": { "enabled": true }, "reality": { "enabled": true, "public_key": "", "short_id": "" } }, "packet_encoding": "xudp" } ] } ``` Server: ```json { "log": { "level": "trace" }, "inbounds": [ { "type": "vless", "tag": "vless-in", "listen": "0.0.0.0", "listen_port": 443, "users": [ { "name": "User", "uuid": "", "flow": "xtls-rprx-vision" } ], "tls": { "enabled": true, "server_name": "www.amazon.de", "reality": { "enabled": true, "handshake": { "server": "www.amazon.de", "server_port": 443 }, "private_key": "", "short_id": "", "max_time_difference": "1m0s" } } } ], "outbounds": [ { "type": "direct", "tag": "direct" } ] } ```

Server and client log file

Client: ```console INFO[0772] [2191462909 0ms] inbound/socks[socks-in]: inbound connection from 127.0.0.1:51012 INFO[0772] [2191462909 1ms] inbound/socks[socks-in]: inbound connection to 1.1.1.1:80 INFO[0772] [2191462909 1ms] outbound/vless[proxy]: outbound connection to 1.1.1.1:80 DEBUG[0777] [2191462909 5.5s] inbound/socks[socks-in]: connection closed: process connection from 127.0.0.1:51012: context deadline exceeded ``` Server: ```console INFO[0820] [2280245079 0ms] inbound/vless[vless-in]: inbound connection from :2559 DEBUG[0820] [2280245079 1ms] dns: lookup domain www.amazon.de DEBUG[0820] [2280245079 8ms] dns: lookup succeed for www.amazon.de: 52.222.224.83 2606:2cc0::163 2606:2cc0:1::163 2606:2cc0:3::163 2606:2cc0:2::163 ERROR[0850] [2280245079 30.1s] inbound/vless[vless-in]: process connection from :2559: REALITY: processed invalid connection ```
nekohasekai commented 1 year ago

There have been reports from Iranian users that shadow-tls has been blocked, possibly based on local DNS lookups. Regardless, shadow-tls and other similar technologies may have been banned in places where China exports censorship technology.

dani0854 commented 1 year ago

Now having an identical problem with Shadowsocks. Looks like packets have no problem traveling from client to server, but get dropped on the way back from server to client.

Disabled all firewall, didn't help. Also checked from client in different city in Russia, and it works.

Could be specific ISP, or Moscow problem.

(Or as usual I am missing something trivial)

uprtdev commented 1 year ago

The fact that it works on one ISP but doesn't work on another may have place because of the type of censorship mechanism that these ISPs have. Not all the internet providers in RU have "TSPU" (last generation of DPI systems) installed.

uprtdev commented 1 year ago

What confuses me in your log, I see the message "processed invalid connection". Doesn't it mean that the connection reaches the server, but the server refuses it for some reason?

Could you please try to connect to the same server using the same ISP, just not from your computer, but from the mobile device over WiFi (try Nekobox or V2RayNG client for example).

And one more question, do you have some uTLS fingerprint set on the client? Don't see it in the config.

dani0854 commented 1 year ago

Unfortunately, I am in a different country. And only have access via raspberry pi. But it all started when VPN stopped working on relative iphone, with sing-box app. Since this relative is not great with tech, it's hard for me to debug it from a phone remotely. So I stripped most of the config and started debugging from a raspberry pi I have in the same network. But relative says it also doesn't work on mobile connection.

Since I stripped uTLS fingerprint, I assume it takes default value of chrome

dani0854 commented 1 year ago

I did performed tcpdump, seems some packets get dropped on the way to server

Client:

tcpdump -i eth0 host <server ip>
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:31:19.502256 IP 192.168.70.10.40950 > <server ip>.https: Flags [S], seq 2099491376, win 64240, options [mss 1460,sackOK,TS val 1548141506 ecr 0,nop,wscale 7], length 0
19:31:19.553756 IP <server ip>.https > 192.168.70.10.40950: Flags [S.], seq 758334370, ack 2099491377, win 43440, options [mss 1460,sackOK,TS val 3252776925 ecr 1548141506,nop,wscale 11], length 0
19:31:19.553816 IP 192.168.70.10.40950 > <server ip>.https: Flags [.], ack 1, win 502, options [nop,nop,TS val 1548141557 ecr 3252776925], length 0
19:31:19.556233 IP 192.168.70.10.40950 > <server ip>.https: Flags [P.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 1548141560 ecr 3252776925], length 517
19:31:19.818127 IP 192.168.70.10.40950 > <server ip>.https: Flags [P.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 1548141822 ecr 3252776925], length 517
19:31:20.074145 IP 192.168.70.10.40950 > <server ip>.https: Flags [P.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 1548142078 ecr 3252776925], length 517
19:31:20.586151 IP 192.168.70.10.40950 > <server ip>.https: Flags [P.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 1548142590 ecr 3252776925], length 517
19:31:21.610165 IP 192.168.70.10.40950 > <server ip>.https: Flags [P.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 1548143614 ecr 3252776925], length 517
19:31:23.658163 IP 192.168.70.10.40950 > <server ip>.https: Flags [P.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 1548145662 ecr 3252776925], length 517
19:31:24.554351 IP 192.168.70.10.40950 > <server ip>.https: Flags [F.], seq 518, ack 1, win 502, options [nop,nop,TS val 1548146558 ecr 3252776925], length 0
19:31:27.754169 IP 192.168.70.10.40950 > <server ip>.https: Flags [FP.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 1548149758 ecr 3252776925], length 517
19:31:35.946161 IP 192.168.70.10.40950 > <server ip>.https: Flags [FP.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 1548157950 ecr 3252776925], length 517
19:31:52.330169 IP 192.168.70.10.40950 > <server ip>.https: Flags [FP.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 1548174334 ecr 3252776925], length 517

Server:

tcpdump -i eth0 host <client ip>
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:31:19.533672 IP <client ip>.1328 > sing-box.https: Flags [S], seq 2099491376, win 64240, options [mss 1460,sackOK,TS val 1548141506 ecr 0,nop,wscale 7], length 0
16:31:19.533763 IP sing-box.https > <client ip>.1328: Flags [S.], seq 758334370, ack 2099491377, win 43440, options [mss 1460,sackOK,TS val 3252776925 ecr 1548141506,nop,wscale 11], length 0
16:31:19.584490 IP <client ip>.1328 > sing-box.https: Flags [.], ack 1, win 502, options [nop,nop,TS val 1548141557 ecr 3252776925], length 0
16:31:34.598289 IP sing-box.https > <client ip>.1328: Flags [.], ack 1, win 22, options [nop,nop,TS val 3252791990 ecr 1548141557], length 0
16:31:39.608748 IP sing-box.https > <client ip>.1328: Flags [F.], seq 1, ack 1, win 22, options [nop,nop,TS val 3252797000 ecr 1548141557], length 0
16:31:39.878259 IP sing-box.https > <client ip>.1328: Flags [F.], seq 1, ack 1, win 22, options [nop,nop,TS val 3252797270 ecr 1548141557], length 0
16:31:40.134285 IP sing-box.https > <client ip>.1328: Flags [F.], seq 1, ack 1, win 22, options [nop,nop,TS val 3252797526 ecr 1548141557], length 0
16:31:40.646285 IP sing-box.https > <client ip>.1328: Flags [F.], seq 1, ack 1, win 22, options [nop,nop,TS val 3252798038 ecr 1548141557], length 0
16:31:41.670269 IP sing-box.https > <client ip>.1328: Flags [F.], seq 1, ack 1, win 22, options [nop,nop,TS val 3252799062 ecr 1548141557], length 0
16:31:43.718303 IP sing-box.https > <client ip>.1328: Flags [F.], seq 1, ack 1, win 22, options [nop,nop,TS val 3252801110 ecr 1548141557], length 0
16:31:47.910274 IP sing-box.https > <client ip>.1328: Flags [F.], seq 1, ack 1, win 22, options [nop,nop,TS val 3252805302 ecr 1548141557], length 0
16:31:56.102276 IP sing-box.https > <client ip>.1328: Flags [F.], seq 1, ack 1, win 22, options [nop,nop,TS val 3252813494 ecr 1548141557], length 0
16:32:12.486255 IP sing-box.https > <client ip>.1328: Flags [F.], seq 1, ack 1, win 22, options [nop,nop,TS val 3252829878 ecr 1548141557], length 0
16:32:45.510266 IP sing-box.https > <client ip>.1328: Flags [F.], seq 1, ack 1, win 22, options [nop,nop,TS val 3252862902 ecr 1548141557], length 0
dani0854 commented 1 year ago

The problem seemed to happen only between clients in Russia, and a specific server. So I migrated to a new server, and the issue has disappeared. I guess the best long term solution will be to use something like Cloudflare.

Since it is not an issue of sing-box, I am closing this issue. Thanks for the help.