type
status
date
slug
summary
tags
category
icon
password
如需技术支持,请点击 👉 联系方式
1. 传统旁路由方案的弊端
在传统的旁路由(透明网关)方案中,为了能够科学上网,内网设备需要以旁路由为网关,然后旁路由以主路由为网关来让设备正常联网。在这种网络结构中存在多种弊端,比如说当旁路由下线或者宕机了,那么所有以旁路由为网关的设备将直接失去与外网的连接(如下图所示)。
在本文,作者将介绍一种可以完美替代旁路由结构的网络搭建方案,可以有效的提升网络的速度和稳定性,并且还可以在此基础上再进一步对内网的各种协议、终端等进行管控。
2. 网络拓扑出处
建议各位可以先去看一遍原作者的文章,了解其中的逻辑之后再回来对比着看。
本文参考其中的逻辑将其应用于以 unRAID 为虚拟平台的 iKuai + Openwrt 网络结构中,其他的 NAS 系统也是一样可以实现的。
2024-05-20:原作者在 Youtube 上出了一期关于本网络架构的视频教程,推荐大家都去看看(记得关注频道哦)。
3. 物理环境与网络环境介绍
需要说明的是,只有一台设备的情况下博主并不建议做 AIO。我之前将我唯一一台 Unraid 设备用作 AIO 运行了一年半最后放弃了,因为很影响家里的网络。
- 物理设备:使用设备为畅网 N5105(V3版),4 个 2.5G 网口(网卡型号为 Intel 的 i225-V ),虚拟机网口的分配和配置等请看下文。
- 底层平台:底层使用 unRAID 作为虚拟化平台(后期我改成了 iKuai 作为底层系统,下文有说明)。
- iKuai 虚拟机:作为主路由拨号(光猫已经设置为桥接)。
- Openwrt 虚拟机:科学上网。
- ISP:电信 300M 带宽。
4. 网络拓扑
原作者的网络结构如下:
博主根据其逻辑,整理出本文所实现的网络拓扑:
本文实现的网络结构本质上与原作者是一样的,读者朋友们需要理解其中的逻辑之后再根据自己的实际情况来实现(一开始不好理解,读者朋友们得多看几遍)。
4.1 节点设备说明
- 作者内网网段:
10.10.10.0/24
;
- iKuai :
WAN1
用于拨号连接到外网。LAN
地址是10.10.10.1
。WAN2
接口的网关指向 Openwrt 的LAN
地址:10.10.11.2
—>10.10.11.1
。
- Openwrt :
LAN
地址是10.10.11.1
。WAN
接口的网关指向 iKuai 的LAN
地址:10.10.10.6
—>10.10.10.1
。
4.2 目标效果
当 iKuai 网段下的设备(
10.10.10.X/24
)访问国内的 IP 时,正常走 WAN1
口访问外网;当访问的国外的 IP 时,借助 iKuai 的分流规则将访问国外 IP 的流量走 WAN2
口出去,也就是发送给 Openwrt 的 LAN
地址,然后 Openwrt 将数据加密后从它的 WAN
出去,也就是将流量发送到 iKuai 的 LAN
口,继而从 WAN1
口出去访问外网。iKuai 会实现初步的分流,然后当流量到达 Openwrt 时代理工具也会进行一次分流判断 —— 如果是国外的流量就走代理,如果不是在直连出去。
4.3 方案优势
- 完美替代旁路由方案:可以完美替代如今用的比较多的旁路由(透明代理)方案,不再需要单独的将设备的网关设置为旁路由的地址。
- 避免多次端口转发问题:避免了因旁路由而大致的多次端口转发的问题(从主路由转发端口给旁路由,再由旁路由转给对应的服务)。
- 国内外流量直接分流:借助 iKuai 的分流规则可以直接对国内国外的流量直接分流。
- 可以实现线路的冗余:如果 Openwrt 宕机了,也就是
WAN2
线路断了,iKuai 内可以设置自动切换线路到WAN1
正常联网。
- 可更好的利用 iKuai 的流控功能:除了分流之外,还可以更好的实现 QoS 等,并且还可以控制某个设备不走 Openwrt 代理。
4.4 缺点
- 需更新 IP :需要定期维护国内 IP 地址表,根据作者建议,半年更新一次即可。
- 不好维护:对于新手来说搭建起来会有难度,并且出问题时也不好维护。
5. iKuai 虚拟机配置和网口分配规划
iKuai 虚拟机的创建不难,到官网下载一个 ISO 安装文件(选择 32 位即可,64 位版本多一个虚拟机功能,但我们用不到),分配 1G 的虚拟硬盘安装即可,iKuai 的虚拟机安装步骤省略。
如果你是以 iKuai 作为底层系统,那么请一定选择 64 位系统进行安装。
由于我的 N5105 设备有四个网口,其中一个口被 Unraid 作为管理口使用不能进行直通,所以我这里将剩下的 3 个网口直通给 iKuai 虚拟机,并再多分配 1 个虚拟网卡:
直通的 3 个网口对应到物理设备的接线如下:
为什么将
eth0
与 eth1
直连:
eth0
是 unRAID 的管理口,eth1
与 iKuai 的 LAN 口,将两者直连的目的是为了能让 unRAID 既可以连接外网也可以在内网中被访问,这样的好处是可以不需要将 Unraid 的管理口接入到交换机,缺点是如果 iKuai 虚拟机关机了(或者宕机了),那么内网将无法访问 Unraid 。请读者自行斟酌。6. OpenWRT 虚拟机配置
固件我用的是 eSir 的佛跳墙旁路由固件(eSir 网盘),读者可以根据自己的喜爱来使用,没有限制。
OP 的虚拟机由于只用于走科学,不需要拨号,因此无需分配太多的资源,CPU 核心数可以看着给 2C/4C,内存 1G/2G 够用了。
OP 的虚拟机设置
需要提供两个虚拟网卡:
7. iKuai 系统内设置
7.1 WAN1
与 LAN
设置
根据前面的网络拓扑,在 iKuai 系统内分别将
WAN1
口和 LAN
配置好。WAN1
设置(用于正常拨号)
LAN
设置
链路桥接两个
LAN
口,这样网线无论插在两个口中的哪一个都可以正常访问到 iKuai。7.2 WAN2
设置
前面介绍 iKuai 虚拟机的配置时作者额外添加了一个虚拟网卡,那么这个虚拟网卡的作用是在 iKuai 内用于
WAN2
口。WAN2
配置
- 创建
WAN2
并绑定虚拟网卡;
- 接入方式使用
静态IP(固定IP)
;
- IP 地址设置为另一个网段的 IP,具体是什么地址随意,这里作者使用的是
10.10.11.2
(作者自己内网的网段是10.10.10.X
,所以用10.10.11.X
方便自己记住);
- 网关填写的是 Openwrt 的内网 IP 地址
10.10.11.1
;
- 将
WAN2
设置为默认网关;
- 使用线路检测功能,作用是当 Openwrt 离线了会切换到
WAN1
继续正常联网,这里填写的10.10.10.6
是 Openwrt 的WAN
地址。
7.3 添加分流规则
(1)添加 自定义运营商
添加一个 自定义运营商
,将国内 IP 网段加入到此自定义运营商中。
将下面链接内的 IP 地址段添加到新建的
自定义运营商规则
中(来自 17mon/china_ip_list
):由于 iKuai 内自定义运营商最多只能添加 5000 条目的地址,因此需要分两次添加:
添加国内 IP 地址段的目的是为了能在 iKuai 上分流,也就是当你发起一个访问时,iKuai 接收到你的数据包后会查看你访问的 IP 地址是国内的还是国外的:如果是国内的就走
WAN1
出去,国外的就发送给 Openwrt 走代理。(2)添加 多线负载
分流规则
多线负载配置
- 运营商选择之前添加好的自定义运营商。
wan1
线路负载比例设置为1
并启用(wan2
不需要启用),表示只要是访问的目的 IP 地址符合自定义运营商里面的记录值(国内 IP),那么就会走wan1
线路,也就是直联。
- 保存。
(3)添加 端口分流
分流规则防止 Openwrt 回环
端口分流配置
配置“端口分流”的作用是防止回环:因为前面我们已经设置了
多线负载
的功能,在这个功能下会实现 IP 分流,但如果说不为 OpenWRT 设置防环规则,那么就可能会出现 OP → iKuai → OP → iKuai → OP ….
的回环情况。添加一条端口分流规则:
线路选择
wan1
,负载模式如图,将 Openwrt 的 wan
地址(10.10.10.6
)设置分流的对象,表示 iKuai 在接收到 OP 的数据包时直接发往运营商线路出去:7.4 iKuai DNS 设置
2024-03-20 补充:关于 DNS 这一块的问题,博主在第 13 章内容中提供了一个搭建 DNS 服务器的方法,大家感兴趣的可以去看看。
由于作者在 Openwrt 中使用 OpenClash 会自带有 DNS 服务器,所作者将 iKuai 的 DNS 服务器设置为 Openwrt 的
WAN
地址( 10.10.10.6
),读者朋友们可根据自己的实际来设置。iKuai DNS 设置
作者之所以将 iKuai 的 DNS 服务器设置为 OP ,是希望借助 OpenClash 的 DNS 功能去避免 DNS 污染的问题,读者朋友其实可以不去这么做,可以直接在 iKuai 上使用公共的 DNS 的即可,例如:
7.5 iKuai 添加 NAT规则
在“网络设置 - NAT 规则”中添加规则,来让 OpenWRT 里面正确显示源 IP 地址。
如果不添加次规则,那么你会在 OP 里面发现所有发送到 OP 的设备的 IP 地址都会显示为 iKuai
wan2
口的 IP 地址,而不是某个具体设备的 IP 地址。- 动作:选择“过滤”,表示不做 NAT 。
- 出接口:选择
wan2
,也就是说被分流发往wan2
的数据包不对其数据包内的源 IP 地址进行更改。
- 协议:选择任意。
- 最后保存。
8 Openwrt 系统内设置
8.1 LAN 设置
LAN
设置
LAN 口的设置只需要保证设置好 IP 地址和子网掩码即可,不需要填写 DNS 。
LAN
的其他设置参考
8.2 WAN
设置
WAN
设置
WAN 口的设置需要填写好 IP 地址、子网掩码和网关,然后 DNS 服务器可以填写公共的 DNS ,也可以填写你在其他地方设置的 DNS 服务器。
WAN
其他设置参考
8.3 防火墙设置
(1)新建 WAN
区域转发规则
新建 WAN
区域规则(如果你用的 OpenWRT 固件里面已经配置好了 WAN
防火墙,那么这里可以跳过)
名称设置为
wan
,设置如下:然后将
WAN
口的防火墙设置绑定到所创建的区域中:(2)防火墙 - 基本设置
防火墙设置
(3)防火墙 - 自定义规则
防火墙自定义规则参考
上图中的第一条规则的作用与防火墙基本设置中的“IP 动态伪装”是一样的,所以这里你可以在行首添加上
#
来注释掉此规则。其余规则的作用是将 DNS 请求转发到本地的 53 端口。这里作者也选择注释掉,因为作者使用 Openclash 可以实现本地 DNS 劫持,所以不需要这里的规则:
如果你代理工具或者其他的 DNS 工具没有实现这一效果,建议你将 2~4 条规则启用(去掉#
),表示劫持 DNS 请求到 OpenWRT 本地的 53 端口。
8.4 DHCP/DNS 设置
关闭“重绑定保护(rebind protection)”
9 使用体验
经过以上设置之后,整体网络就搭建完成了,这里说一下使用体验。
9.1 网络流畅度提升
最大的体验是速度变快,网络访问变得流畅。
由于 iKuai 分流的作用,路由变得更加明确,因此整体网络的流畅度也得到了提升,并且无论是走国内流量还是走国外流量,都能够跑满带宽。
以作者的电信 300M 宽带为例,梯子测速和国内流量下载等都可以跑满带宽:
9.2 网络更加稳定
如果使用以前的旁路由方案,如果当旁路由掉线,那么所有以旁路由为网关的设备都将直接断网。
采用了本方案之后,即使旁路由崩掉了,那么后果也只是无法科学上网而已,不影响整体网络的可用性。
9.3 端口映射问题得到解决
按照以前的旁路由方案,如果某一个设备以旁路由为网关且希望暴露某一个服务到公网上,那么就得从主路由做端口映射到旁路由,再从旁路由映射端口到对应设备上,采用了本方案后此问题不再存在。
9.4 网络更可控
结合 iKuai 的各种流控规则,可对家里的网络进一步调控,比如可控制各种网络协议、限流限速,还可以控制哪些设备不可以走代理等。
iKuai 使用 端口分流
控制局域网内 IP 不走代理
由于我们借助WAN2
口实现了请求转发给 OP 的作用,因此我们也可以借助 iKuai 的端口分流
将不需要走代理的 IP 流量绕过WAN2
线路。
新建一条端口分流规则:
- 分流方式选择
外网线路
;
- 线路选择
WAN1
,也解释拨号的线路;
- 线路绑定;
- 负载模式选择
源 IP + 目的 IP + 目的端口
,如果效果不佳可以选择源 IP
;
- 协议选择
任意
;
- 在
源地址
中添加你希望不走代理的 IP 地址,也可以借助 iKuai 的分组功能实现 IP 分组;
- 最后保存规则即可。
10. 常见问题
Q:在此结构下,如何能保证正常访问 unRAID ?
A:取消
eth0
与 eth1
接口的直连,将这两个口单独用网线与交换机相连,这样即使 iKuai 崩掉了也能够正常访问到 unRAID 。在作者的这个案例里,我用一根网线将 unRAID 的管理口与 iKuai 的 LAN 进行了直连,这种方式会存在一个缺点,那就是假如 iKuai 崩掉了,那么 unRAID 就无法访问。所以读者朋友们如果担心这种情况发生,那么取消直联,将 unRAID 的管理口接入到交换机或者充当了 AP 功能的路由器的网口即可。
Q:openWRT 如果宕机了会不会网络就不可用了?
A:不会。
OP 宕机了,那么 iKuai 会自动切换到
wan1
线路保证可以正常连接网络(前提是你在 wan2
线路里面勾选了自动切换设置),不会出现网络不可用的情况,仅仅只是无法科学上网而已。Q:如何控制哪些 IP 不走代理?
A:详见 9.4、网络更可控 。
Q:如果我的设备只有两个网口,那么能否实现本文所说的网络结构?
A:可以实现。
具体的操作方法参考 11. 2023-07-24:底层由 unRAID 替换为 iKuai 系统 的章节末尾补充内容。
11. 2023-07-24:底层由 unRAID 替换为 iKuai 系统
由于
i225-v
网卡在 unRAID 上存在速率不稳定且会出现断流的情况(主要是由于 Intel 导致的驱动问题),已将底层的 unRAID 替换为 iKuai 系统,但整体的框架依然是一样的。替换为 iKuai 之后,在 iKuai 上虚拟化一个 OP 系统,然后再按照本文 unRAID 的方法去部署即可,逻辑是是一样的。更换为 iKuai 之后已经使用一段时间,目前一切稳定,没有出现
i225-v
网卡常见的断流、重启等问题,带宽也都能跑满。如果你也希望使用 iKuai 作为底层系统,在 iKuai 上虚拟化一个 OP 来使用,那么博主大致说一下步骤。
在 iKuai 中绑定一个物理网用于创建与 OP 通信的 WAN 口,创建 OP 虚拟机时候提供两个虚拟网卡,这两个虚拟网卡在 OP 里面用作一个 WAN 口一个 LAN 口,具体设置跟本文正文是一样的:
接着 iKuai 所创建的 WAN 口与 LAN 口连接起来。这里说的连接起来是指 WAN 口与 LAN 口能够互相访问,你可以用一根网线将 WAN 与 LAN 口直连起来,如果你设备上的 LAN 口数量不足,那你也可以将 LAN 口用网线接到交换机,让后也将 WAN 口连接到交换机,这样 LAN 就可以与 WAN 通信。
补充:只有两个网口的情况下该如何实现第二个 WAN 口。
如果你的软路由只有两个网口,那么也就是说只能一个用于 WAN 口拨号,另一个口用于 LAN 口,那么这时候就没有多余的物理网口用于绑定另外的 WAN 口实现 IP 分流到 OpenWRT 虚拟机上。
但是 iKuai 是可以创建一个虚拟 WAN 口进行使用的,你可以按照下面的步骤来实现:
WAN2
口绑定到Kvm Virtual Bridge Ethernet Controller
;
- 设置好 IP 地址、子网掩码和网关(网关 IP 是 openWRT 虚拟机里面的
LAN
口 IP 地址)
接下来创建 openWRT 虚拟机并添加虚拟网卡的时候,请记得将其中一个虚拟网卡绑定到
WAN2
口,另一个网卡绑定到 LAN
口:绑定了
WAN2
的那个虚拟网卡在 openWRT 虚拟机里面用作 LAN
口,绑定了 LAN
的虚拟网卡在 openWRT 虚拟机里面用于 WAN
口,如下图所示:12. 2023-09-20:关于本网络结构下的 DNS 请求以及 OpenClash 的补充说明
2024-03-20 补充:关于 DNS 这一块的问题,博主在第 13 章内容中提供了一个搭建 DNS 服务器的方法来配合这个网络架构使用。
在前文关于 iKuai DNS 设置中作者提到了由于本人使用 OpenClash,因此在设置 iKuai 的 DNS 服务器地址时我设置为了 OP 的
WAN
地址,意思也就是说通过 OpenClash 去处理内网下的所有 DNS 请求。这么做的好处是可以利用 OpenClash 的各种规则去实现关于分流、DNS 防污染等效果,但缺点是如果 OP 宕机了(或者说 OpenClash 出问题无法使用)那么就无法处理内网下的 DNS 请求,从而造成无法正常联网,会出现比如说 QQ 可以正常登录但是无法访问网页的情况。
其实关于 DNS 这一块的内容其实有不少可以注意的点,因此本章节会补充关于此问题的一些信息。
需要说明的是,本章节默认读者已经对 OpenClash 有一定的了解了,因此省略掉关于 OpenClash 一些基本知识的讲解。
(1)建议使用 Redir-Host
模式。
其实
Redir-Host
比 Fake-IP
模式缺点要多一些,不仅需要多做一次 DNS 解析,而且还存在 DNS 污染的可能。但是由于此网络结构下 iKuai 可以借助 IP 来实现分流,所以我还是选择了使用 Redir-Host
模式,这样在内网设备对解析回来的 IP 发起请求时,iKuai 就能拿到目标 IP 地址去做一次分流。相反的,如果使用的是
Fake-IP
,那么由于 OpenClash 会在客户端发起域名解析请求时会返回一个内网 IP ( 192.18.x.x
),所以 iKuai 自然也就没有办法实现分流,而是只能由 OpenClash 负责所有的分流功能,这相当于自废了一部分“武功”。而且使用
Fake-IP
还会造成另一个问题,那就是如果你使用 IDM 下载器,你会发现下载时有“卡顿”的情况。那是因为 IDM 在发起多线程下载的时候,由于发起下载请求的 IP 地址是 Fake-IP
返回的内网 IP ,所以在多线下载时就会出现“卡顿”的现象。(2)关于 DNS 污染问题。
理论上,使用运营商提供的 DNS 服务器来做域名解析速度是最快的,但是运营商的服务器往往存在 DNS 污染的情况(作者这边就是这样的),所以如果你比较在意 DNS 污染问题,那其实你也可以使用 OpenClash 的 Fake-IP 模式,并且博主也建议你安顺序去看以下视频了解更多关于 DNS 污染的原理:
- 【进阶•DNS泄漏篇】竟能提速降延迟!再也不用担心DNS污染了!90%以上的人都存在DNS泄露!会有什么安全问题?如何解决代理中的DNS泄漏问题?以及WebRTC绕过代理泄漏本机真实IP,看完就知道了
- 【DNS泄露】实战演示DNS泄漏,全局模式就不会dns泄漏?解答DNS泄露的争议,最简单clash配置DNS方法,fakeip到底会比realip提升网速吗?跨境电商网络环境要求高该如何防止DNS洩露
当你认真看完上述的视频之后,你就了解 DNS 污染是什么意思了,并且如何应对也都清楚了。
然后可以补充的是,在 Redir-Host 模式下,建议大家可以在 OpenClash 中这么去设置 DNS:
- 开启“自定义上游服务器”:
- NameServer 中填写上公共 DNS 地址:
这里推荐大家使用腾讯或者阿里的 DNS-over-HTTP/3 服务器地址:
添加的时候记得勾选上“强制 HTTP/3”:
其他更多关于 DOH 或者 HTTP/3 公共 DNS 服务器的信息可以参考:
(3)将 DNS 服务器地址设置为 OP 也存在网络稳定问题。
这是因为如果将 iKuai 的 DNS 服务器地址设置为了 OP 的 WAN 地址,那么当 OP 或者 OpenClash 出现问题时,内网将无法正常解析 DNS 请求,那么也就会造成网络无法正常使用的,从而会出现诸如微信或者 QQ 可以使用但是无法打开网页的情况。
如果你不希望面对此种风险的话,你可以将 iKuai 的 DNS 服务器地址设置为其他的公共 DNS 服务器,例如:
记得勾选上“DNS 加速服务”,否则其他设备将其 DNS 服务器地址设置为 iKuai 的 IP 地址时将无法实现域名解析。
或者:
(4)如果你使用的是 Fake-IP
模式,请不要使用端口分流来实现局域网 IP 不走代理。
前面在“9.4、网络更可控”讲解过使用 iKuai 的端口分流功能可以控制某个 IP 或者 IP 段不走代理,这个方法在 OpenClash 下的
Redir-Host
模式下是有用的,但是如果你使用的 Fake-IP
模式,那么这时候就不能这么用了,因为会导致被分流的 IP 无法上网。原理是由于
Fake-IP
模式在处理 DNS 请求时返回的是一个内网 IP 地址而不是真实的 IP 地址,所以后续内网的设备需要与 OpenClash 通信才能正常联网,而如果强制分流不走 OP 的 WNA2 口,那么被端口分流的 IP 就无法正常联网了。13. 2024-03-11:方案回顾与 DNS 解析服务器搭建(方案最后一块拼图)
各位新年好,先祝大家新的一年心想事成,万事如意!
距离本篇文章的发布也差不多过去了一年的时间,我了解到不少朋友第一次进到我的博客就是从这篇文章进来的,在 Google 显示的搜索排名里面,这篇文章也是占我博客热度的第一名,看得出来大家对这个网络架构比较感兴趣。
因此为了能更好的帮助大家搭建好这一套网络架构,本章将会回顾这个网络架构的一些细节以及优化 DNS 这一块的流程。
13.1 回顾
(1)使用体验
我说下我自己的使用体验。这个网络架构从我写这篇文章之前就一直使用至今,使用中也是一直观察和进行优化,可以说只要不是硬件有问题或者瞎折腾,基本上网络是不会出什么问题的。
唯一一次“事故”是由于我操作不慎,造成了广播风暴使得我的整个硬件设备出现了 CPU 过载,系统无效应不可操作,从而造成了家里的网络瘫痪。
但由于搭建起来有一定的难度,所以在我发布这篇文章之后有过不少网友(包括评论区)跟我咨询搭建过程中的一些问题该如何解决。
其实想要搭建好这个网络,最重要的是能理解这个架构的逻辑,只要能理解好这个逻辑,不管你用的是什么底层平台(PVE、ESXI 或是 Unraid 等)都能实现本篇文章所介绍的效果。
(2)架构逻辑
在文章的开头,我介绍了使用旁路由(透明网管)的一些弊端 —— 当所有流量都发送给旁路由的情况下,一旦旁路由出现宕机之类的情况,那么所有以旁路由为网关的设备将直接失去网络连接,而本篇文章所介绍的网络架构就是为了解决此问题而出现的。
这个架构的逻辑其实很简单,就是根据数据包的目的 IP 地址来判断是否需要进行分流 —— 也就是走代理还是走国内直连,这样就避免了旁路由模式中将所有的数据都发给旁路由的问题。
而 iKuai 的
多线负载
功能就可以实现这一目的。我们通过设置一个 自定义运营商
来添加国内 IP 地址网段,然后提供给 多线负载
功能作为 IP 分流依据:- 当数据包目的 IP 地址属于
自定义运营商
内的 IP 地址(也就是国内 IP),那么直联访问;
- 当数据包的目的 IP 地址不属于
自定义运营商
内的 IP 地址(也就是国外 IP),那么就将数据包发送给 iKuai 里面的 OpenWRT 虚拟机,由里面的代理工具进行处理之后再发往 iKuai 。
逻辑如下图所示:
在这个网络架构里面,发送给 OpenWRT 的线路是这个架构下的默认线路,换句话说就是所有 iKuai 接收到的数据都会默认发往 OpenWRT ,但因为有了多线负载
功能,在走默认线路之前数据包会进行国内国外流量的分流。
同时即使 OpenWRT 出现了问题,那么也不影响整体的网络可用性,因为 iKuai 里面可以实现线路的自动切换,所以 OpenWRT 不能使用了那也仅仅只是不能走代理而已。
但如果说 OpenWRT 还负责内网的 DNS 解析工作,那么 OpenWRT 不能正常使用的情况下会造成内网设备联网不正常,这也是此章节所要解决的重点问题。
(3)DNS 解析问题
前面说过,这个网络结构下会依据数据包的目的地 IP 地址来进行分流,但正确分流的前提是能够获取到正确的 DNS 解析,如果说 DNS 解析出来的 IP 地址是不正确的(比如说 DNS 污染),那么就可能会造成不能正确分流。
在上面的“关于本网络结构下的 DNS 请求以及 OpenClash 的补充说明”内容中博主提到,由于我将内网下的 DNS 请求交由 OpenClash 处理,所以假如说 OpenClash 出问题(或者说 OpenWRT 出问题),那么内网就无法处理 DNS 请求,就会造成设备无法正常联网的情况。而且在我们这个网络架构下,OpenClash 负责内网 DNS 请求的情况下是无法使用 Fake-IP 模式的,这也会在一定程度上影响使用体验。
DNS 服务器出问题导致的一个常见现象就是 QQ 或者微信等 App 可以正常使用但是网页打不开。
13.2 解决 DNS 解析问题的方案
为了解决此问题,经过一段时间的使用,博主目前实验出了一套比较好用的方案,简单来说就是在 iKuai 中虚拟化一个 Linux 系统并搭建 PaoPao DNS ,将其作为这个网络架构下的 DNS 解析服务器,并且利用其 DNS 分流功能优化 DNS 解析流程,最终从根本上弥补本方案的不足。
(1)结构图
(2)架构说明
- 内网设备发起域名解析请求:内网设备访问某个域名时,向 PaoPao DNS 服务器发起 DNS 解析请求;
- PaoPao DNS 服务器处理请求:PaoPao 接收到 DNS 解析请求,根据内部的域名库判断此域名是否是国外域名:
- 如果是国外域名:那么发送给 OpenClash 的 DNS 监听端口(7874)进行解析,在 Fake-IP 模式下 OpenClash 直接返回 fake ip 给 PaoPao,PaoPao 再返回给解析结果;
- 如果不是国外域名:那么直接在本地进行解析,直接返回解析结果;
- 数据包发往网关:设备获取到 DNS 解析出来的 IP 地址,将其封装到数据包发送给网关 iKuai ;
- iKuai 进行 IP 分流:iKuai 接收到数据包后检查里面的目的地 IP 地址,根据
多线负载
的自定义网络运营商来进行分流: - 如果目的 IP 属于国外 IP:发送给 OpenClash ,OpenClash 与代理服务器建立链接走科学;
- 如果目的 IP 不属于国外 IP:那么走直联;
(3)补充说明
- 博主使用的是 OpenClash 的 Fake-IP 模式:在博主的使用环境中,我的 OpenClash 采用了 Fake-IP 模式。在先前的文章里面博主提到不建议使用 Fake-IP 模式,那是因为当时 DNS 的解析由 OpenClash 负责,使用 Fake-IP 会造成域名解析无法分流(区分国内国外进行解析),也就造成了所有流量都会流向 OpenClash 的情况,但是现在有了 PaoPao 之后就不存在此问题了。但是使用 Fake-IP 模式需要处理不少细节,所以从易用性角度来说,建议读者们使用 Redir-Host 模式,并且如果大家经常使用游戏平台,比如 Steam、橘子平台、Epic 平通、Xbox 或者 PS 等,那么最好也是使用 Redir-Host 模式。
- 建议单独搭建 PaoPao DNS 服务器:由于作者使用的是 iKuai 作为底层系统,所以我选择了在 iKuai 里面再添加一个虚拟机来搭建 PaoPao DNS,读者可以根据自己的实际情况把 PaoPao DNS 搭建在其他的平台上面。你也可以将 PaoPao DNS 部署在独立的设备上,比如说树莓派,这样可以实现最大化的冗余。
- 不要让 PaoPao DNS 服务器走 IP 分流:需要注意的是,由于我们当前这个架构有 IP 分流(多线负载)的功能,所以需要将 PaoPao DNS 服务器的 IP 地址加入不分流的名单,换句话说可以通过 iKuai 上面的
端口分流
功能指定 PaoPao DNS 走运营商线路出去(方法参考下文的 13.4 章节内容),因为权威DNS需要准确的 IP 去判断,IP 分流会影响权威 DNS 的判断。
13.3 PaoPao DNS 搭建
PaoPao DNS 是一个递归 DNS 服务器,它针对 China 大陆,还有智能根据 CN 分流加密查询的功能,也可以自定义分流列表,可以自动更新 IP 库,分流使用了 mosdns 程序,加密查询使用 dnscrypt 程序,针对 IPv4/IPv6 双栈用户也有优化处理。
PaoPao DNS 的作用就相当于你把 114 搭建在了自己家里,你再也不需要使用 114 或者 223 之类的公共 DNS 服务器了,而且解析速度比公共的 DNS 服务器更快。
PaoPao DNS 可以通过 Docker 进行快速部署,你只需要调整好相应的变量就可以直接部署到设备上。考虑到本方案的网络架构稳定性,我没有选择将 PaoPao 搭建在 OpenWRT 里面,而是另外再虚拟化一个 Linux 系统进行部署。
而 Linux 这一块我选择了 Alpine :Alpine 是一个以安全为导向的轻量级 Linux 发行版,基于 musl libc 和 busybox ,它具有体积小、资源消耗低等特点。
Apline 有专门用于虚拟机环境的
.iso
系统安装镜像(下载地址),我下载的 x86 架构的虚拟机安装镜像大小只有 60M ,非常适合用来搭建 PaoPao DNS 。参考:安装并初始化 Alpine 的流程
由于博主使用的是 iKuai 系统,所以这里就以 iKuai 作为底层系统介绍 Alpine 虚拟机的安装过程。根据 PaoPao 作者的建议,Docker 部署下的环境要求如下:
docker 的运行家用建议内存 2G ,企业环境建议 16G ,再大了意义不太大(实际内存占用差不多达到 4G 已经很厉害了,当然,内存越大性能越好,命中率体验更棒),容器启动的时候会根据可用内存调整配置文件参数,占用内存不会超过上限。根据 Github 的使用者反馈,有最低 512M 内存的 ARM 路由器流畅使用的案例。实际上,在最低参数启动下的缓存也是能满足家庭使用需求的。
1️⃣ 在 iKuai 文件管理中新建一个文件夹用来存放 Alpine iso
安装镜像以及虚拟硬盘,然后获取 iso 镜像文件路径。
复制镜像文件地址:
2️⃣ 新建虚拟机
添加虚拟机:
- 系统类型:Linux ;
- CPU 核心数:给到两核心差不多了,CPU 核心数多的话可以多给一点也无所谓;
- 虚拟机内存:家庭环境给到 2G 即可,其他的可以参考前面 PaoPao 作者的建议;
- 虚拟机光驱:将前面复制的文件路径地址粘贴到这里面;
- UEFI 启动:开启。
添加虚拟硬盘:
- 开启“半虚拟化模式”。
- 虚拟硬盘给个 2G 或 3G 即可(如果你还想在 Alpine 中安装别的东西那就给多一点)。
- “磁盘名称”就是存放虚拟硬盘的位置,将其存放到与 iso 镜像文件一直的路径即可,虚拟硬盘名称可以参考图片里的命名。
添加虚拟网卡:
开启虚拟机:
3️⃣ 初始化 Alpine
启动 Alpine 虚拟机之后,输入
root
会车登录到命令行界面:接着按照下面的步骤进行系统的初始化配置:
- 输入
setup-apline
命令进入初始化流程。
- 选择选择键盘类型:输入
cn
;
- 选择选择键盘类型:继续输入
cn
;
- 配置系统
hostname
:直接回车使用默认值即可;
- 选择网口:按下回车键使用默认的
eth0
即可;
- IP 地址获取方式:按下回车键使用 DHCP 获取 IP 地址方式;
- 是否需要对网络进行自定义配置:按回车使用默认值
n
,不做自定义配置;
- 设置 root 用户密码;
- 设置时区 - 1:输入
Asia
;
- 设置时区 - 2:输入
Shanghai
;
- 是否设置 http/ftp 代理:按回车使用默认值
none
,不使用代理;
- 设置 APK 安装包镜像地址:按下回车使用默认值,我们后续再进行修改;
- 是否创建用户:按下回车键使用默认值
no
;
- 是否使用 openssh 作为 ssh 服务:按下回车使用默认值
opencssh
;
- 是否允许 root 用户使用密码登录:输入
yes
;
- 为 root 用户输入密钥或者 url 地址:按下回车键表示不设置;
- 选择安装盘:输入虚拟硬盘的名称(如
vda
);
- 硬盘用途:输入
sys
表示用作系统盘使用;
- 是否清空硬盘数据并进行安装:输入
y
表示格式化硬盘并安装系统文件;
- 此时系统安装已经完成。
此时输入
poweroff
命令关闭系统,然后编辑 iKuai 虚拟机,把安装镜像去掉并启动 Alpine 虚拟机:4️⃣ 配置 Apline 并安装 Docker 服务
打开虚拟机,输入
ifconfig
命令查看 Alpine 当前的 IP 地址:(1)设置固定 IP 地址以及修改 DNS 服务器
此时可以通过 SSH 工具登录到 Alpine,然后通过下面的步骤更改为静态 IP 地址。
Alpine 自带有vi
命令可以进行文本编辑,如果你需要使用nano
命令,可以通过apk add nano
来安装。
设置静态 IP 地址的格式如下:
修改好 IP 地址之后,使用下面的命令重启网络来生效:
修改下面的配置文件来修改 DNS 服务器:
可以参照下面的格式来添加公共 DNS 服务器:
如果你已经搭建了好 PaoPao DNS,那么实际上你也可以将这里的 DNS 服务器设置为本机地址(
127.0.0.1
),这样表示使用本机的 PaoPao DNS 服务器进行解析:(2)更改 APK 镜像源
使用下面的命令将 Alpine 的 APK 镜像源设置为中国科技大学的镜像源:
更新 apk 安装包:
(3)安装 Docker
输入以下命令检查 docker 是否已经正确安装:
将 docker 服务设置为开机启动:
(4)修改 Docker 镜像源
复制粘贴下面的命令运行:
修改好之后重启 Docker 服务:
检查镜像源是否已经添加上:
搭建好 Alpine 之后,参考下面的参数搭建 PaoPao DNS :
docker-compose 搭建
参数说明(更多参数请查看 Github 仓库 )
CNAUTO
:是否开启 CN 大陆智能分流,如果位于境外可配置为no
;
IPV6
: 仅在CNAUTO=yes
时生效,是否返回 IPv6 的解析结果,默认为no
,如果没有IPv6环境,选择no
可以节省内存。- 设置为
yes
返回 IPv6 的查询(为分流优化,非大陆双栈域名仅返回 A 记录)。 - 如果设置为
only6
,则只对 IPv6only
的域名返回 IPv6 结果。 - 如果设置为
yes_only6
,则对大陆域名返回 IPv6 的解析结果(相当于yes
),对非大陆域名只对 IPv6only
的域名返回 IPv6 结果(相当于only6
)。 - 如果设置为
raw
,则不对IPv6结果做任何处理,直接返回原始记录。
CNFALL
:仅在CNAUTO=yes
时生效,在遇到本地递归网络质量较差的时候,递归查询是否回退到转发查询,默认为yes
。配置为no
可以保证更实时准确的解析,但要求网络质量稳定(尽量减少 nat 的层数),推荐部署在具备公网 IP 的一级路由下的时候设置为no
; 配置为yes
可以兼顾解析质量和网络质量的平衡,保证长期总体的准确解析的同时兼顾短时间内网络超时的回退处理。
USE_MARK_DATA
:该项默认值为no
,当设置为yes
的时候,将会自动更新下载预先标记处理的全球百万域名库,在判断大陆分流的时候优先使用该数据,该功能仅标记数据,后续如何处理取决你的设置(比如默认分流或者自动转发)。域名数据库来源于paopao-pref
项目定期更新。该功能:- 优点:可以优化DNS泄漏问题、提供更快速精准高效的分流
- 缺点:会占用更多内存,增加容器启动时间
CUSTOM_FORWARD
:仅在CNAUTO=yes
时生效,将force_forward_list.txt
内的域名列表转发到到CUSTOM_FORWARD
DNS服务器。该功能可以配合第三方旁网关的 fake ip ,域名嗅探 sniffing 等特性完成简单的域名分流效果。这里的openclash的IP地址:7874
指的是 OpenWRT 的 7874 端口,也就是 OpenClash 的 DNS 监听端口,也就是说当 PaoPao DNS 发现所请求的域名属于国外的域名时,就会将其发送给 OpenClash 进行解析:
AUTO_FORWARD
:仅在CNAUTO=yes
时生效,配合CUSTOM_FORWARD
功能使用,默认值为no
,当设置为yes
的时候,解析非 CN 大陆IP的域名将会直接转发到CUSTOM_FORWARD
所设置值的 IP 设备。
TZ
:时区。
HTTP_FILE
:http 静态文件服务器端口,设置为yes
之后可以通过浏览器访问http://ip:7889
访问到 PaoPao DNS 的配置文件 。
DNS_SERVERNAME
:DNS的服务器名称,你使用windows的nslookup的时候会看到它。
SOCKS5
:为分流非 CN IP 的域名优先使用 SOCKS5 查询(如10.10.10.8:7890
,强制使用 socks5 查询则加上@
,比如@10.10.10.8:7890
),但没有也能查,非必须项。仅在CNAUTO=yes
时生效。SOCKS5 初始化会有大概 3 分钟的延迟连接测试过程,期间的解析结果并非最优延迟。
CN_TRACKER
:仅在CNAUTO=yes
时生效,默认值为yes
,当设置为yes
的时候,强制trackerslist.txt
里面 tracker 的域名走 dnscrypt 解析。更新数据的时候会自动下载最新的 trakcerlist 。该功能在一些场景比较有用,比如AUTO_FORWARD
配合 fakeip 的时候可以避免使用 fakeip 连接 tracker 。
SAFEMODE
:安全模式,仅作调试使用,内存环境存在问题无法正常启动的时候尝试启用。
搭建好 PaoPao DNS 之后,你需要先给 PaoPao 指定一个固定线路出口避免被分流(参考下文的 13.4 章节内容),再通过下面的命令简单验证所有 DNS 组件是否工作正常:
如果测试正常,那么你会得到
ALL TEST PASS
的输出结果:如果显示
FAIL
,可以执行 debug.sh
进一步分析原因:13.4 调整此网络结构下的 DNS 配置
当我们安装好 PaoPao DNS 服务器之后,我们需要对此网络结构进行如下调整。
(1)使用 端口分流
给 PaoPao DNS 服务器指定出口线路
注意:
如果 iKuai 的
网络设置 - DNS 设置
里面开启了 强制客户端DNS代理
,那么请关闭,否则会影响 PaoPao DNS 服务器的正常工作。由于权威 DNS 需要准确的 IP 去判断,IP 分流会影响解析的结果,我们需要让 PaoPao DNS 服务器避开 iKuai 上面的分流,因此就需要使用
端口分流
功能给 PaoPao DNS 服务器直接走运营商线路出去。此外,一些软路由存在劫持 DNS 请求的情况,这种情形下可能就会造成 PaoPao 无法进行 DNS 解析,解决办法参见这个issue。
线路
选择拨号线路(我这里的 adsl1 是运营商拨号线路)
- 勾选
线路绑定
;
负载模式
选择源 IP
;
协议
选择udp
;
源地址
添加上 PaoPao DNS 服务器的 IP 地址;
- 最后保存
这么做的意义在于,PaoPao DNS 服务器只有在进行 DNS 解析的时候(DNS 解析使用 UDP 协议),才需要使用固定的线路出去,设置好了之后再通过测试命令检测一下 PaoPao DNS 此时是不是可以正常工作:
(2)调整 iKuai DHCP 服务器与 DNS
DHCP 服务器的 DNS 服务器设置为 PaoPao 的 IP 地址:
(3)OpenWRT DNS 配置
1️⃣ DHCP/DNS 取消 DNS 转发
确保 DNS 不进行转发,因为在这个网络架构下,我们的目的就是要让 PaoPao 进行 DNS 解析。
(4)Alpine 自身的 DNS 调整
如果你和我一样同样是搭建了 Alpine 虚拟机来部署 PaoPao DNS ,那么在部署好了之后,你需要调整 Alpine 的
/etc/resolv.conf
文件,将 DNS 服务器设置为 127.0.0.1
,也就是说宿主机使用 PaoPao DNS 进行域名解析:13.5 调整此网络结构下的 OpenClash 配置
关于 OpenClash 上面的 DNS 解析,可以参考 V2EX 上面的一个帖子《关于 openclash DNS 解析的疑问》。
(1)OpenClash Fake-IP
模式下的配置
1️⃣ 使用 OpenClash 的 Meta 内核
博主自己使用的 Meta 核心下的 Fake-IP 模式,所以这里我提供 Fake-IP 模式下的配置参数,如果读者们经常打游戏,比如 Steam、橘子平台、Epic 平通、Xbox 或者 PS 等,建议读者们使用 Redir-Host 模式。
2️⃣ 停用 本地 DNS 劫持
这里建议把 OpenClash 的 DNS 劫持关闭。
3️⃣ 开启 绕过中国大陆 IP
功能
然后将
大陆域名 DNS 服务器
设置为 PaoPao 的 IP 地址:此功能的作用是将大陆 IP 和域名进行直连,不经过 OpenClash 核心,关于
绕过中国大陆 IP
更多的说明:openclash 的绕过中国 ip 主要由两个模块组成1. 在 iptables 中添加中国大陆 ip 段直接绕过的规则( ipset )2. 使用一份国内站点域名表,添加至 dnsmasq 中,在这个域名表中的 将会使用 114.114.114.114 来进行解析为真实的 ip ,并不使用 clash 核心的 dns 解析,所以会返回真实 IP综上,一个国内站点会获取到真实的国内 IP ,再被 iptables 放行。缺点是域名表不够全,只包含了主流站点,不够准确,并且这个列表比较大( 2m+),会导致 dnsmasq 启动较慢。
4️⃣ DNS 设置
- 开启
自定义上游 DNS 服务器
;
Fallback DNS 代理组 (支持正则匹配)
:开启并选择一个代理组,意思就是使用代理组里面的代理来访问 Fallback 里面的域名服务器进行 DNS 解析。
- 开启
Fake-IP 持久化
;
- 开启
Fakeback-Filter
(关于 Fallback-Filter 的作用解释):读者朋友可以复制这里面的配置到你的Fakeback-Filter
设置中,如果读者清楚这一功能的作用也可以自行配置。
接下来在自定义上游服务器的
NameServer
列表中添加两个国内的 DNS 服务器,这里我建议使用阿里云的 DOH DNS 服务器:然后分别修改这两个国内的 DNS 服务器的配置,开启
节点域名解析
和 强制 HTTP/3
功能:在
FallBack
域名组里面添加两个国外的 DOH DNS 服务器:5️⃣ 其他配置参考
(2)OpenClash Redir-Host
模式下的配置
1️⃣ 使用 OpenClash 的 Meta 内核
2️⃣ 停用 本地 DNS 劫持
这里建议把 OpenClash 的 DNS 劫持关闭。
3️⃣ 开启 绕过中国大陆 IP
功能
然后将
大陆域名 DNS 服务器
设置为 PaoPao 的 IP 地址:此功能的作用是将大陆 IP 和域名进行直连,不经过 OpenClash 核心,关于
绕过中国大陆 IP
更多的说明:openclash 的绕过中国 ip 主要由两个模块组成1. 在 iptables 中添加中国大陆 ip 段直接绕过的规则( ipset )2. 使用一份国内站点域名表,添加至 dnsmasq 中,在这个域名表中的 将会使用 114.114.114.114 来进行解析为真实的 ip ,并不使用 clash 核心的 dns 解析,所以会返回真实 IP综上,一个国内站点会获取到真实的国内 IP ,再被 iptables 放行。缺点是域名表不够全,只包含了主流站点,不够准确,并且这个列表比较大( 2m+),会导致 dnsmasq 启动较慢。
4️⃣ DNS 设置
- 开启
自定义上游 DNS 服务器
;
Fallback DNS 代理组 (支持正则匹配)
设置为你的代理组;
- 开启
Fakeback-Filter
(关于 Fallback-Filter 的作用解释):读者朋友可以复制这里面的配置到你的Fakeback-Filter
设置中,如果读者清楚这一功能的作用也可以自行配置。
Nameserver-Policy
(可选功能):这个功能的作用是对某一个域名指定使用某一个 DNS 服务器进行解析。假如说你希望使用 114 DNS 服务器解析 Baidu 的域名 ,那么格式为'*.baidu.com': '114.114.114.114’
。
主机
(可选功能):一般用不上,不做赘述。
接下来分别添加
NameServer
和 FallBack 的 DNS
服务器。NameServer
服务器列表:接下来在自定义上游服务器的
NameServer
列表中添加两个国内的 DNS 服务器,这里我建议使用阿里云的 DOH DNS 服务器:然后分别修改这两个国内的 DNS 服务器的配置,开启
节点域名解析
和 强制 HTTP/3
功能:FallBack
服务器列表:5️⃣ 其他配置参考
13.6 其他配置
待更新
13.7 PaoPao DNS 解析规则配置
经过前面的一些列配置,我们已经在原有 iKuai & OpenWRT 的架构上面补齐了最后一块拼图 —— DNS 解析。由于我们将 DNS 服务器进行了单独的部署,并且通过调整原有架构上面关于 DNS 解析功能的配置,最终实现了 DNS 解析与代理这两个功能的分离,在架构上面更简洁和清晰。
前面说过,PaoPao 可以实现域名解析的分流 —— 国内域名 PaoPao 本地解析,国外域名发送给 OpenClash 进行解析。但如果说我希望某一个域名不发送给 OpenClash 进行解析,或者反过来我希望某一个域名只发送给 OpenClash 进行解析,那么这时候就需要编辑 PaoPao 上面的规则文件来实现这样的自定义效果。
(1)自定义规则文件
你可以通过访问
http://ip:7889
来查看 PaoPao 的配置文件列表,具体每一个文件的作用请查看 Github 项目上面的说明。PaoPao DNS 服务器有以下几个可供用户自定义配置的
.txt
文件:force_cn_list.txt
:此文档的作用是强制使用本地递归服务器查询文档里面记录的域名,换句话说就是不交给 OpenClash 进行解析。容器版本更新不会覆盖该文件。一行一条,语法规则如下:- 以
domain:
开头域匹配:例如domain:03k.org
会匹配自身03k.org
,以及其子域名www.03k.org
,blog.03k.org
等。 - 以
full:
开头:完整匹配,例如full:03k.org
只会匹配自身,完整匹配优先级更高。 - 以
regxp:
开头:正则匹配,例如regexp:.+\.03k\.org$
(采用 Go标准正则)。 - 以
keyword:
开头匹配域名关键字,例如keyword: 03k.org
会匹配到www.03k.org.cn
。 - 尽量避免使用 regxp 和 keyword ,会消耗更多资源。
- 域名表达式省略前缀则为
domain:
。 - 同一文本内匹配优先级:
full > domain > regexp > keyword
force_nocn_list.txt
:强制使用 dnscrypt 加密查询的域名列表,匹配规则同上。容器版本更新不会覆盖该文件。
force_forward_list.txt
: 仅在配置CUSTOM_FORWARD
有效值时生效,强制转发到CUSTOM_FORWARD
DNS 服务器的域名列表,也就是说里面记录的规则会强制发送到 OpenClash 中进行 DNS 解析,匹配规则同上。容器版本更新不会覆盖该文件。
trackerslist.txt
:bt trakcer 列表文件,开启CN_TRACKER
功能会出现。此文件的作用是避免 BT/PT 下载时使用代理链接到 Tracker 服务器。该文件在更新时会增量自动更新(更新数据来源),你也可以添加自己的 trakcer 到这个文件(或者向该项目提交),更新的时候会自动合并。修改将实时重载生效。容器版本更新不会覆盖该文件。
(2)注意事项
- 如果你想解析的域名位于境外,并且没有境内 CDN ,而你又想获取原始记录(与
force_forward_list.txt
区分开),那么你应该把域名加进force_nocn_list.txt
而不是force_cn_list.txt
,因为基于个人网络环境差异,境外域名存在递归失败的可能。
- 修改
force_cn_list.txt
、force_nocn_list.txt
或force_forward_list.txt
将会实时重载生效。
- 文本匹配优先级
force_forward_list
>force_nocn_list
>force_cn_list
。
(3)总结
- 希望某个域名本地解析(不让 OpenClash 做解析),那么编辑
force_cn_list.txt
文件;
- 希望某个域名本地加密解析(不让 OpenClash 做解析),那么编辑
force_nocn_list.txt
文件;
- 希望某个域名强制走 OpenClash 解析,那么编辑
force_forward_list.txt
文件;
- 希望 PT 站的 Tracker 服务器本地解析,那么编辑
trackerslist.txt
文件。
13.8 进一步优化:配合 Adguard Home 的使用
如果你希望查看 PaoPao DNS 接收到了哪些 DNS 请求,或者说你想知道某个 IP 发起了什么 DNS 请求,又或者说你希望对某个 DNS 请求进行屏蔽,那么 PaoPao DNS 自身是不能实现这些需求的,因此我们可以再搭建一个 Adguard Home 作为 DNS 请求的入口,实现更具体的 DNS 请求统计、查询和管控等一系列功能。
需要说明的是,Adguard Home 在带机量大、过滤规则较多的情况下对设备的性能有一定的要求,如果你的设备性能有所欠缺,建议你谨慎使用。
本人不推荐在普通路由器上运行 AdGuard Home、Pi-Hole 等工具,路由器的性能对 AdGuard Home 的运行效率有着较大影响。根据本人测试,Pi-Hole 空载需占用 15MB 内存(不含缓存),AdGuard Home 空载需占用 20 MB 内存(不含缓存),AdGuard Home 带机 13 台、过滤规则 74000+ 条时占用 700MB 内存(含缓存)。 —— 少数派:AdGuard Home 安装及使用指北
(1)部署 Docker
同样的,我们可以使用 Docker 的形式搭建 Adguard Home:
由于 Adguard Home 会作为前端 DNS 解析的入口,所以 53 端口需要给到 Adguard Home 使用,因此我们需要重新调整 PaoPao DNS 的端口映射来避免和 Adguard Home 的 53 端口冲突,比如:
(2)DNS 配置
进入到 Adguard Home 以后,我们需要将 DNS 服务器设置为 PaoPao DNS ,格式为:
另外,为了保证即使 PaoPao 出问题不能使用了,我们还可以借助 Adguard Home 上面的
(3)其他设置
由于 PaoPao 自身有缓存,所以不需要开启 Adguard Home 上面的缓存功能:
另外需要补充的是,如果你也和博主一样虚拟化了一个 Alpine 虚拟机来搭建 PaoPao 和 Adguard Home ,那么在使用 Adguard Home 时请注意调整日志和数据统计文件的保存时间,因为这两项功能随着时间的增长会占据比较大的硬盘存储空间,所以如果你一开始分配给虚拟机的存储空间不大,那么建议你调整这里的配置:
其他的 Adguard Home 功能请自行探索。
整体效果如下:
(4)补充:iKuai 内添加 NAT 规则
这里的所添加的 NAT 规则其作用在于正确显示所有发往 Adguard Home 进行 DNS 请求的设备 IP 地址(参考上文 7.5 iKuai 添加 NAT 规则 ):
14. 相关网络优化
1️⃣ 优化 Fake-IP 模式下的 iKuai 多线负载功能
如果你和我一样使用 OpenClash 的 Fake-IP 模式,那么你可以这么去优化 iKuai 的多线负载设置:
(1)添加自定义运营商
将 Fake-IP 的 IP 地址段添加进去,但前提是你得在 openclash 里面设置 Fake-IP 的固定地址段,如下图所示:
然后创建一个新的自定义运营商:
(2)创建多线负载策略
运营商选择之前设置的 Fake-IP 地址段自定义运营商,然后线路选择
wan2
(也就是分流到 OP 的线路),负载比例设置为 1
,负载模式选择 源IP+源端口
。(3)保证 Fake-IP 的多线负载策略在第一位
由于 iKuai 的多线负载功能匹配顺序是按照先添加策略的那一个规则优先匹配(并且匹配到规则后停止后续的匹配),所以我们把 Fake-IP 的多线负载策略放到第一位,如下图所示:
如果你先前已经设置了国内 IP 段的多线负载策略,那么删除掉之后再重新添加即可让 Fake-IP 的多线负载策略实现第一顺位。
这么做的目的在于,当需要走代理的时候,也就是访问访问 fake-ip 地址时,可以第一时间跳过国内 IP 地址段的匹配规则,从而快速将需要代理的流量发往 OP。
参考资料:iKuai 官方文档 - 多线负载