Jackie's Blog

探索区块链、自动化与开源技术

解决 Windows 无法挂载 HTTP WebDAV 的问题

当前市面上大多数网盘都可以挂载到 AList(或 OpenList)中。AList 支持 WebDAV 协议,这意味着我们可以通过 AList 提供的 WebDAV 服务,将网盘像本地磁盘一样挂载到系统中,实现文件的直接读写。

然而,在 Windows 系统中尝试挂载时,可能会遇到如下错误:

网络位置

挂载


问题原因

出现该问题的原因是 Windows 默认的 WebClient 服务仅支持 HTTPS 协议,而本地搭建的 WebDAV 服务通常基于 HTTP 协议,因此导致挂载失败。

对于部分用户来说,将 WebDAV 升级为 HTTPS 是更安全的选择,但对于仅在内网使用、对安全性要求不高的场景来说,启用 Windows 对 HTTP 协议的支持可能是更快捷的解决方案。


解决方案

步骤 1:修改注册表

  1. 按下 Win + R,打开“运行”窗口,输入 regedit,打开注册表编辑器。

  2. 导航到以下路径:

    1
    计算机\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
  3. 找到 BasicAuthLevel 条目,双击并将数值数据修改为 2,点击“确定”。

注册表

步骤 2:重启 WebClient 服务

  1. 再次按下 Win + R,输入 services.msc,打开“服务”窗口。
  2. 找到 WebClient 服务,右键选择“重新启动”。

服务

  1. 等待服务重启完成,或直接重启计算机。

成功挂载


旧评论:我改了注册表还是没用,在服务里看到WebClient被禁用,启动服务就能连上了。但是使用体验并不好,我试了复制几个100多M的文件到电脑,根本复制不过来,还是得到网页里下载。——来自refrain1128的评论


结语

通过以上步骤,Windows 便可以支持基于 HTTP 协议的 WebDAV 挂载,使内网环境下的网盘访问更加便捷。如果你有更高的安全需求,仍建议配置 HTTPS 以保障数据传输安全。

本文部分(图片)由AI辅助创作,请仔细辨别!
上回我们讲解了什么是 DNS 泄露,现在我们来讲讲如何预防与修复 DNS 泄露。

如何预防与修复 DNS 泄露?

1.预防 DNS 泄露的措施

预防 DNS 泄露是保障网络隐私的关键第一步。以下是几种有效的预防方法,下图清晰地展示了主要的决策路径。

决策路径

使用加密的DNS协议

采用 DNS over HTTPS (DoH) 或 DNS over TLS (DoT) 可以加密你的DNS查询,防止第三方窥探或篡改,即使在非VPN环境下也能提升基础安全性。许多现代浏览器和操作系统都内置了对这些协议的支持。

  • 配置方式:你可以在操作系统的网络设置或主流浏览器(如 Chrome、Firefox)的设置中启用 DoH 或 DoT,并指定一个可信的加密DNS服务器(例如 Cloudflare 的 1.1.1.1 或 Google 的 8.8.8.8,后续我可能也会推出DNS,欢迎合作与支持!)。

利用VPN集成防护

一个好的VPN服务是预防DNS泄露的最有效手段之一,因为它应该将你的所有网络流量(包括DNS查询)通过加密隧道路由。

  • 启用VPN的DNS保护功能:大多数商业VPN客户端提供“DNS泄漏保护”或“拦截非VPN DNS”的选项,请确保启用它。
  • 手动配置VPN客户端:对于OpenVPN等客户端,你可以在配置文件(.ovpn文件)中添加特定指令来强化DNS安全,例如使用 block-outside-dns (Windows) 来阻止所有非VPN隧道的DNS请求,以及 register-dns 来确保连接VPN后立即更新系统的DNS设置。

调整系统与网络设置

某些系统或网络配置可能导致DNS请求意外绕过VPN隧道。

  • 禁用IPv6协议(可选):因为VPN连接有时可能无法正确处理IPv6流量,导致DNS请求通过IPv6链路泄漏(即使VPN已接管IPv4流量)。在操作系统的高级网络设置中暂时禁用IPv6是一个可选的预防措施。
  • 定期更新固件:保持你的路由器、计算机网络驱动程序等设备的固件为最新版本,以确保已知的安全漏洞得到修补,这有助于维持网络栈的稳定性。

2.修复 DNS 泄露

即使采取了预防措施,定期检查并知道如何应对可能的泄露仍然很重要。

发现泄露后的立即应对措施

一旦确认存在 DNS 泄露,可以尝试以下方法快速解决问题:

  1. 清除本地DNS缓存:本地计算机保存的DNS缓存可能包含旧的或被污染的记录。清除缓存可以确保后续查询获取最新、最准确的解析结果。
    • Windows系统:以管理员身份打开命令提示符,输入 ipconfig /flushdns 并回车。
    • macOS系统:在终端中输入 sudo killall -HUP mDNSResponder 并回车。
  2. 重启VPN连接或更换VPN服务器:有时简单的重连可以解决临时的路由或DNS配置问题。
  3. 检查并确保VPN的DNS保护功能已开启:再次确认VPN客户端设置中的防泄漏开关是否处于打开状态。

长期解决方案

如果泄露问题持续存在,可能需要更彻底的解决方案:

  • 更换可靠的DNS服务器:将本地设备的DNS服务器地址手动更换为可靠、安全的公共DNS服务器(如 8.8.8.8, 1.1.1.1)。这可以在网络连接属性中设置。
  • 考虑更换VPN服务提供商:如果你使用的VPN提供商无法持续可靠地防止 DNS 泄露,投资一个以安全和隐私为核心、提供内置DNS泄露保护且经过独立审计的VPN服务是值得的。

3.高级配置与操作

对于技术能力较强的用户,可以考虑以下更深层次的配置:

  • 配置防火墙规则:你可以使用高级防火墙软件创建规则,阻止所有非VPN连接的网络适配器上的出站DNS请求(通常目的端口为53)。这可以强制所有DNS流量只能通过VPN虚拟网卡出去。

结尾

好了,本文到此结束,希望你能从中学到一些知识与技能。

如何发现 DNS 泄露?

1. 什么是 DNS 泄露?

DNS 泄露(DNS Leak) 是一种安全漏洞,它发生在用户试图使用虚拟专用网络(VPN)来隐藏自己的网络活动时,本应通过 VPN 安全隧道发送的 DNS 查询请求,却意外地被暴露给用户的互联网服务提供商(ISP)的 DNS 服务器或其他未受保护的第三方服务器。

基本原理与危害

DNS(Domain Name System)是互联网的“电话簿”,负责将我们输入的域名(如 www.google.com)转换为计算机可以识别的 IP 地址。通常情况下,当你使用 VPN 时,你所有的网络流量(包括 DNS 查询)都应该通过 VPN 服务器进行路由,这样你的 ISP 就无法看到你访问了哪些网站。

然而,当发生 DNS 泄露 时,DNS 请求没有通过 VPN 隧道发送,而是直接通过你的本地网络连接发送到了你的 ISP 提供的 DNS 服务器。这会导致:

  • 隐私暴露:你的 ISP 或其他第三方可以监控和记录你访问的网站,你的上网行为不再匿名。
  • 潜在风险:这些信息可能被用于针对性广告、网络钓鱼或其他恶意行为。

DNS 泄露与 DNS 劫持/污染的区别

需要注意的是,DNS 泄露不同于 DNS 劫持(DNS Hijacking)DNS 污染(DNS Pollution)

  • DNS 泄露:主要是隐私暴露问题,DNS 查询被意外发送到了你不想发送的地方(如你的 ISP),但解析结果本身可能仍然是正确的。
  • DNS 劫持/污染:是指 DNS 解析结果本身被篡改,将你试图访问的域名指向错误的、恶意的 IP 地址,可能导致你访问钓鱼网站或无法访问正常网站。

2. 如何检测 DNS 泄露

检测 DNS 泄露通常可以通过在线工具来完成。

常用检测方法

访问专门的 DNS 泄露检测网站(例如 browserleaks.com/dns,或者是 dnsleaktest.com)是最直接的方法。这些网站的工作原理如下:

DNS 泄露检测原理

当您访问检测网站时,该网站会随机生成多个唯一的、此前不存在的子域名。您的本机会将这些子域名的解析请求发送给您当前网络配置中使用的上游 DNS 服务器。由于这些子域名是全新的,在上游 DNS 服务器中不可能存在缓存,因此服务器必须进行递归查询,向其上游的多个 DNS 服务器发送请求,直到请求到达泄露检测网站所属的权威 DNS 服务器。此时,权威 DNS 服务器会记录下最终发起请求的源 DNS 服务器的 IP 地址。检测网站会收集这些 DNS 服务器的 IP 信息,并将其显示在您的浏览器中。

结果判断

  • 未发生泄露:如果检测结果中显示的所有 DNS 服务器 IP 地址都属于你所使用的 VPN 服务提供商 或你 手动配置的公共 DNS(如 Google DNS 8.8.8.8、Cloudflare 1.1.1.1 等),那么大概率没有发生 DNS 泄露。

未发生 DNS 泄露

  • 可能发生泄露:如果检测结果中出现了你所在地区 ISP(互联网服务提供商)的 DNS 服务器 IP,这意味着你的 DNS 查询请求绕过了 VPN,直接暴露给了你的 ISP,这就发生了 DNS 泄露。

可能发生 DNS 泄露

结尾

好了,文章就到这里了,下一章我们将讲解如何预防与修复 DNS 泄露。

0%