【教程|隐私安全|审查规避】配置安全 DNS 与安全 SNI 简易教程：补全 HTTPS 最后的安全拼图，预防 DNS 污染与 SNI 阻断（更新中） 其他工具 系统优化 APP IOS 技术教程

Tsurumaki_Kokoro 只看Ta 资源大神 举报
83 1

前言

P1

（本部分内容摘编自：节点订阅 β By ZGQ Inc.）

某些网站在国内地区无法访问，通常有三种可能：

  1. 网站已关闭。

  2. IP 被墙。

  3. DNS 污染。

一部分情况属于第 3 种，只是域名被 SNI 阻断，可通过以下方法解决此问题：

  • 修改设备的 hosts 文件。

  • 自定义 DNS 服务器。

    • 本作者注：此方法不会改变 DNS 请求与响应“以明文传输”这一特性，故不建议选择此方法。

  • 使用安全 DNS 与安全 SNI。

本教程将围绕着第三种方法展开。

注意： 诸如 Google 等网站和某些 APP 是直接被墙 IP，这种情况下只能在科学上网后访问。

P2

安全 DNS 和安全 SNI 是为了提升网络通信的隐私和安全而设计的，作用在不同的层面。

1. 安全 DNS

  • 代表技术：
    • DNS-over-TLS（DoT）
    • DNS-over-HTTPS（DoH）
    • DNSCrypt（DC）
    • Oblivious DNS-over-HTTPS（ODoH）
    • DNS-over-QUIC（DoQ）
  • 背景： 传统的 DNS 查询通常使用明文传输，这意味着用户的 DNS 查询请求（例如，用户访问的网址）对 ISP、中间人等都是可见的。这会暴露用户的浏览习惯，并可能被用于监视。
  • 工作原理： 安全 DNS 通过使用加密协议（HTTPS、TLS 或 QUIC 等）来加密 DNS 查询请求和响应。

2. 安全 SNI

  • 代表技术：
    • Encrypted SNI（ESNI）
    • Encrypted Client Hello（ECH）
  • 背景： 传统的 TLS 握手过程中，客户端发送的 Client Hello 消息包含一个名为 Server Name Indication (SNI, 服务器名称指示) 的字段，该字段以明文形式指示客户端要连接的服务器域名。这意味着即使用户使用 HTTPS 连接，ISP 和其他中间人仍然可以看到用户正在访问哪个网站。
  • 工作原理： ECH 通过加密包括 SNI 字段在内的整个 Client Hello 消息来解决这个问题。
    • 加密 Client Hello： 客户端使用服务器的公钥（从支持安全 DNS 的 DNS 服务器获取）加密整个 Client Hello 消息，包括 SNI 字段。
    • 解密 Client Hello： 服务器收到加密的 Client Hello 消息后，使用其私钥解密，获取 SNI 字段。

简单总结：

  • 安全 DNS 保护的是 DNS 查询 过程的隐私和安全。
  • 安全 SNI 保护的是 TLS 握手 过程的隐私。

P3：观前提醒

  • 本教程仅为配置安全 DNS 与安全 SNI 的简易操作指南。

  • ECH 较为新兴，目前仅有部分网站实验性地启用 ECH，本教程提供测试服务端是否支持 ECH 的方法。

  • 再次强调： 被墙 IP 的网站只能在科学上网后访问。

目录

1.1 配置安全 DNS

1.1.1 已知的 DNS 提供商

若读者知道其它列举 DNS 提供商的网站，欢迎在评论区补充。

1.1.2 观前提醒

多数服务商的 (O)DoH/DoT/DoQ 的 tls 证书是没有对 IP 地址签发认证的，必须写实际的域名，但也有一些 (O)DoH/DoT/DoQ 提供商可以直接使用 IP 作为主机名访问，例如 CloudFlare 的 1.1.1.1 和阿里云公共 DNS 的 223.5.5.5。（摘编自：DNS 服务 | 新 V2Ray 白话文指南）

大多数浏览器和操作系统的设置仅支持添加 (O)DoH 提供商。

GFW 对于境外 DNS 提供商，存在不同程度的干扰（轻则间歇丢包，重则封锁 IP），具体干扰程度通常与以下因素相关：

  • DNS 提供商的知名度。

  • DNS 查询所使用的端口号，853 端口（DoT/DoQ）相比于 443 端口（DoH/ODoH）受干扰程度更大。

请自行根据使用体验选择 DNS 提供商。可在以下网站中测试国内不同省（市）对某一 DNS 提供商的干扰程度：

1.1.3 浏览器设置

1.1.3(1) Chrome 与其它基于 Chromium 的浏览器

在“设置 -> 隐私和安全 -> 安全/安全性”中，启用“使用安全 DNS”并选择“添加自定义 DNS 服务提供商”，输入 (O)DoH 提供商的地址后回车。

1.1.3(2) Firefox 与其它基于 Mozilla Firefox 的浏览器

在“设置 -> 隐私与安全 -> 基于 HTTPS 的 DNS”中，启用策略选择“增强保护”或“最大保护”，随后在“选择提供方”中选择内置提供商或自定义提供商。

1.1.4 系统设置 (Windows 11)

在“设置 -> 网络和 Internet 设置 -> WLAN(无线局域网) -> 硬件属性”或“设置 -> 网络和 Internet 设置 -> 以太网”中，找到“DNS 服务器分配”并点击“编辑”，启用 IPv4 和按需启用 IPv6。在“首选 DNS”中输入 (O)DoH 提供商的纯 IP 地址，在“DNS over HTTPS”中选择“开(手动模板)”并输入 https://提供商的域名/dns-query，随后保存。

提示： 部分 (O)DoH 提供商的 URL 不以 dns-query 结尾，请自行参阅提供商的最新信息。

1.1.5 第三方软件

1.1.5(1) AdGuard Home

推荐使用该软件。

适用于：Windows、macOS 和 Linux。其它类型设备可修改 DNS 为正在运行 AdGuard Home 的设备的地址。

官网：AdGuard Home| 适用于任何操作系统（Windows，macOS，Linux）的网络软件。

官方 GitHub 项目地址：GitHub - AdguardTeam/AdGuardHome: Network-wide ads & trackers blocking DNS server。

无法访问 GitHub？尝试访问以下链接（由本作者手动上传至屋舍，仅有 Windows 和 Linux 的 amd64 版本且不保证更新）：

以 Windows 为例，下载完毕并解压缩后，运行 AdGuardHome.exe，随后在浏览器中输入 127.0.0.1:3000 （有可能是其它端口，具体请查看终端日志）。

点击“开始配置”。在步骤 2/5 中，网页管理界面（Web UI）监听端口建议选择一个非特权端口（1025-65535），DNS 服务器监听端口若无特殊需求则建议选择 53 端口，点击“下一步”。

在步骤 3/5 中，设置用户名和密码并点击“下一步”。

在步骤 4/5 中，根据 AdGuard Home 对当前设备和其它内网设备进行配置，随后点击“下一步”。

在步骤 5/5 中，点击“打开仪表盘”以结束初始配置。

在“设置 -> DNS 设置”中，分别在上游 DNS 服务器、后备（回落） DNS 服务器和 Bootstrap DNS 服务器中输入安全 DNS 提供商地址后点击“应用”。Bootstrap DNS 用于解析上游和后备 DNS 服务器的 IP 地址，其不支持输入域名，例如 udp://1.1.1.1、tls://1.1.1.1 和 https://1.1.1.1/dns-query，输入 DC 提供商的地址时不受此限制。

若仅希望 AdGuard Home 作为 DNS 解析器，将 AdGuard Home 设置为启动项后即算结束。AdGuard Home 的功能不止这些，但其它功能已脱离本教程的范畴，故若有需要请自行搜索有关 AdGuard Home 的更多“玩法”。

1.1.5(2) Simple DNSCrypt

目前不推荐用该软件，其最新更新于 2020/04/11，问题较多，详见该软件的 GitHub Issues。

适用于：Windows。其它类型设备可修改 DNS 为正在运行 Simple DNSCrypt 的设备的地址（需调整部分设置）。

官方 GitHub 项目地址：GitHub - bitbeans/SimpleDnsCrypt: A simple management tool for dnscrypt-proxy。

屋舍（由本作者手动上传）：

TBA。

1.1.5(3) RethinkDNS

适用于：Android。

官网下载页面：Downloads | Rethink，支持直链、F-Droid 和 Google Play 下载。

直接下载 .apk 文件（官方直链）： https://dl.rethinkdns.com/app 。

官方 GitHub 项目地址：GitHub - celzero/rethink-app: DNS over HTTPS / DNS over Tor / DNSCrypt client, WireGuard proxifier, firewall, and connection tracker for Android.。

不止 GitHub，官网也无法访问？欧尼酱真是个无可救药的杂鱼呢～♥️❤️（划掉） 尝试访问以下链接（由本作者手动上传至屋舍）：

RethinkDNS 不仅是一个提供安全的 DNS 解析服务的工具，亦是一个强大的防火墙工具。本章节仅涉及 DNS 配置，若有需要请自行搜索 RethinkDNS 防火墙配置相关内容。

TBA。

1.1.5(4) Nebulo

适用于：Android。其它类型设备可修改 DNS 为正在运行 Nebulo 的设备的地址（需调整部分设置）。

GitHub 项目地址（镜像）：GitHub - Ch4t4r/Nebulo: Mirror of https://git.frostnerd.com/PublicAndroidApps/smokescreen. Feel free to contribute here as well.，README 为英文版本，内含多种下载渠道。

屋舍（由本作者手动上传）：

Nebulo 专注于提供安全的 DNS 解析服务，配置难度相比于 RethinkDNS 较小。

TBA。

1.1.5(5) DNSecure

适用于：iOS。

在 App Store 中搜索 DNSecure，找到图标为“黄底白锁”的 DNSecure 并下载。若未找到软件，请在切换 App Store 的地区后再次搜索。

DNSecure 内置“Instructions”配置教程（英文，但有流程图）。

若需要添加自定义 DNS 提供商，在“左上角‘+’号 -> DNS-over-HTTPS/TLS”中，“NAME”自取；“SERVERS”填写提供商的纯 IP 地址，例如 1.1.1.1 和 2606:4700:4700::1111 （IPv6 地址在此处无需添加中括号），请确保填入的 IP 地址均来自同一提供商的同一 DNS 服务端；“SERVER URL”填写与“SERVERS”中的 IP 地址相对应的 URL，此处为 https://cloudflare-dns.com/dns-query。

1.2 配置安全 SNI

安全 DNS 配置完毕后，通常也意味着 ECH 配置完毕，这取决于浏览器和操作系统版本。同时注意：尽量避免使用知名度相对较低的 DNS 提供商。

2.1 测试客户端与服务端对安全 SNI 的支持情况

2.1.1 测试客户端

  • Cloudflare 的“浏览体验安全检查”：Cloudflare 浏览器检查 | Cloudflare。

    • 注意： 第一个结果（安全的 DNS）基本没有参考性。Cloudflare 仅可测出在使用自家的 DNS 解析器时的结果，使用其它 DNS 解析器时测试结果一律为问号。
    • 2.1.1_1.png

  • 一个专注于测试 ECH 的网站：Welcome to ECH!。该网站中亦有其它子域名，模拟在遇到某些异常情况时客户端是否依旧支持 ECH：

2.1.2 测试服务端

若读者知道其它测试方法，欢迎在评论区补充。

2.1.2(1) dns.google

需科学上网，若访问失败请尝试加上 https:// 前缀。

dns.google 是谷歌公共 DNS 解析器的网页。在“DNS Name”中输入待测试服务端的域名并点击“Resolve”，随后在左上角“RR Type”中输入“HTTPS”并再次点击“Resolve”。若响应中包含 ech=xxx，则意味着服务端支持 ECH。

2.1.2(1)_1.png

2.1.2(2) AdGuard Home

请确保准备访问待测试域名的设备的 DNS 指向正在运行 AdGuard Home 的设备的地址。

进入 AdGuard Home 的 Web UI，在“设置 -> DNS 设置 -> 日志配置”中勾选“启用日志”，随后点击“查询日志”。

切换设备（若没有多余的设备，直接新增浏览器分页且确保系统 DNS 配置正确亦可），访问待测试域名。访问完毕后，切换到 Web UI 界面并刷新，查询与测试域名相关的 HTTPS 类型的 DNS 响应，若响应中包含 ech=xxx，则意味着服务端支持 ECH。

2.1.2(2)_1.png

2.2 DNS 泄露测试

DNS 泄露测试在此处主要作用为测试是否存在因设备/程序/服务等绕过安全 DNS 导致的 DNS 请求与响应泄露给 ISP 与其它中间人的情况。假设使用境外安全 DNS 提供商，那么结果（DNS 出口）中不应存在国内 IP 地址。

3.1 FAQ

  • 在不使用 VPN 与代理时，中间人总能知道用户访问的 IP 地址，通过 IP 地址可推测出具体网站。这样看来，ECH 不就没有作用了吗？

    • 首先，“通过 IP 地址可推测出具体网站”这一点不成立。现代互联网广泛使用 CDN，这意味着存在多个网站共用同一个 IP 地址的情况，直接封锁 CDN 的 IP 将误伤大量正常网站，这亦是 GFW 使用 SNI 阻断的原因之一——实现选择性地高精度地阻断路由到单一 IP 地址的流量。

    • 其次，在 Client Hello 消息中，SNI 不是唯一的敏感信息，ECH 会加密整个 Client Hello 消息以解决 TCP 握手过程中几乎所有隐私问题。

参考资源

曲终人散，黄粱一梦，该醒了！
收藏的用户（0） X
正在加载信息~
最新回复 ( 1 )
发新帖