search

net4people / bbs

Forum for discussing Internet censorship circumvention
3.19k stars 75 forks source link

中国屏蔽了部分例如 1.1.1.1 的安全 DNS （DoH） #284

Closed flowerinsnowdh closed 9 months ago

flowerinsnowdh commented 9 months ago

最近发现境内经常无法访问网络，后来发现是 DNS 经常不灵的问题；目前正在使用 DNS over HTTPS，抓包发现只要是发往 1.1.1.1:443、8.8.8.8:443这种安全 DNS 的地址，会经常收到 TCP 报文 RST——有时是在发送 SYN 后，有时是在发送 Client Hello 后，有时是接到 Server Hello 后；手动访问 https://1.1.1.1/ 或 https://8.8.8.8/ 这些本来有欢迎页的网站时都会因为 TCP 重置而无法访问；多台主机都有该问题，使用代理服务器后该问题得到了解决

发往不加密的 53 端口的 TCP 和 UDP 数据都可以正常发送和接收以完成 DNS 查询

对应 IPv6 地址例如[2606:4700:4700::1111]:443则是失灵时不灵，有时候会反复发送 SYN 而没有任何回应，有时候可以正常访问

Recently, I found that I often can't access the internet in my country, but later I realized that it's because the DNS often doesn't work; currently I'm using DNS over HTTPS, and I found that as long as I send to a secure DNS address such as 1.1.1.1:443 or 8.8.8.8:443, I will often receive a TCP RST - sometimes after sending SYN, sometimes after sending Client Hello, sometimes after receiving Server Hello; when manually accessing https://1.1.1.1/ or https://8.8.8.8/, which have a welcome page, it is impossible to access due to TCP reset; multiple hosts have this problem. This problem was solved by using a proxy server.

TCP and UDP data to and from unencrypted port 53 can be sent and received normally for DNS lookups.

For IPv6 addresses such as [2606:4700:4700::1111]:443, it fails to work, sometimes it sends SYN repeatedly without any response, sometimes it can be accessed normally.

wkrp commented 9 months ago

There's some recent discussion about blocking 1.1.1.1 in this thread: https://github.com/net4people/bbs/issues/280#issuecomment-1706267069. However, I don't see a mention of TCP RST, so your experience may be something different.

Do you know on what day the problem started?

RPRX commented 9 months ago

However, I don't see a mention of TCP RST, so your experience may be something different.

其实可能不特殊，无非就是被丢包或收到 RST，具体怎么做取决于各地区、各运营商。总之任务发下去了，确保给它封了就行。

说起 RST，有兴趣的话可以看一下我们对河南增强版 SNI 黑名单（仅次于福建的一些 SNI 白名单）的研究：https://github.com/XTLS/Xray-core/issues/2426

In fact, it may be nothing special, whether packets are dropped or receive RSTs. It may be that exactly how to do it depends on each region and each carrier: just make sure to block it when the task is issued.

Speaking of RST, if you're interested, check out our research on Henan's enhanced SNI blacklist (second only to some of Fujian's SNI whitelists): https://github.com/XTLS/Xray-core/issues/2426

wkrp commented 9 months ago

I've seen a pcap now from 2023-09-05 that shows RSTs when accessing 1.1.1.1:443 and is otherwise consistent with https://github.com/net4people/bbs/issues/280#issuecomment-1706267069.

  1. ICMP echo works (RTT ~250 ms, TTL = 47).
  2. TCP connection to port 80 works (RTT ~200 ms, TTL = 46).
  3. TCP connection to port 443 receives three RSTs (RTT ~9 ms, TTL variable > 64). The RSTs come immediately after the client SYN.

There's also a RST visible in recent OONI measurements. For some reason OONI classifies it as "error" rather than "anomaly". In this case, the connection is established successfully and is reset only after the Client Hello. There are still measurements showing timeouts and some that are successful.

https://explorer.ooni.org/chart/mat?test_name=web_connectivity&axis_x=measurement_start_day&since=2023-08-06&until=2023-09-15&time_grain=day&probe_cc=CN&input=https%3A%2F%2F1.1.1.1%2Fdns-query%3Fdns%3Dq80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB

https://explorer.ooni.org/search?since=2023-09-07&until=2023-09-09&probe_cc=CN&test_name=web_connectivity&failure=true&domain=1.1.1.1

Lanius-collaris commented 9 months ago

@flowerinsnowdh Could you try https://1.0.0.1/dns-query , https://162.159.36.1/dns-query or https://[2001:4860:4860::64]/dns-query ? Client Hello without SNI may not trigger RST.

flowerinsnowdh commented 9 months ago

@flowerinsnowdh Could you try https://1.0.0.1/dns-query , https://162.159.36.1/dns-query or https://[2001:4860:4860::64]/dns-query ? Client Hello without SNI may not trigger RST.

URL Result
https://cloudflare-dns.com/ ❌
https://one.one.one.one/ ❌
https://1.0.0.1/ ✅
https://1.1.1.1/ ❌
https://162.159.36.1/ ✅
https://162.159.46.1/ ✅
https://[2606:4700:4700::1001]/ ✅
https://[2606:4700:4700::1111]/ ✅
https://[2606:4700:4700::64]/ ✅
https://[2606:4700:4700::6400]/ ✅

事实上不论发的 SNI 是什么，只要 IP 地址匹配，且端口是 443，TCP SYN 后就有概率会被重置

In fact, no matter what SNI is sent, as long as the IP address matches and the port is 443, there is a probability that it will be reset after TCP SYN

flowerinsnowdh commented 9 months ago

I've seen a pcap now from 2023-09-05 that shows RSTs when accessing 1.1.1.1:443 and is otherwise consistent with #280 (comment).

1. ICMP echo works (RTT ~250 ms, TTL = 47).

2. TCP connection to port 80 works (RTT ~200 ms, TTL = 46).

3. TCP connection to port 443 receives three RSTs (RTT ~9 ms, TTL variable > 64). The RSTs come immediately after the client SYN.

There's also a RST visible in recent OONI measurements. For some reason OONI classifies it as "error" rather than "anomaly". In this case, the connection is established successfully and is reset only after the Client Hello. There are still measurements showing timeouts and some that are successful.

https://explorer.ooni.org/chart/mat?test_name=web_connectivity&axis_x=measurement_start_day&since=2023-08-06&until=2023-09-15&time_grain=day&probe_cc=CN&input=https%3A%2F%2F1.1.1.1%2Fdns-query%3Fdns%3Dq80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB

https://explorer.ooni.org/search?since=2023-09-07&until=2023-09-09&probe_cc=CN&test_name=web_connectivity&failure=true&domain=1.1.1.1

是这样没错，完全相同

That's right. It's exactly the same.

flowerinsnowdh commented 9 months ago

There's some recent discussion about blocking 1.1.1.1 in this thread: #280 (comment). However, I don't see a mention of TCP RST, so your experience may be something different.

Do you know on what day the problem started?

根据多人报告，大约在9月5日左右出现了该问题，将 DNS 服务器设置为 DoH 1.1.1.1 || 8.8.8.8 的用户/VPS 难以访问互联网

According to multiple reports, the issue appeared around September 5, and users/VPS with DNS servers set to DoH 1.1.1.1 || 8.8.8.8 had difficulty accessing the Internet

UjuiUjuMandan commented 9 months ago

Your title is misleading, in fact only some of DoH severs are blocked.

Have a look at this DoH list.

nameserver = [
    "https://185.222.222.222/dns-query",
    "https://45.11.45.11/dns-query",

    "https://9.9.9.9/dns-query",
    "https://149.112.112.112/dns-query",

    "https://208.67.220.220/dns-query",
    "https://208.67.222.222/dns-query",

    "https://101.101.101.101/dns-query",

    "https://146.112.41.5/dns-query",

    "https://130.59.31.248/dns-query",
    "https://130.59.31.251/dns-query",

    "https://77.88.8.1/dns-query",
    "https://77.88.8.8/dns-query",

    "https://94.140.14.140/dns-query",
    "https://94.140.14.141/dns-query",

    "https://162.159.36.1/dns-query",
    "https://162.159.46.1/dns-query",
    "https://1.1.1.1/dns-query",
    "https://1.0.0.1/dns-query",
    "https://162.159.132.53/dns-query",
    "https://[2606:4700:4700::1111]/dns-query",
    "https://[2606:4700:4700::1001]/dns-query",
    "https://[2606:4700:4700::0064]/dns-query",
    "https://[2606:4700:4700::6400]/dns-query",

    "https://dns.tuna.tsinghua.edu.cn:8443/dns-query"
]
wkrp commented 9 months ago

根据多人报告，大约在9月5日左右出现了该问题，将 DNS 服务器设置为 DoH 1.1.1.1 || 8.8.8.8 的用户/VPS 难以访问互联网

According to multiple reports, the issue appeared around September 5, and users/VPS with DNS servers set to DoH 1.1.1.1 || 8.8.8.8 had difficulty accessing the Internet

In #285 I started a new thread to talk specifically about RST injection for 1.1.1.1:443.

@flowerinsnowdh, one thing I wasn't sure about: is 8.8.8.8:443 blocked the same way as 1.1.1.1:443 is blocked (for you)? Or is 8.8.8.8:443 blocked in a different way, such as by packet dropping? I am trying to find out whether the blocking of 1.1.1.1:443 is its own event, or if it was coordinated with 8.8.8.8:443 at the same time and in the same way.

UjuiUjuMandan commented 9 months ago

@wkrp

I am trying to find out whether the blocking of 1.1.1.1:443 is its own event, or if it was coordinated with 8.8.8.8:443 at the same time and in the same way.

In my experience, https://8.8.8.8 has long been blocked, at least since March, not blocked recently. No RST, but timed out, in all China, according to test result on https://www.itdog.cn/http/ .

flowerinsnowdh commented 9 months ago

Your title is misleading, in fact only some of DoH severs are blocked.

Have a look at this DoH list.

nameserver = [
  "https://185.222.222.222/dns-query",
  "https://45.11.45.11/dns-query",

  "https://9.9.9.9/dns-query",
  "https://149.112.112.112/dns-query",

  "https://208.67.220.220/dns-query",
  "https://208.67.222.222/dns-query",

  "https://101.101.101.101/dns-query",

  "https://146.112.41.5/dns-query",

  "https://130.59.31.248/dns-query",
  "https://130.59.31.251/dns-query",

  "https://77.88.8.1/dns-query",
  "https://77.88.8.8/dns-query",

  "https://94.140.14.140/dns-query",
  "https://94.140.14.141/dns-query",

  "https://162.159.36.1/dns-query",
  "https://162.159.46.1/dns-query",
  "https://1.1.1.1/dns-query",
  "https://1.0.0.1/dns-query",
  "https://162.159.132.53/dns-query",
  "https://[2606:4700:4700::1111]/dns-query",
  "https://[2606:4700:4700::1001]/dns-query",
  "https://[2606:4700:4700::0064]/dns-query",
  "https://[2606:4700:4700::6400]/dns-query",

  "https://dns.tuna.tsinghua.edu.cn:8443/dns-query"
]

感谢指正，是我的描述不够严谨，已更正

Thanks for the correction, it was a lack of precision in my description, it has been corrected

flowerinsnowdh commented 9 months ago

根据多人报告，大约在9月5日左右出现了该问题，将 DNS 服务器设置为 DoH 1.1.1.1 || 8.8.8.8 的用户/VPS 难以访问互联网 According to multiple reports, the issue appeared around September 5, and users/VPS with DNS servers set to DoH 1.1.1.1 || 8.8.8.8 had difficulty accessing the Internet

In #285 I started a new thread to talk specifically about RST injection for 1.1.1.1:443.

@flowerinsnowdh, one thing I wasn't sure about: is 8.8.8.8:443 blocked the same way as 1.1.1.1:443 is blocked (for you)? Or is 8.8.8.8:443 blocked in a different way, such as by packet dropping? I am trying to find out whether the blocking of 1.1.1.1:443 is its own event, or if it was coordinated with 8.8.8.8:443 at the same time and in the same way.

过一会我去测试一下，但是我已经可以确定的是 https://8.8.8.8/ 不可以访问

I'll test it in a bit, but what I can already tell for sure is that https://8.8.8.8/ is not accessible

flowerinsnowdh commented 9 months ago

根据多人报告，大约在9月5日左右出现了该问题，将 DNS 服务器设置为 DoH 1.1.1.1 || 8.8.8.8 的用户/VPS 难以访问互联网 According to multiple reports, the issue appeared around September 5, and users/VPS with DNS servers set to DoH 1.1.1.1 || 8.8.8.8 had difficulty accessing the Internet

In #285 I started a new thread to talk specifically about RST injection for 1.1.1.1:443.

@flowerinsnowdh, one thing I wasn't sure about: is 8.8.8.8:443 blocked the same way as 1.1.1.1:443 is blocked (for you)? Or is 8.8.8.8:443 blocked in a different way, such as by packet dropping? I am trying to find out whether the blocking of 1.1.1.1:443 is its own event, or if it was coordinated with 8.8.8.8:443 at the same time and in the same way.

访问 8.8.8.8:443 不会有任何响应

Accessing 8.8.8.8:443 does not result in any response