2020年7月

有些臭运营商会乱改解析,导致你看小黄书…………不对,是看学术交流的网站会蹦出一大堆广告来
这是由于我们在进行PPPOE拨号的时候,运营商可以指定我们路由器WAN口的DNS,或是直接将我们WAN口对外DNS请求劫持。
[redbar]我们需要保证域名解析主要流程中的所有连接都是加密的不被篡改。 ————栗子[/redbar]
如何解决运营商劫持DNS的问题,我想的是只需要在运营商劫持之前做好劫持就可以了。
我们可以通过DOT(DNS over TLS)或者DOH(DNS over HTTPs)的方法保护解析不被篡改。
最开始我想了一个方案,使用Aliyun_HK的轻量服务器作为中转节点,从Cloudflare DNS或者Google DNS取数据,然后本地路由器劫持所有DNS流量并通过TLS连接Aliyun_HK获取DNS解析结果(就是vmess里最常用的ws+tls方案),结果没想到,Aliyun_HK的DNS也不是百分之一百完美的,访问国外专业学术网站时有时还是有微量的劫持问题,如下图所示。
main.jpg
当时是这样的一个情况,我想访问一个网站查资料的时候,发现无法访问,加了HK,JP,CA各种代理也无法访问,我冷静思考了半小时,才想到上图中红框框这个位置数据传输是不加密的,可能被劫持了,于是我修改成下面这样,确保解析每一个步骤都是加密传输的:
QQ截图20200724221527.jpg
就是使用Aliyun_HK主机从权威的DOH服务器取数据并缓存,然后本地使用Stubby连接Aliyun_HK的DOH服务取数据。
这样解析的安全性上去了,但是我发现解析的速度又下来了,因为要从国外取数据到HK,再从HK到BJ,还要过ADGH的隐私规则,这样解析一个IP要100ms左右的请求/响应时间。
我这个人比较懒,直接在路由器的Dnsmasq服务配置文件里把所有DNS的TTL设置成一天,然后配个脚本每天早上到服务器上把常用DNS取一下缓存到本地,倒是挺快的也够安全,就没再继续鼓捣了。
佛系DNSmasq配置:
QQ截图20200724223507.jpg
今天突然看到DnsPod公众号说腾讯家也出DOH服务器了,于是想着可以再搭个国内专用的DOH中转服务器,使用AdguardHome中转的同时可以把我常用的内网hosts也加到里面,再配置一些防追踪的规则,应该能比现在快很多。
搭建AdguardHome肯定是最简单的,不管你啥服务器直接5条命令搞定:

wget https://static.adguard.com/adguardhome/release/AdGuardHome_linux_amd64.tar.gz #下载
tar xvf AdGuardHome_linux_amd64.tar.gz #解压
cd AdGuardHome #打开文件夹
sudo ./AdGuardHome -s install #安装
./AdGuardHome -s status #运行

配置服务器安全组:
QQ截图20200724225559.jpg
登录ADG配置上游服务器:
QQ截图20200724223951.jpg
配置隐私和广告规则:
QQ截图20200724224023.jpg
配置内网HOSTS
QQ截图20200724224125.jpg
配置抗D规则,这步主要是需要在自定义规则加这样一条,用于防止一种常见的DNS攻击:
[redbar]||pizzaseo.com^$important
这个pizzaseo是DNS攻击最常见的域名,把它屏蔽掉可以节约一半DNS资源。[/redbar]
QQ截图20200724224211.jpg
配置TLS证书:
QQ截图20200724224759.jpg
配置域名解析:
QQ截图20200724224513.jpg
配置本地路由器上Stubby服务连接AdguardHome_DOH服务器:
QQ截图20200724225005.jpg
QQ截图20200724225105.jpg
配置DNSmasq的端口劫持:
QQ截图20200724225157.jpg
配置本地主机,延迟4个6:
QQ截图20200724225331.jpg
QQ截图20200724225258.jpg
配置本地浏览器:
QQ截图20200724225408.jpg
配置手机DOT:
QQ截图20200724225706.jpg
测试DNS是否正常劫持到DOH上:
QQ截图20200724225937.jpg
到ADG上可以看到解析记录:
QQ截图20200724225849.jpg
访问国内被劫持的网站,没有问题:
QQ截图20200724230042.jpg

测试通过。
[greeninfo title="附自建DNS供大家测试,有效期1年。"]DNS:120.92.74.158:53
DOH:https://dns.nsoc.tech:444/dns-query
DOT:tls://dns.nsoc.tech:853[/greeninfo]

搭建在软路由上面的Nextcloud是由一个PHP-NGINX-Docker和一个MYSQL-Docker组成的,
nextcloud.jpg
本来计划配置源站+OSS+CDN的模式准备给网盘提升一下速度,结果SSL证书我都做好了,发现阿里云只支持443端口的CDN源站,我北京联通443端口被封了,当然就没法用CDN了。
网盘刚搭建好的时候响应还比较快,然而随着文件量的增加,近期点击页面中的按钮会卡好几秒,感觉不像是CPU性能瓶颈(Intel(R) Celeron(R) CPU 3855U),直觉就是MySQL数据库反应慢,于是决定先优化一下本地数据库好了。
system.jpg
性能不够,Redis来凑,先开个Redis-Docker

docker run -d \
 --security-opt seccomp:unconfined \     #允许容器执行全部的系统的调用
 --restart=always \     #一直运行
 --name Redis \     #配置友好名称
 --network cloud \     #配置网络,与Nextcloud连到同一网段
 --ip 172.19.0.250 \     #指定Redis的IP地址
 -p 6379:6379 redis

关闭Nextcloud和MySQL的Docker
stop.jpg
找到Nextcloud的配置文件,加上Redis配置/www/nextcloud/config/config.php

  'memcache.local' => '\OC\Memcache\Redis',
  'memcache.distributed' => '\OC\Memcache\Redis',
  'memcache.locking' => '\OC\Memcache\Redis',
  'redis' => array(
  'host' => '192.168.60.1',
  'port' => 6379,
  ),  

redisconf
大功告成,打开Nextcloud,已经非常明显的加载速度提升了。

next.jpg

Ps: 顺便改一下MySQL配置增加性能:

Docker console到MySQL,在my.cnf里加一条

innodb_flush_log_at_trx_commit = 0  #在提交事务时,InnoDB不会立即触发将缓存日志写到磁盘文件的操作,而是每秒触发一次缓存日志回写磁盘操作,并调用操作系统fsync刷新IO缓存(假装是懂了)。

docker console查下MySQL配置

SHOW VARIABLES like '%flush%'

mysql.jpg
再打开Nextcloud,瞬间加载,美滋滋,感觉加载速度变快了一百倍。